Regulatory posture
Minthouse is a seller of goods that accepts payment in a dollar-denominated token. It is not a money transmitter, not a money services business, and conducts no activity requiring a money transmitter licence. This page states the position and then tests it, prong by prong, against what the platform actually does.
The house's stated regulatory position, written so that a reader can check it rather than take it. Every claim below names the flow or the code path it rests on. It is a statement of position and not legal advice, and it does not substitute for advice to any reader about their own obligations in their own jurisdiction.
The position, in one paragraph#
Money transmission is accepting currency, funds, or value that substitutes for currency from one person and transmitting it to another person or location. A business that does it is a money services business (an MSB) and needs a money transmitter licence (an MTL) in each state that requires one. Minthouse never does that. Every movement of value on this platform is one of exactly three things: a customer moving their own funds within their own control, a customer paying Minthouse for goods that customer bought, or Minthouse paying a consignor the proceeds of that consignor's own goods. None of them is an intermediated transfer between two other parties, and the house never stands between a payer and a payee who are transacting with each other.
The four prongs, tested#
1. Accepting funds from one person for transmission to another#
The house does not do this, and there is no flow in which it could. Payments run in a straight line between a customer and Minthouse:
| Movement | From | To | What it is |
|---|---|---|---|
| Escrow deposit | bidder wallet | BidEscrow | The bidder posting collateral against their own future bids. Signed by the bidder; the house cannot initiate it. |
| Escrow withdrawal | BidEscrow | bidder wallet | The bidder taking back their own collateral. Signed by the bidder; the house cannot block it. |
| Settlement | BidEscrow | treasury | That bidder paying Minthouse for the lot that bidder won. One immutable destination, fixed at deployment. |
| Invoice payment | buyer wallet | treasury | Payment to Minthouse for goods sold. |
| Consignor payout | treasury | consignor wallet | Minthouse discharging its own debt to the consignor as agent of that sale. |
Read the columns. There is no row in which funds arrive from person A and leave to person B on A's instruction. A buyer's payment is not forwarded to the consignor; it is received by Minthouse as the selling agent, and the consignor is paid what the house owes them, after the buyer protection window, out of the house's own account. Those are two separate obligations that happen to be economically related, which is the ordinary structure of every auction house that has ever existed.
2. Exchanging one currency for another#
The house performs no conversion, at any point, for anyone.
- Invoices are denominated in US dollars and settle in USDC, which is itself denominated in dollars at one to one. Paying a $1,075 invoice means sending 1,075 USDC. There is no rate, no spread, and nothing for the house to take a turn on.
- The house does not buy, sell, or hold any asset other than the settlement token, and does not convert between the settlement token and anything else.
- Where a customer wants to convert dollars into the settlement token first, they do that with Peer Pay, an independent third-party service operating under its own terms. Minthouse is not a party to that relationship, holds no funds at any point in it, and earns nothing from it. See Custody and settlement.
- The reverse, converting the settlement token back to fiat, runs on the open ZKP2P protocol against a public cash-out escrow contract. The customer's own wallet signs the deposit and an independent buyer fills it. Minthouse never holds, routes, converts, or takes a fee on a cash-out.
3. Issuing or redeeming stored value#
The house issues nothing. There is no Minthouse token, no account credit that can be spent anywhere, no gift balance, no prepaid instrument, and no closed-loop value of any kind. The one balance a customer can hold on the platform is their own USDC inside the escrow contract, which is not issued by Minthouse, not redeemable against Minthouse, and not spendable anywhere except as collateral for that customer's own bids.
4. Acting as a payment intermediary between third parties#
The house is never in that position, because it is always a principal or the disclosed agent of one side. In every sale Minthouse acts as agent of the consignor: it catalogues, markets and sells the lot on the consignor's behalf, the contract of sale forms between the winning bidder and the consignor, and the house executes it. Payment flows to the house in that capacity. This is the classic agency-of-seller structure, and the payment it receives is payment for goods, not a transmission it is holding for someone else to collect.
The bid escrow, stated exactly#
This is the part of the platform that most resembles custody, so it gets the most precise treatment on this page rather than the least.
The escrow contract does hold customer property. The house says so in the contract's own header, in those words, and does not characterise it as anything else. What matters for the analysis is whose funds, for whose obligation, and where they can go:
- The funds are the bidder's own, deposited by the bidder from the bidder's own wallet, and credited on chain to the bidder's own address.
- They secure the bidder's own obligation: the irrevocable offer that every bid is. This is a security deposit against the depositor's own contractual liability, in the same position as a bidder's deposit at a traditional saleroom.
- They can reach exactly two destinations. Back to the bidder, on a two-step withdrawal that the bidder signs and the house cannot stop. Or to the treasury address fixed at deployment, as payment of that bidder's own invoice, and only after the house has first locked them against a named lot. There is no third destination reachable by any function, any role, or any sequence of calls.
- The house cannot move free balance at all. Not to itself, not to anyone. See Guarantee 1.
So the escrow accepts value from a person and can only ever return it to that same person or apply it to that same person's debt to Minthouse. There is no transmission, because there is no second person the value can reach.
Holding customer funds in a contract the house operates a key against is a deliberate custody decision, and the house acknowledges it carries licensing questions in some jurisdictions rather than asserting that it carries none. The contract's design answer is to make the custody as narrow and as auditable as it can be made: an immutable destination, a settle that cannot be composed with the lock that funds it, a withdrawal path that needs no house signature, and a public event for every movement. What that design does not do is make the custody disappear, and this documentation does not claim it does. The full account of what the house can and cannot reach is Guarantees and limits.
What the house is, for the avoidance of doubt#
Compliance screening#
Screening is a real gate enforced at real choke points on the server, never in the client, with the vendor behind it swappable by configuration. The design intent is that choosing a vendor is one adapter rather than a re-architecture, and that until one is chosen the platform states plainly which mode it is in.
Where the gates sit#
- Registration. Every account is screened and stamped at sign-up.
- Transacting. A bid or a Buy Now above the configured threshold re-checks the account's status before the engine will accept it.
- Being paid. A payout or a refund is never marked sent to a blocked account. This gate has no threshold and no bypass.
The four statuses#
| Status | Browse | Bid | Be paid |
|---|---|---|---|
| clear | Yes | Yes | Yes |
| pending | Yes | No | No |
| review | Yes | Under the threshold only | No |
| blocked | Yes | No | No |
pending is the state of an unstamped account on a deployment that has a provider configured: it fails closed, and clears itself the moment the vendor answers. A vendor having a slow afternoon never blocks a live auction: the request path reads the cached stamp on the account rather than making a network call inside a bid.
No screening vendor is configured, so the provider is off and every account screens clear. That is the honest state of this deployment today, and it is said here rather than implied by a page describing gates as though they were filtering anybody. The gates themselves are wired and exercised by the test suite; what is absent is a vendor behind them.
Sanctions and wallet screening#
Every user represents, under Terms of Service §10, that they are not named on, or owned or controlled by anyone named on, any applicable sanctions list, and that they are not located in a comprehensively embargoed jurisdiction. Wallet addresses are subject to screening, and payments tied to sanctioned addresses are refused. Settling an invoice with proceeds of crime, and routing payments to conceal their origin or defeat screening, are both prohibited conduct and grounds for suspension and reversal.
What the chain contributes#
An on-chain settlement rail changes what screening can see, and the house treats that as a feature rather than a talking point. Every deposit, lock, release, expiry and settlement is a public event naming the wallet and the lot, permanently. That gives the desk, and any counterparty or examiner, a complete and independently verifiable record of the counterparties the platform has moved value with, one that cannot be edited after the fact by Minthouse or anyone else. The house's internal record is separately hash-linked and append-only, so the two can be reconciled against each other. See Receipts and the event chain.
Publishing an address is not the same as knowing who controls it, and this documentation does not claim the chain performs identity verification. What it provides is an immutable transaction record; what a vendor provides is attribution and list matching. The two are complements, and the second one is a configuration on this deployment rather than a live integration.
Jurisdiction and eligibility#
- Bidders must be at least 18 and legally able to form a binding contract.
- The platform may not be used in any jurisdiction where auctions of collectibles settled in digital assets, or the user's participation in them, is unlawful. Complying with the law that applies to a user is that user's responsibility, and the house says so plainly rather than implying a global licence it does not hold.
- These terms are governed by the laws of the State of Delaware. Disputes not resolved informally go to individual binding arbitration seated in Wilmington, with a small-claims carve-out and a 30-day opt-out. Terms of Service §15.
Taxes#
Sales and use taxes, customs duties, and any other taxes arising from a purchase are the buyer's responsibility. The house does not provide tax advice, and the portfolio engine's cost-basis figures are a bookkeeping convenience rather than a tax position: the FIFO method it uses is stated in the portfolio engine documentation so that a reader's accountant can see exactly what it did.