Settlement contracts

available[domain, requester] = deposited − settled − active reservations

deposit and depositWithAuthorization pull the domain's configured payment token into escrow, verify an exact balance delta, normalize atomic units into μUSDC, and increase deposited. Settlement tokens must expose 6–36 decimals; escrow initialization, Native Chain governance, and runtime domain loading all reject fewer than six because an individual micro-USDC payout would not always be representable. Native Chain owns the authoritative active-reservation ledger because requests do not transact with the settlement chain. settleBatch verifies each execution, enforces request/model and execution replay nullifiers, aggregates transfers, converts μUSDC payouts back to exact token units, increments cumulative settled, and records the compact result.

There is no general live-domain withdrawal. During clean retirement only, governance first pauses the escrow; each requester may then withdraw deposited minus settled minus reserved credit. The escrow tracks total protocol-accounted custody independently from its raw token balance. The verifier is permanently bound to that escrow at deployment and atomically requires paused=true and accountedCustodyMicros=0 in the retirement transaction. Unsolicited direct token transfers are therefore harmless dust: they neither satisfy nor block retirement and never erase user liabilities. Governance may sweep excess before retirement for operational cleanliness, but retirement safety depends only on zero accounted custody.

The proof covers a settlement-domain ID computed from chain ID, token, escrow, and verifier; it also covers validator set ID, a time-bounded batch nonce, and the ordered hash of every settlement tuple. Each tuple carries the validator-certified inputHash, ordered modelSetHash, ordered model IDs, schemaHash, deadline, and expected model count. A batch either validates and applies as a whole or reverts. The nonce embeds validUntil in its high bits and must expire no more than five minutes in the future. Each domain uses separate API-deposit and coordinator-settlement EOAs: their nonce streams must never be shared across processes, because a replacement race can delay an otherwise valid settlement until its observer anti-equivocation lease expires. The contract rejects more than 64 executions; the deployed off-chain request cohort cap is 32. The measured 64-execution distinct-requester/distinct-servicer maximum remains below the 29M safety budget.

• The active verifier set ID must match the payload.
• servicerPayment + foundationFee must equal cost.
• The cumulative request spend cannot exceed the reserved budget.
• A request/model pair and execution ID can settle only once.
• Only the final item for a request can release its unused reservation.

Applications import ITakusenResults instead of the administrative escrow implementation. protocolVersion returns 2. requestState exposes inputHash, modelSetHash, schemaHash, deadline, expectedModels, terminalModels, successfulModels, and the only request states v2 can emit: NONE, ACTIVE, FINALIZED, or FAILED. Execution states are NONE, PENDING, SUCCESS, FAILED, or BUDGET_EXHAUSTED. ACTIVE begins when the first model result is published on the results contract and the request remains open; before that, NONE means only that this result contract has no published state and cannot distinguish an admitted off-chain request from an unknown ID. requestModels returns the canonical ordered bytes32 IDs committed by modelSetHash.

ITakusenResults.RequestState memory request = takusen.requestState(requestId);
require(request.status == ITakusenResults.RequestStatus.FINALIZED);
require(keccak256(abi.encode(modelIds)) == request.modelSetHash);
require(request.terminalModels == request.expectedModels);

ModelResultFinalized is emitted for every terminal model with the public execution-status code. RequestFinalized reports expected, successful, and terminal counts; terminalReason is 0 when at least one model succeeded and 1 when none did, identically on TakusenEscrow and TakusenResultRelay. TakusenOutput provides strict boolean, integer, and choice decoding and schema validation. TakusenBooleanConsumer owns a deterministic strict-majority threshold; a resolution caller can provide evidence but cannot choose policy. Ties and sub-majorities fail, and early resolution succeeds only after one side has already reached the same irreversible strict majority. TakusenResultRelay implements the same ITakusenResults lifecycle, ordered model discovery, counts, and schema commitments on non-paying chains.

Validator G1 public keys are stored after applying their BDN roster coefficient. Installation rejects infinity, zero-weight, malformed, and non-prime-subgroup G1 points using the EIP-2537 G1MSM subgroup check. A proof supplies a non-infinity G2 aggregate signature and a least-significant-bit-first signer bitmap. The verifier aggregates selected keys, rejects an infinity aggregate key, checks strict stake weight, hashes the 32-byte digest to G2, and performs one pairing equation using the Prague BLS12-381 precompiles.

Escrow, token, and bridge use UUPS upgradeability with explicit upgrader roles; escrow and bridge also expose pausing roles. Operational policy requires Native Chain validators to authorize the exact action digest and the governance executor contract to execute it in nonce order. Roles are a contract capability; the deployed ownership and operational ceremony determine the real security boundary.