Support ripe building artist owned infrastructure

Build log

PND grew one tool at a time, in response to what artists kept running into. This page is the log of what shipped, in the order it shipped.

It is not a roadmap. Nothing here is a promise about what comes next. It is a record of what is already done.

  1. Catalog import planner

    /artist/[address]/import turns an artist's self-published registry (currently Bryan Brinkman's JSON-LD feed at bryanbrinkman.com/api/artworks) into a one-click bulk-import flow for the Catalog contract. The planner filters to mainnet, deduplicates against what's already on-chain, surfaces non-mainnet and off-chain entries transparently, and batches the writes into a few multicall transactions.

    Why this matters for artists. Declaring 200+ works one at a time was never going to happen. If you publish your own canonical list of work, PND can translate it into your on-chain Catalog in a handful of transactions.

    ▸ technical detail

    Pluggable adapter registry under apps/web/src/lib/import-sources/. Per-contract granularity toggle (token-by-token vs. full contract), hidden for known shared platforms. Multicall hook chunks at 50 ops per tx. End-to-end verified on an anvil fork: 229 ops across 5 multicall txs against the live Catalog contract.

  2. Indexed every artist active on a supported platform

    PND now keeps a server-side index of every address that has acted as an artist on a contract PND supports (Sovereign house owners, Foundation creators and minters, Catalog declarants), and a per-artist index of their work across every supported platform (Foundation, Sovereign, Manifold, SuperRare V2, Transient Labs). The data lives in PND's own database, not refetched against the chain on each page load.

    Why this matters for artists. Wherever PND shows your work, it's reading from one consistent record of what you've made across the platforms it covers. That same record is the substrate the catalog tooling reads from, so flows like the import planner can pull from what you've already minted instead of asking you to track down contract addresses.

    ▸ technical detail

    known_artists is a Postgres view over Ponder tables (Sovereign house owners, Foundation creators and artist-token minters, Catalog declarants). Per-artist token enumeration on the external platforms (Manifold, SR V2, Transient Labs) is stored in three status tables with incremental eth_getLogs cursors. Refreshes are background-only and gated on the known set, so anonymous traffic can't drive RPC fan-out.

  3. Catalog mainnet deploy + /catalog and /dependency pages

    The Catalog contract went live on Ethereum mainnet. Artists can publish an authoritative on-chain list of which contracts, tokens, and token ranges belong to their public record. /catalog/[address] is the read view and the owner's edit flow. /dependency/[address] is a contract-centric companion that asks which artist any given contract belongs to. The artist page surfaces a compact Catalog section when an artist has declared anything.

    Why this matters for artists. If a collector or another artist asks 'is this really yours?', the answer can now live on-chain in a place you control, separate from any one platform. Galleries, archives, and tools can read it without trusting PND.

    ▸ technical detail

    Immutable, public-infrastructure contract: no admin, no owner, no upgrade path, no fees. Deployed via CREATE2 so the same address applies on every EVM chain given identical bytecode and salt. Multicall and operator delegation. Add/remove events include the actor so audit trails are self-contained. Indexed by Ponder so /catalog reads from Postgres rather than fanning out to RPC on every visit.

  4. /delist landing page

    A dedicated /delist page explains the bulk-cancel tool and previews any wallet's active Foundation and SuperRare listings without requiring a connection. Paste an address or ENS to see what's listed. Connect that wallet to cancel selected rows. Linked from the For-artists nav and a new /guides/delist explainer.

    Why this matters for artists. If a collector or another artist asks whether they have stale Foundation or SuperRare listings, you can send them one URL. They see what's listed before being asked to connect anything.

  5. Guides section, with the first guide on auction contracts

    /auctions explains the artist-owned auction contracts in plain language. Who deploys and owns each contract, how listing, bidding, and settlement actually happen, what continues to work if the PND frontend disappears, and the tradeoffs against a shared platform contract. Linked from a new /guides hub and from a new 'For artists' dropdown in the navbar.

    Why this matters for artists. When a collector or another artist asks how your contract actually works, you can link them to one page that answers it. Same job /about does for the project, scoped to the contracts themselves.

  6. Build log added

    This page. A timeline of what PND has shipped, in the order it shipped.

    Why this matters for artists. If you want to see where the project has been before deciding whether to use it, or whether to support it, the answer is now on one page instead of scattered across PRs and X posts.

  7. funding-works campaign hit its threshold

    The FundingWorksRipe campaign funding PND closed past its minimum threshold. Supporters minted, streams activated, and the work continues without VC money or platform fees.

    Why this matters for artists. PND's runway for the next phase is funded by people who believe artist-owned infrastructure should exist. Not by taking a cut from your sales.

    ▸ technical detail

    FundingWorks streams funds to ripe over time. Supporters hold a token connected to the campaign and can burn it to redeem the unvested remainder if the relationship stops feeling aligned. The supporters list lives in the global footer of every PND page.

  8. About page added

    /about explains what PND is, why it started, and what it has shipped so far.

    Why this matters for artists. If a collector or another artist asks 'what is this,' you can link them to one page instead of explaining it in DMs.

  9. Supporters thanked in the global footer

    Every page now thanks the people who minted from the funding-works campaign that funds PND.

  10. Activity feed promoted to the home page

    The home page now shows a live, lazy-loading feed of auctions, bids, mints, and settlements across the platforms PND covers.

    Why this matters for artists. First-time visitors see the work happening right now, not an empty search box.

  11. /sites landing page + fork-friendly deploys

    A dedicated /sites page explains the self-hosted artist site option. The deploy path was reshaped so an artist can fork the template and deploy to Netlify with only a wallet address. No PND-issued keys required.

    Why this matters for artists. You can run your own auction site on your own domain. If PND goes away, your site keeps working against your contract.

  12. Artist-owned site template MVP

    A standalone Next.js template that reads an artist's auction contract directly, with the same design system as the main PND app.

    Why this matters for artists. Your auctions can live on a site you control, separate from PND.

    ▸ technical detail

    Token-page layout, sticky artwork, Owner + Provenance sections, dynamic favicon, theme-aware bid history. Cache keys include artistAddress so multiple sites can coexist.

  13. Transient Labs support + /auction/new for any owned ERC-721

    PND now reads Transient Labs galleries and bid histories. Artists can also start an auction on any ERC-721 they own, not just tokens from a supported platform.

  14. Platform adapters: SuperRare V2, Manifold, Foundation

    PND moved from being Foundation-specific to a multi-platform reader. Artist galleries, collector views, last-sale lookups, and auction interactions now loop over a registered set of platform adapters.

    Why this matters for artists. Your artist page now shows work across the platforms you've used, not just one.

    ▸ technical detail

    Introduced an adapter interface + registry; refactored gallery, last-sale, and collector paths to fan out across Foundation, Sovereign, SuperRare V2, Manifold, and (later) Transient Labs.

  15. Multi-platform delist + relist

    Artists can delist from Foundation and SuperRare V2 in a single flow, then relist into their own auction contract.

  16. Home: work + artist grid

    The home page replaced its search-only landing with a shuffled grid of work and artists.

    Why this matters for artists. Visitors see who's on PND immediately, instead of having to know what to search for.

  17. Sovereign Auction House v1.0.0 mainnet deploy

    The artist-owned auction contract went live on Ethereum mainnet. Immutable, zero platform fee, no admin role, no PND-controlled upgrade path.

    Why this matters for artists. Auctions you run through this contract belong to you. The contract keeps working whether or not the PND frontend does.

    ▸ technical detail

    Houses are EIP-1167 minimal-proxy clones from an immutable factory. Ownership is locked at deploy. Reads are public; writes are callable from any wallet that can call functions.

  18. Migrate UI: Foundation → Sovereign

    A guided flow to delist a token from Foundation and relist it into the artist's own Sovereign auction contract in one session.

  19. Bulk delist from Foundation (EIP-5792)

    Artists can delist many Foundation listings at once. Wallets that support EIP-5792 batch the calls; others fall back to one-by-one.

    Why this matters for artists. Cleaning up old Foundation listings stops being a 20-transaction afternoon.

  20. Foundation reserve auction panel with on-chain bidding

    After Foundation's frontend went offline, PND added a panel for placing bids, viewing bid history, and resolving ENS on existing Foundation reserve auctions.

    Why this matters for artists. Auctions that were already running on Foundation stayed usable.

  21. Artist profile + preserve flow

    The first usable shape of PND: an artist profile with a Preserve flow that discovers the tokens an artist had on Foundation and lets them pin the media to IPFS through their own pinning provider.

    Why this matters for artists. If Foundation's storage ever stopped resolving, your work would still have a home you control.

    ▸ technical detail

    Pinata as the default, with Filebase and 4EVERLAND as alternatives for free-tier artists. Pin failure reasons are surfaced instead of swallowed. Discovery is scoped to Foundation-pinned tokens, with stable already-pinned counts via batch status checks.