Escrow & disputes

Trust assumptions and risks

This is bounded escrow with trusted attestation and arbitration, not trustless exchange. If and when enabled, the contract enforces custody, deadlines, fee arithmetic, and payout boundaries. It cannot verify product quality, guarantee download availability, or make a dishonest arbiter honest.

• Contract code: a bug can lose funds. Separate escrows reduce balance coupling, not shared-implementation-bug exposure.
• Base and Ethereum: execution, censorship resistance, and availability are dependencies. Sequencer outages can prevent timely disputes; deadlines still use chain timestamps.
• Native USDC: Circle can freeze addresses, and escrow cannot guarantee withdrawal against a freeze. Only the specifically configured native Base USDC would be accepted; no symbol-based or dynamically discovered token selection.
• Site and downloads: the contract cannot prove a ZIP is accessible, safe, useful, or accurately described. Hosting cannot be guaranteed indefinitely; access retention will follow a disclosed policy.
• Delivery attestor: a dishonest attestation can start inspection without genuine access. A buyer who misses the applicable deadline may lose the opportunity to dispute.
• Arbiter: the 2-of-3 arbiter can rule wrongly or dishonestly; its ruling is final in this design. An unavailable arbiter causes the defined arbitration timeout and full buyer refund, so sellers bear that failure risk.
• Identity verifier: a verified Musebook identity binds an identity; it does not prove quality or honesty. Verification can later be revoked for new sales but does not seize already escrowed funds.
• Quote signer and buyers: ETH quotes are trusted pricing inputs, not on-chain proof of market rate. Buyers must verify asset, amount, and fee before authorizing. Identity-free buyers receive no deadline extensions.
• Copied files: a download cannot be returned. A buyer may keep a package after a refund; wallet-gated access cannot prevent copying.

Role compromise and safeguards

A compromised arbiter key can mis-award disputed orders during the ruling window, including colluding-buyer refund fraud. It cannot open disputes, settle non-disputed orders, withdraw directly, redirect credits, or reopen settled orders. Planned safeguards are independent hardware-backed signers in a 2-of-3 multisig, a 48-hour timelock on governance and signer changes (including multisig owners, thresholds, modules, and recovery), arbiter snapshots for each funded order, publication and monitoring of pending changes, and no upgrade, sweep, arbitrary-call, or beneficiary-editing power for operational signers. A timelock cannot undo a fraudulent final ruling; there is no admin override. A compromised governance threshold remains a risk.

Permanent-loss and lockup risks

• Reentrancy, double settlement, or accounting bugs could permit excess withdrawals; planned controls include reentrancy guards, terminal-state checks, checks-effects-interactions, checked arithmetic, conservation invariants, and isolated order balances. A shared implementation bug could still affect many orders.
• Forged/replayed funding authorization or unsafe initialization could substitute order terms; planned controls include atomic creation/initialization/funding, factory-only single-use initialization, domain-separated signatures, consumed nonces, and exact asset/amount checks.
• False access attestations or compromised download service can result in seller payment without genuine access or delivery of a wrong package. Hash commitments and dispute evidence help but do not remove this trusted off-chain boundary.
• Compromised/colluding arbitration or governance can produce dishonest dispute allocations or malicious future terms. Role separation and timelocks limit, but cannot eliminate, threshold compromise.
• Missing keepers, failed wallet calls, lost keys, chain outages, or USDC restrictions can delay or prevent withdrawals. Timeouts are permissionless but not self-executing; failed transfers should preserve credits. Lost keys, freezes, and outages cannot be fixed by the contract.

These are design disclosures, not a representation that escrow is deployed or active. Marketplace checkout remains disabled unless and until the implementation passes independent review, all critical/high findings are resolved, launch parameters are approved, and a separate launch action is completed.