The guide · Perpetual in plain language

What Perpetual does, and why it matters.

You do not need to know how a blockchain works to understand Perpetual. Every idea here is explained twice: first the way you would explain it to a friend, then the way the machine actually does it. Read the plain parts straight through; open the technical blocks whenever you want the mechanism.

01The problem

Most NFT art can quietly disappear.

When you buy an NFT on a typical marketplace, you own a permanent receipt that points at a file stored somewhere fragile. The receipt survives forever. The file usually does not.

This is not a rare failure. Image hosts shut down, IPFS pins stop being paid for, and startups fold, taking every file they hosted with them. The blockchain keeps saying you own the token. The token points at nothing.

Perpetual was built to close exactly that gap: the artwork itself, not just the receipt, has to survive.

Under the hood

A standard NFT is an ERC-721 token whose tokenURI points to metadata, which points to media. Both links usually resolve to an HTTP server or an IPFS gateway. If the pin lapses or the domain expires, the chain still records ownership, but resolution fails: the CID has no serving node, or the URL 404s. Nothing on-chain prevents this, because nothing on-chain contains the art.


02The fix

Five copies, one of them indestructible.

Every artwork on Perpetual is stored five times, in five independent places. Four copies make it fast and high-resolution. The fifth is written into the blockchain itself, and that one cannot be taken down by anyone.

The engraved copy is called the onchain proof. It is a canonical image of the work written directly into Ethereum, so it survives for as long as Ethereum itself exists, no matter what happens to Perpetual, to the artist, or to any hosting company. The other four copies exist so the art also loads fast and in full resolution day to day.

Nothing on Perpetual can be listed for sale unless its onchain proof exists and matches. Permanence is the entry ticket, not an upgrade.

Under the hood

Shard 0, the STATE shard, is written via SSTORE2: the image bytes become contract bytecode inside the ForeverLibrary contract, with the content hash computed on-chain at mint. Contract state is consensus-guaranteed and cannot be pruned.

Shard 1, the LOG shard, stores the full-resolution media in event logs via the LogLedgercontract at roughly 8 gas per byte; only a Merkle root and size live in state, so anyone can verify the bytes against the root. Shards 2 through 4 are IPFS, Arweave, and Irys: three independent permanent-storage networks with separate operators and failure domains. Every shard’s hash is anchored on-chain, so integrity is checkable against an immutable reference.

Read the full permanence explainer →


03Creating

Minting: publishing a work so it cannot be lost.

Minting on Perpetual is uploading your artwork once and letting the system place all five copies, write the provenance record, and set your royalty. A few minutes of signing; permanence from that point on.

You choose a one-of-one or an edition (numbered copies of the same work, like prints from one negative, each individually owned). You set your royalty up front. For a short window after minting you can still adjust the redundant copies; then you can lock everything, permanently, as a signal to collectors that nothing about the work can ever change.

Under the hood

mint() writes the provenance record (artist, title, timestamp, media type, metadata hash), stores the proof bytes via SSTORE2, sets the ERC-2981 royalty (up to 10%, matching the settlement clamp so it is always honorable in full), and emits TokenMinted for indexers. mintEdition() mints N tokens (up to 100) sharing one storage footprint: a single SSTORE2 pointer and content hash across the edition, so an edition costs roughly what one mint costs in storage.

Storage economics are explicit: either the artist pre-pays a flat storage fee at mint and the token trades fee-free forever, or Perpetual fronts storage and earns a small hosting fee (at most 1.5%) on each sale, recorded on the token itself. An edit window (set per collection) allows shard additions after mint; lockShards() ends it irreversibly.

Open the mint studio →


04Artist sovereignty

Your collection can be a contract you own outright.

Most platforms mint your art into their contract, under their rules. Perpetual lets you deploy your own contract in one transaction. It belongs to your wallet, and only you can mint into it.

A sovereign collection is discovered and traded on Perpetual exactly like everything else, but nothing about it is held hostage: if you ever leave, your contract, your tokens, their provenance, and their permanence all leave with you, unchanged. And because only the owner can mint into a sovereign collection, nobody can forge a work into your name.

Under the hood

ForeverLibraryFactory.createCollection(name, symbol) deploys a fresh ForeverLibrary owned by the caller and emits CollectionCreated so the indexer picks it up automatically. Sovereign collections are deployed owner-mint-only (openMint = false): mints from any other wallet revert, which closes the forged-provenance vector. The shared canonical collection stays open for artists who do not want their own contract. Ownership transfers use a two-step nominate-and-accept flow, so a mistyped address can never take control.


05The market

Trading that cannot shortchange the artist.

Listing costs nothing. Money and art only move at the moment a sale actually settles, and the settlement itself checks the artist's royalty. A sale that skips the royalty is rejected by the contract, not by a policy.

Listing a work or making an offer is free: you sign a message stating your terms, and nothing touches the chain until someone accepts. When a trade settles, the artwork, the payment, the royalty, and any fee move in one atomic step. Perpetual never holds your art or your money at any point.

Under the hood

Orders are EIP-712signed messages, valid against the settlement contract regardless of whether Perpetual’s orderbook is online. Settlement reads the token’s royaltyInfo() (ERC-2981) on-chain and reverts if the payout does not honor it; the seller also signs a minimum-proceeds figure, so a manipulated fee structure cannot silently reduce what they receive. Smart-contract wallets are supported via EIP-1271 signature checks.


06Barter

Trade art for art, not just for money.

Perpetual restores the trade most marketplaces dropped: your token for theirs, directly, with cash added on either side only if the values need balancing.

Every proposal can be accepted, declined, or countered, and a counter simply re-opens the terms. Nothing moves until both sides have signed, and then the whole trade settles at once: there is no moment where one side has both assets.

Under the hood

NFT-for-NFT orders bundle token sets on both sides with an optional ETH top-up in either direction, settled atomically by the same settlement contract as sales. Criteria swaps sign an offer against a collection (optionally a trait) rather than a token id; the counterparty supplies any qualifying token at fill time, and the contract verifies it matches the signed criteria.

Open the swaps desk →


07Two networks

Ethereum and Base, traded as one market.

Perpetual runs on two blockchains, Ethereum and Base, presented as a single marketplace. When the two sides of a trade live on different chains, the swap still settles without anyone having to trust anyone.

No bridge, no middleman holding both assets, no wrapped stand-in tokens. Either both sides of the trade complete, or both sides get their property back. The small flat swap fee is shown before you sign and refunded if the trade never settles.

Under the hood

Cross-chain settlement uses hashed-timelock escrows (HTLC): both legs lock under one hashlock, with the maker’s timelock longer than the taker’s. Claiming one leg publishes the secret on-chain, which is precisely what lets the counterparty claim the other. A minimum timelock prevents griefing with instant-expiry locks, and if a payout to a contract wallet is rejected, the funds are held claimable via withdraw() rather than stuck.


08Inheritance

Art that outlives you needs somewhere to go.

Permanent art raises a question most platforms ignore: what happens to your collection when you lose your keys, or when you are gone? Perpetual lets you name an heir on-chain, ahead of time.

You designate an heir wallet while you are active. Nothing changes about your ownership. If your wallet then goes silent for a long period, the heir can begin a claim, which starts a waiting period. Any activity from you at any point cancels it. The design goal is strict: an heir can never take from a present owner, and a lost owner can never strand the work.

Under the hood

The ContinuityVault contract records a designation, an inactivity threshold, and a claim delay. Liveness is any transaction the vault observes from the owner. initiateClaim() starts the clock only after the threshold; the owner can veto at any time before the delay elapses, and a vetoed claim can be re-initiated later only if the owner has gone silent again. The vault holds no assets and takes no custody; it authorizes the transfer, nothing more.


09Living works

Code art needs its instrument preserved too.

Generative and interactive works are programs, and programs lean on libraries that live on some company's servers. Preserving the artwork means preserving the code it runs on, forever, in the same place.

An interactive piece on Perpetual can reference its libraries from an on-chain store instead of a CDN. When the work is displayed, those libraries are read back from the chain, verified byte-for-byte, and assembled into the artwork, with no dependence on any company still existing.

Under the hood

The ScriptStore contract stores libraries in SSTORE2 chunks, sealed under an author-bound content hash. Artwork HTML references them with <script data-onchain="name">, optionally pinning the exact bytes with data-onchain-hash so the work always resolves the version its author validated. The resolver verifies every read against the sealed hash before inlining; unverified bytes are never executed.


10The invariant

What happens if Perpetual disappears?

This is the question the whole system is designed around, so it deserves a direct answer: nothing happens to your art. Ownership, provenance, and the artwork itself all survive, and the marketplace around them can be rebuilt by anyone.

Every token page includes a live demonstration of this, the Vanish Test: watch the operator-dependent layers go offline one by one while the onchain proof keeps resolving the artwork from Ethereum itself. You can also download a Certificate of Permanence for any token, an archival record you keep independently of us.

Under the hood

The indexer reads only public data: the contracts, their events, and the public storage networks. Its schema is published, so a third party can re-index everything and stand up a replacement marketplace with zero cooperation from Perpetual. Orders settle against the contract, not against our servers. The operator is replaceable by construction; that property is the product.


11Start here

Three steps, none of them custodial.

Connect a wallet, mint or collect, trade when you are ready. Perpetual never holds your keys, your art, or your money.

  1. 01

    Connect a wallet. Any standard wallet works. Connecting costs nothing and grants nothing beyond a public address.

  2. 02

    Mint, or start collecting. Artists: upload once, choose your royalty, and the five copies are placed for you. Collectors: every work you see here already carries its permanence with it.

  3. 03

    Trade on your terms. Fixed price, offers, art-for-art swaps, or cross-chain trades. Every cost is shown before you sign.