License IP on Story. Two-sided sealing. One atomic settlement.
SealedIP is a trustless sealed-bid auction protocol for licensing IP registered on Story Protocol. It is two-sided sealed: bidders encrypt their bid amounts AND the seller encrypts the reserve price. Neither side sees the other's number until settlement. Powered by CDR (Confidential Data Rails), Story's threshold-decryption network operated by piplabs.
Why two-sided sealing?
The bidder side
Open auctions on-chain leak. Anyone can read the mempool and snipe at the last block. Anyone running a node can sequence bids in their favor. Even with private mempools, the operator sees everything.
SealedIP fixes this with CDR threshold cryptography:
bids are encrypted under a key that no single party — not us, not the
validators, not the seller — can decrypt alone. They reveal in lockstep only
after the deadline AND after someone calls trigger().
The reserve side
A visible reserve floor changes strategy. Bidders anchor on it and shade their bids just above. Sellers who want true price discovery need the floor hidden as much as the bids.
SealedIP gives the seller a separate CDR vault for the reserve. The seller
signs the same BidPayload digest structure (with their own address as
signer), encrypts it, and submits it via submitEncryptedReserve. At settle
the contract verifies the signature recovers the seller's address — forgery
reverts the entire settle with InvalidReserveReveal. If the seller never
seals a reserve, the floor defaults to 0 WIP.
Multi-step reveal condition (AuctionRevealCondition)
CDR validators won't publish decryption shares just because the clock passed.
The AuctionRevealCondition contract gates each vault on TWO conditions:
block.timestamp >= auction.deadlineSealedAuction.isTriggered(auctionId) == true
Both must be true simultaneously. This makes the trigger call the intentional "open the envelope" act, not passive clock expiry.
Atomic settlement
The winner, payment, refunds, and license mint all happen in one transaction. If any step would fail, nothing happens — there's no partial state where one bidder is paid and another isn't refunded.
Trustlessness guarantee: a malicious orchestrator can only censor (which auto-refunds everyone), never forge a winner or pay a non-winner. The contract re-verifies all signatures and deposit caps on-chain. The t-of-n CDR threshold means no single party holds the full decryption key.
What you can do
| I'm a... | Start here |
|---|---|
| Bidder looking to license IP | Quick start for bidders |
| Creator wanting to sell licenses | Quick start for sellers |
| Developer integrating SealedIP | Quick start for developers |
| Auditor or security researcher | Threat model |
| CDR validator / operator | Operators guide |
At a glance
- Network: Story Aeneid testnet (chain id
1315) - License standard: Programmable IP License (PIL)
- Currency: WIP (wrapped IP)
- Settlement: Atomic, single transaction
- Privacy: Two-sided sealed — bids AND reserve encrypted via TDH2/CDR
- Reveal gate: AuctionRevealCondition (deadline + trigger, both required)
- License: MIT
State of the project
This is the documentation for the SealedIP protocol as built for the CDR Hackathon (Story Foundation), May 27 – June 5, 2026. The deployment lives on Aeneid testnet only. Covered by a Foundry test suite; otherwise unaudited. See Audit status for the honest read on what's been verified and what hasn't.
Production launch targets and any mainnet deployment will be announced separately. Until then, treat all deployed addresses as redeployable at any time.