Minthouse documentation

Two things bind a sale at Minthouse: the agreements a bidder accepts, and the systems that execute what those agreements say. This site documents both, in the same detail, and does not describe one in language the other cannot support.

Minthouse Markets, Inc. runs auctions for graded trading cards. A consignor sends a slab; the house catalogues it, opens it for bidding, and sells it to the highest bidder at or above any reserve. Invoices are denominated in US dollars and settle in USDC at one to one. On deployments where the bid escrow is enabled, bids are collateralised on chain by the bidder's own wallet, and the house's ability to touch that collateral is limited by a contract it cannot upgrade.

That last sentence is the reason this documentation exists in the shape it does. A platform that asks somebody to put money into a smart contract owes them the contract, not a summary of it, and owes them the summary too, because most people who deposit will never read Solidity. Both are here. The plain-language account of the escrow is How the bid escrow works; the complete function-by-function surface is the contract reference; and the page that reconciles them, stating what is guaranteed unconditionally and what is not, is Guarantees and limits.

What Minthouse is#

An auction venue. In every sale the house acts as agent of the consignor: it catalogues, markets and sells lots on the consignor's behalf, and unless a lot page says otherwise the house does not own what it sells. The contract of sale forms between the winning bidder and the consignor. The house executes it, issues the invoice, and takes its fee.

It is also a marketplace of record. Every price realized is published, bid histories are public with the bidders anonymised, and every ruling the auction engine makes is written into a hash-linked event chain and countersigned as a receipt the bidder can fetch. The house's position is that an auction whose decisions cannot be checked afterwards is not an auction, it is an assertion.

What Minthouse is not#

Five of these are legal statements and one is a practical one. All six are load-bearing, and each is set out at length in the pages named beside it.

• Not a money transmitter, and not a money services business. The house does not accept funds from one person for transmission to another, does not exchange one currency for another, and does not issue or redeem stored value. Every function that moves value is either a transaction the customer signs from their own wallet or a transfer between the customer and Minthouse as principal for goods sold. See Regulatory posture.
• Not a custodian of fiat money, and never an escrow agent for it. There is no house bank account holding a buyer's payment while a card ships, and no point in any flow at which Minthouse holds dollars belonging to a customer. See Custody and settlement.
• Not an insurer. Where the house holds a card in its vault, it undertakes no insurance on that card and arranges none, and the published agreements do not allocate the risk of loss or damage while it is held. The absence is stated rather than left to be assumed, and the custody record says what it does prove. See The vault.
• Not the holder of your keys. Deposits, withdrawals and cash-outs are signed by the wallet that owns the funds. The house holds one operational key, and the contract limits what that key can do to three verbs against locks it created. See Guarantees and limits.
• Not an investment platform. Nothing offered here is a security, a fund, or a managed product, and no lot is sold with any expectation of profit. Estimates and prices realized describe an auction market, not a return. See Risk disclosures.
• Not the grading company. A grade is the opinion of PSA, BGS, CGC or SGC, and Minthouse sells the certified card rather than a promise about a regrade. What the house does warrant, and the remedy when that warranty fails, is in Authenticity and enforcement.

This deployment#

The chapters#

How to read this#

The chapters are ordered so that reading straight through works, but nothing depends on it. If you are here for one thing:

• You are about to bid and want to know what you are agreeing to. Conditions of Sale, then How the bid escrow works. Twenty minutes.
• You are evaluating whether the escrow can take your money. Guarantees and limits first: it names the three bounded exceptions in the first screen rather than burying them, then Threat model.
• You are auditing the contract. Contract reference and Lifecycle and clocks, with the verified source open beside them. Deployments tells you how to confirm the bytecode at the address is that source.
• You are counsel or compliance. Regulatory posture and Custody and settlement are written for you, and both cite the code paths that make the claims checkable rather than asserting them.
• You are consigning a card. Conditions of Sale §7 for what you agree to and what you are owed, at auction or at a fixed price, then The vault for what happens to the object while the house has it, and what the house does not undertake about it.
• You want the whole flow once. How a sale works, end to end.

Conventions#

Amounts are shown as a reader sees them on an invoice, in dollars, and are computed internally in integer cents with no floating-point arithmetic anywhere in the money path. Times quoted for the auction are Eastern; times quoted for the chain are block timestamps in UTC. A monospace name like lockExpiresAt or placeBid is a real identifier in the deployed source, not a paraphrase, and can be searched for.

Where a page states something the house cannot presently do, or a defect an earlier version had, it says so in those words. The version history in Threat model is written that way on purpose: a contract on its sixth version has five versions' worth of mistakes behind it, and the useful document is the one that names them.