Risk disclosures
The things that can go wrong, named, with what the house can and cannot do about each. This page is written to be read rather than to be signed, and it does not soften anything the Terms of Service say.
Irreversibility#
A transfer sent to the wrong address, on the wrong network, or in the wrong asset is gone. Not gone-pending-a-support-ticket: gone. Minthouse cannot reverse it, the chain cannot reverse it, and no party has the authority to reverse it. Check the address, the network and the asset before you sign, every time.
This applies to every on-chain action on the platform: escrow deposits, escrow withdrawals, invoice payments, and cash-out deposits. It does not apply to the auction itself, a sale the house reverses under Authenticity and enforcement is reversed in the house's own ledger, and any refund is a new payment rather than an undone one.
Key loss#
The escrow contract keys every balance to the address that deposited it. There is no function that reassigns a balance to a different address, and that is deliberate: the same property that stops Minthouse moving a bidder's balance to an address of its choosing stops the house rescuing a bidder who has lost control of theirs.
- Lose the keys to a wallet with a free escrow balance and that balance is unreachable, permanently.
- Lose them while a balance is locked and the same is true after the lock expires.
- Where an account signs in through the embedded-wallet provider, recovery is that provider's, under that provider's model. Minthouse holds no key material for a customer and cannot recover one.
Escrow custody#
The bid escrow holds customer funds. The house says so plainly rather than describing the arrangement as non-custodial, and the complete account of what that costs a bidder is Guarantees and limits. The three risks it names, in short:
- Free balance can be encumbered. The house's key can lock free balance against a lot. That is how collateral works and it is not a defect, but it means a balance sitting in the contract is not the same as a balance in your wallet.
- A requested withdrawal is not a guaranteed exit. Until it is claimed, a pending withdrawal can be drawn back into a lock. Finishing the delay is not what makes the money safe; claiming it is.
- A locked balance is unreachable while the contract is paused. Free balance is always reachable, pause or no pause. Locked balance waits for the settler, for the lock's own 30-day clock, or for a revoke.
Each of those is bounded, and each bound is stated exactly on the guarantees page rather than characterised.
Physical custody of a card#
A card kept in the Minthouse vault, whether a consignment awaiting sale or a purchase the buyer chose not to have shipped, is a physical object in someone else's building, and it carries the risks a physical object carries: loss, damage, theft, fire.
The house undertakes no insurance on a card in the vault and arranges none. Neither the Conditions of Sale nor the Terms of Service allocate the risk of loss of or damage to a card while the house holds it, and this page will not invent an answer in either direction. If that answer matters to your decision, ask the desk in writing before leaving a card here, and get the reply in writing. The only published term that touches it is the liability cap in Terms of Service §13.
What the custody record does give you is narrower than a guarantee and worth knowing exactly: an append-only history with a named member of staff on every transition, a database-enforced rule that one certificate is one live object, and a reconciliation pass that names any card held under a sale the house has since reversed. That is evidence about where a card is and who moved it. It is not cover for what happens to it. The vault.
Operational risk of the house#
Minthouse runs a server, and a server can be compromised. The relevant question is what a compromise reaches.
- The settler key is a hot key held by the auction house server. A thief holding it can lock bidders' free balances against invented lots and settle locked amounts to the immutable treasury, an address the house already controls, no sooner than two minutes after each lock. It can never send funds to an attacker's address, because no function takes a destination.
- The guardian key can pause the contract and can terminally revoke the settler. It can never move funds and can never appoint itself settler; that power is absent from the contract rather than merely guarded.
- The database holds the auction record. It is append-only where it matters: the ledger and the audit trail are not rewritten, and the event chain is hash-linked, so a silent edit of history breaks every hash after it.
The full analysis, including what each compromise cannot do and how it is recovered from, is Threat model.
Smart contract risk#
BidEscrow is on its sixth version. Five versions had defects, several of them serious, and every one of them is documented by name in the version history rather than quietly superseded. The honest inference from that record is not that the contract is now perfect; it is that a contract holding customer funds should be assumed to contain defects nobody has found yet.
| Assurance | What it covers |
|---|---|
| Two independent audits | v5 was reviewed separately by two parties; both produced a v6 candidate and the better one became the base. Eight defects were found by one audit and missed by the other. |
| Ten-lens expert panel | Run over the merged result with adversarial verification. 37 findings raised, 26 refuted on verification; every survivor was LOW. |
| Test suites | 161 Foundry tests and 934 Node tests pass against this version of the contract. |
| Static analysis | Slither: 21 results in 6 families, all triaged. |
| Source verification | Any deployment the house publishes must be an exact byte match to the published source, at 0 differing bytes, metadata included — the steps to verify one are published. |
| Not covered | No formal proof of the full state machine. No bug bounty currently running. No insurance of any kind on escrow balances. |
Network and third-party risk#
- The chain. Minthouse does not operate, and is not responsible for, any blockchain, wallet software, or RPC provider, including congestion, outages, reorganisations and forks. Payments are booked at 40 blocks precisely because shallower depths are replaceable.
- Network fees. Yours, and not refunded, including on overpayments returned in kind and on reissued invoices.
- The settlement token. USDC is issued by a third party. Minthouse does not issue it, does not guarantee its peg, and cannot make a holder whole if the issuer fails or freezes an address.
- The onramp. Peer Pay operates under its own terms. A failed, delayed or cancelled order is a dispute with the provider, and it does not change the fact that your invoice is due in 10 days.
- The cash-out. ZKP2P is an open protocol. Fill times depend on open buyer demand and are estimates rather than promises; a fill dispute lives in the protocol's own on-chain rules, and Minthouse is not a party to it.
- The sign-in provider and the grading companies. Third parties, under their own terms.
Market and collectible risk#
Collectibles are not investments, and the house does not present them as any. Prices can fall, sometimes sharply and sometimes permanently. An estimate is the specialist's opinion of where a lot may sell, not a valuation, not a floor, and never a promise. Prices realized describe an auction market on a particular day.
Nothing on this platform is investment, financial, tax, or legal advice; no lot is offered with any expectation of profit; and nothing here is a security, a fund, a managed product or an offer of investment services.
Two mechanics worth understanding before bidding, because both cost money:
- A bid is an irrevocable offer. It cannot be lowered or withdrawn. A mistyped maximum is binding, and the house's discretion to reject an erroneous bid is a discretion rather than a right you hold.
- The fee is on top. Estimates never include the auction house fee. A $50,000 hammer is a $52,875 invoice.
Privacy on a public chain#
Where escrow collateral is enabled, the lock amount equals your standing maximum plus the published fee, permanently and publicly. Anyone watching the chain can therefore infer what you were willing to pay, and can keep that inference for ever. Nothing anyone can do will delete it. If that matters to you, bid on a deployment where the escrow is off, or accept the disclosure knowingly. See What is revealed.
This deployment#
The catalogue is real consignments only, and a won lot ships. The platform is real: accounts, the auction engine, bids, invoices, the ledger and the audit trail all work as documented, and the Peer Pay rails are live, so a payment you choose to make through them is a real payment.
The on-chain bid escrow is not enabled on this deployment. Bids are not chain-collateralised, and the escrow disclosures above apply only on a deployment that runs the escrow.
Any address presented as a Minthouse bid escrow for minthouse.io is not ours, and funds sent to one are lost to whoever controls it. The cash-out escrow described in Terms of Service §7a is separate mainnet infrastructure and does move real funds; do not confuse the two.
What to do about all this#
Three things, in the order they reduce risk most:
- Withdraw what you are not bidding with. Free balance in the escrow is encumberable; the same balance in your own wallet is not. The exit is unconditional and the timelock is one hour.
- Claim, don't just request. A ripened withdrawal that has not been claimed is still reachable by a lock. The claim is one transaction and it cannot be blocked.
- Read Guarantees and limits before depositing. It is the page that says what the contract will and will not do for you, and it names the exceptions in the first screen rather than at the bottom.