Skip to main content

Known limitations

Operational and design limitations of the current SealedIP deployment.

Unaudited, testnet only​

No professional audit has been performed on the contracts. The current suite is 43 Foundry tests covering the happy path and the obvious adversarial cases (signature forgery, deposit overrun, double-write, sealed reserve bypass, etc.), but is not a substitute for a security review.

Treat the current deployment as testnet-only. Real value should not be escrowed in these contracts until a professional audit is complete.

CDR contract not verified on Storyscan​

The CDR system contract (0xCCCcCC0000000000000000000000000000000005) is not verified on the Aeneid Storyscan explorer. The marketplace UI cannot read validator-set size or threshold parameters on-chain. The NEXT_PUBLIC_CDR_THRESHOLD environment variable (default 3) is used for display purposes only; it does not reflect CDR governance and may not match the real threshold in use.

Validator set trust​

Confidentiality depends on the CDR validator set not colluding above the t-of-n threshold. A collusion of t validators could decrypt bids before the deadline. The validator set is operated by piplabs in this deployment. See Validators for context.

Orchestrator availability​

Decryption and settlement are currently driven by a single SealedIP orchestrator account. If it goes offline:

  • trigger() is permissionless, so anyone can flip state to Triggered.
  • settle() requires whoever calls it to read the CDR plaintext and submit the reveals. This is not orchestrator-exclusive: the SDK's settleAuction does the whole flow (trigger, decrypt every vault via CDR, settle), and it has been run end-to-end on Aeneid (see Audit status: Verified live end-to-end). The practical limitation is liveness, not capability: someone has to run it.

Deposits remain safely escrowed during any outage, but auctions do not advance until the orchestrator is back up or someone else assembles the reveals. See Triggering auctions for how a third party could self-settle.

Settlement gas scales with bid count​

Settling an auction with N bidders requires N WIP.transfer calls (one per bidder for refund), one license mint, and one seller payout. Gas cost scales linearly. For typical auctions this is manageable; for an auction with hundreds of bidders, settlement gas could approach block limits. A future version might add a pull-payment mode where losers withdraw refunds themselves.

Floor-0 default for unsealed reserves​

If the seller creates an auction but never calls submitEncryptedReserve, reserveHasCiphertext stays false and the settle-time reserve floor defaults to 0. Any valid bid, including a bid of 1 WEI, can win. Sellers who want a reserve must actively seal one before the deadline.

No griefing penalties for allocate-but-don't-bid​

A bidder can call allocateBidSlot (locking a deposit) and never submit ciphertext. The deposit is returned at settle. This is intentionally permissive for the demo, but allows a griefing vector where a well-funded actor can lock deposits without ever bidding meaningfully.

No bid cancellation​

Once a bid is sealed on-chain, there is no way to cancel it. The deposit is escrowed until the auction settles or expires. If you make a mistake (wrong amount, wrong auction), the contract has no recourse. You can place a second, higher bid to override a lower one, since settle() picks the highest valid bid.

No revocation path for license tokens​

Once settle() mints a PIL license to the winner, the contract has no admin function to revoke it. Reversibility comes only from PIL terms themselves (e.g., expiration). This is by design: atomic settlement requires minted licenses to be final.

No reserve currency choice​

All bids are denominated in WIP. There is no way to list an auction denominated in USDC, ETH, or any other asset. Adding multi-currency support is out of scope for the current deployment.

No multiple bids per bidder​

Each bidder can only allocate one bidSlot per auction. A second call to allocateBidSlot for the same auction is not blocked at the contract level, but the settle() loop picks only the single highest valid bid from any address. This is not a theft risk but means extra deposits from duplicate slots are tied up until settle.

CDR key rotation​

If the CDR network rotates its threshold key while a SealedIP auction is open, ciphertexts encrypted under the old key may see nondeterministic decryption latency during the transition window. CDR retains old keys for in-flight ciphertexts, so clean decryption is expected in practice. Watch CDR's governance feed for rotation announcements if operating high-stakes auctions.

Image hosting​

NFT images uploaded through the marketplace UI are pinned to Pinata. If Pinata rotates its gateway URL, image URLs in NFT metadata may break. The on-chain tokenURI is ipfs://<cid>, so the underlying content is content-addressed and recoverable from any IPFS gateway. UI breaks are temporary.

What's documented elsewhere​