Deployments and verification

What is live for this deployment, and how a published on-chain deployment is verified against the source in this chapter — so that when an address appears here, a reader can establish for themselves that the code behind it is the code these pages describe.

Current deployment#

Environment

Production — minthouse.io

Bid escrow

Not enabled. No bid-escrow contract exists for this deployment.

Payment rails

Peer Pay — USDC on Base mainnet, chain ID 8453

No bid-escrow address exists for minthouse.io

The on-chain bid escrow is not enabled on this deployment: bids are not chain-collateralised, and no escrow deposit is ever asked of you. Any address presented as a Minthouse bid escrow is not ours, and funds sent to one are lost to whoever controls it.

When an escrow deployment is published#

The escrow chapters document the engine as built and verified. If and when the house enables it, the deployment is published here, in this exact shape, before any lot asks a bidder for collateral:

Network

Published here at deployment

Escrow address

Published here at deployment

VERSION()

Published here at deployment

Deploy block

Published here at deployment

Settlement token

Published here at deployment

Treasury

Published here at deployment

Settler

Published here at deployment

Guardian

Published here at deployment

withdrawDelay · MAX_LOCK_AGE · SETTLE_DELAY

Published here at deployment

Booking finality

Published here at deployment

Runtime size

Published here at deployment

Source ↔ chain

Byte-for-byte comparison, published with each deployment

The explorer links and the byte-for-byte verification appear beside the address the day one exists. Until then, the checks below record exactly how a published address will be verified — they run against any deployment of this source.

Role separation#

The three addresses are distinct, and the contract enforces that they stay distinct across rotations rather than only at deployment:

The constructor refuses settler == guardian, treasury == settler, treasury == guardian, treasury == address(this) and treasury == token.
acceptSettler reverts RolesMustDiffer if the caller is the guardian or the treasury.
acceptGuardian reverts RolesMustDiffer if the caller is the settler or the treasury.
The guardian has no power to propose a settler at all.

What the contract cannot enforce is that three people hold those three addresses. That is a deployment discipline, and it is stated in Threat model as an assumption rather than a guarantee.

Verify it yourself#

Four checks, in the order that makes each subsequent one worth doing. The first is the one that matters: if the code at a published address is not the source published here, nothing else in this chapter describes anything real.

1. Confirm the version and the immutables#

Shell

RPC=https://mainnet.base.org
ESCROW=<the address published above>

cast call $ESCROW "VERSION()(uint256)"        --rpc-url $RPC
cast call $ESCROW "treasury()(address)"       --rpc-url $RPC
cast call $ESCROW "token()(address)"          --rpc-url $RPC
cast call $ESCROW "settler()(address)"        --rpc-url $RPC
cast call $ESCROW "guardian()(address)"       --rpc-url $RPC
cast call $ESCROW "withdrawDelay()(uint256)"  --rpc-url $RPC
cast call $ESCROW "MAX_LOCK_AGE()(uint256)"   --rpc-url $RPC
cast call $ESCROW "SETTLE_DELAY()(uint256)"   --rpc-url $RPC

Every value must match the published table. VERSION must be 6: anything lower is a contract with the holes listed in the version history.

2. Confirm the bytecode is the published source#

A published deployment must be byte-identical to a local build of the published source. To reproduce that comparison rather than take it:

Shell

# build the published source with the same compiler settings
forge build

# the runtime the compiler produced
jq -r '.deployedBytecode.object' out/BidEscrow.sol/BidEscrow.json > /tmp/local.hex

# the runtime actually on chain
cast code $ESCROW --rpc-url $RPC > /tmp/chain.hex

diff /tmp/local.hex /tmp/chain.hex && echo "EXACT MATCH"

Metadata is included in this comparison, deliberately

It is common to strip the trailing metadata hash before comparing, because it changes with the source path and compiler settings. That weakens the check: two builds can differ in ways the metadata records and the stripped comparison hides. The house publishes deployments that match with metadata in, at 0 differing bytes, so there is no reason to accept the weaker test.

3. Confirm nothing can change#

Search the verified source for the things that would make the guarantees conditional. None of them appears:

Shell

grep -n "delegatecall\|selfdestruct\|assembly\|_implementation\|upgradeTo" contracts/src/BidEscrow.sol
# no matches

And confirm there is no proxy in front of the address: cast code above returns the full 9,197-byte contract, not a 45-byte EIP-1167 clone or an EIP-1967 proxy. A proxy would be immediately visible in the length.

4. Confirm the transfer surface#

The claim that underwrites everything else is that the contract can only send tokens to msg.sender or to the immutable treasury. There are exactly two transfer calls and one transferFrom:

Shell

grep -n "\.transfer(\|\.transferFrom(" contracts/src/BidEscrow.sol

Call	In	Destination
transferFrom(msg.sender, address(this), amount)	`deposit`, `depositWithPermit`	Inbound.
transfer(msg.sender, amount)	`claimWithdraw`	The balance's own owner.
transfer(treasury, amount)	`settle`	The immutable.

Three calls, no fourth, and no variable destination anywhere. That is Guarantee 1 and Guarantee 3, checkable in one grep.

Reading the event stream#

Everything the house does to a balance is public from the deploy block onward. To watch one bidder on a published deployment:

Shell

cast logs \
  --from-block <the deploy block published above> \
  --address $ESCROW \
  "Locked(address,bytes32,uint256,uint256)" \
  0x000000000000000000000000<bidder address, 32-byte padded> \
  --rpc-url $RPC

bidder and lot are indexed on Locked, Released, LockExpired, WithdrawReduced and Settled, so a bidder or a lot can be filtered without scanning.

Two traps for an indexer

Locked.amount is the new absolute lock; Released.amount is the amount removed. They do not compose. Summing Locked minus Released gives a wrong answer.
LockExpired is emitted alongside Released, not instead of it. An indexer that handles both without deduplicating will double-count the release.

Both are documented on the reference page, and both shapes were chosen so that an indexer written against an earlier version stays correct without a schema change.

Migration is by withdrawal, not by upgrade

If a deployment is ever superseded, there is no state migration and none is possible: the contracts are independent and neither can read the other. A bidder with a balance in a superseded contract withdraws it themselves, through that contract's own two-step path, and deposits into the new one if they want to keep bidding. This is the cost of having no upgrade path, and the house considers it the correct trade: a contract that could migrate balances is a contract that could move them.

Assurance record#

Check	Result
Independent audits of v5	Two, by separate parties. Both produced a v6 candidate; the better one became the base. Five defects were found by one and missed by the other.
Expert panel over the merged result	Ten lenses with adversarial verification. 37 findings, 26 refuted, every survivor LOW.
Foundry suite	161 pass, 0 fail (5 fork-only skips).
Node suite	934 pass, 0 fail.
Slither	21 results in 6 families, all triaged.
Source ↔ chain	Byte-for-byte comparison, metadata included, performed and published against each deployment.
Formal verification	None.
Bug bounty	None running.
Insurance on balances	None.

Reporting a vulnerability#

Write to notices@minthouse.io with enough detail to reproduce. There is no bounty programme, and the house says so rather than implying one. A report that concerns funds at risk should say so in the subject line; the guardian key exists for exactly that call and pausing costs the house far less than the alternative.