Multi-chain settlement

Applications should discover chain support through GET /v1/chain rather than hard-coding it. The governed response identifies domain ID, chain ID, active status, token, escrow, resultsContract, verifier, protocolVersion, deposit mechanisms, verifier state, authoritySynchronized, activationReady, and health. A domain must be active, healthy, and authority-synchronized before an application offers it for payment. activationReady proves at the finalized head that the exact current roster is installed with no pending rotation. Validators must then commit the matching finalized authority certificate on Native Chain before governance can admit or activate the domain. resultsContract currently equals escrow, but consumers should use the explicit field and ITakusenResults interface.

Every request, balance, authorization, proof, and settlement transaction carries one governed settlement-domain ID. A failure or pause on one domain excludes that domain from new work without changing the accounting or finality of healthy domains.

The same response reports current and pending verifier set IDs, latest observed block, and deposited, available, reserved, settled, in-flight, and pending-deposit counters for each domain. These fields let operators reconcile accounting, authority synchronization, finality, and reorg health independently.

settlementDomain = keccak256(chainId, token, escrow, verifier)

The governed registry also carries network name, treasury, token decimals, confirmations, and active status. Changing any identity-defining address creates a new ID. A request commits that ID in its canonical input and EIP-712 authorization; an escrow recomputes the ID used in its batch digest from its live chain and contract addresses.

available[domain, requester] = deposited[domain, requester]
  − settled[domain, requester]
  − activeReservations[domain, requester]

• A request selects exactly one domain before authorization and may reserve only that domain's credits.
• Base USDC and BSC USDC are separate pools even when the wallet address and display denomination match.
• The coordinator partitions settlement cohorts by domain; one proof and transaction target one escrow.
• Native Chain must reject any attempt to settle or finalize one request in a second domain. Contract-local nullifiers alone cannot enforce this across independent chains.
• A portfolio UI may sum balances for display, but admission cannot spend that sum. Fungible cross-chain credit requires a bridge or liquidity/rebalancing layer with separate solvency rules.

Cross-chain visibility is separate from payment. The paying settleBatch call executes once on the request's selected domain. A non-paying destination may receive a separately authorized record through TakusenResultRelay, which implements the same ITakusenResults read interface as the escrow.

• The validator-signed relay item binds the source domain, request and execution identities, complete ordered model set, input hash, schema hash, deadline, expected result count, each model's terminal result, and the finalization marker.
• The relay consumes both (sourceDomain, executionId) and (sourceDomain, requestId, modelId) nullifiers.
• Those source-scoped nullifiers prevent replay and prevent a later execution from overwriting the canonical model result.

A domain is introduced gradually so its verifier, observers, relayers, and clients can synchronize before it accepts funds or requests. The active flag is only the user-traffic gate. Every governed domain that is not permanently removed continues following validator rotation.

Protocol budgets and charges use micro-USDC: 1 USDC = 1,000,000. Supported domain tokens have 6–36 decimals, so every individual micro-USDC servicer or treasury payout has an exact atomic-unit representation. Domain adapters convert those values exactly and reject rounding and overflow. The escrow rejects fee-on-transfer or otherwise non-exact deposits by comparing its balance delta with the requested amount.

The active BSC testnet policy uses chain ID 97 and confirmed finality with three confirmations for latency-sensitive request traffic, while custody and authority observations require the governed control-plane finality. It has its own USDC-compatible token, escrow, verifier, governance executor, deposit relayer, settlement relayer, validator watcher cursors, and servicer payout; neither relayer shares a nonce stream with another process, and its credits never satisfy a Base request. BSC was introduced through an inactive governed revision, coordinated watcher/client/payout rollout, and a later activation revision rather than a service-local registry edit.

• A BSC domain must configure the exact BSC USDC token address, decimals, escrow, verifier, treasury, RPC endpoints, finality policy, and supported deposit mechanisms.
• Tokens with 6–36 decimals use exact scaling at the escrow/adapter boundary for deposits, cumulative credits, settlement charges, and payouts. Tokens with fewer than six decimals are unsupported and rejected before deployment or governance admission.
• If the token does not implement EIP-3009, disable depositWithAuthorization for that domain and provide a verified alternative such as approve + deposit. x402 capabilities must match the actual path.
• Verify BDN/EIP-2537 support and measured gas limits on the target BSC environment before reusing the Base verifier and cohort limits.
• Keep BSC deposits and payouts entirely within the BSC domain. Moving value between Base and BSC is a distinct bridge/liquidity feature, not settlement-domain accounting.

Authority evidence remains valid across small finalized-head differences. An observer first requires its finalized head to be at least the certificate's evidence height, then verifies the exact historical block number, block hash, and verifier state at that height.

An active-to-inactive governance revision stops new payment traffic and creates an immutable deactivation generation. It does not remove the domain or stop authority synchronization. The generation identifies this exact inactive period so that a cancellation from an earlier period cannot reactivate the domain later.

Each action begins with a standard Native Chain governance intent binding the domain, deactivation generation, action, monotonic intent nonce, and expiry epoch. Observers reject cancellation, retirement, or abandonment proofs without that exact unexpired intent, even when the external state otherwise appears ready.

1. Govern a cancel intent for the domain's exact current deactivation generation.
2. Finalize the cancellation in the EVM verifier. Cancellation and retirement share the same next verifier nonce, so either action invalidates a proof retained from the inactive period.
3. Certify the finalized cancellation on Native Chain.
4. Only then submit the governance revision that changes active back to true.

If a cancellation command finds that the EVM action already succeeded, it resumes from the recorded action block and completes the Native Chain certificate phase instead of replaying the EVM call.

A domain that has accepted traffic may leave the registry only through clean retirement or separately governed emergency abandonment. Both paths end in a permanent Native Chain tombstone.

• Clean retirement requires a paused escrow, withdrawal of every requester's unused credit, resolution of every obligation, zero protocol-accounted custody, no pending validator rotation, finalized permanent verifier retirement, and a native quorum tombstone.
• The retirement authorization binds the verifier's next monotonic retirement nonce and has at most a 30-minute EVM validity window.
• Direct token transfers that are outside protocol accounting cannot block an otherwise clean retirement.
• A never-active staged candidate may be discarded directly by governance because it never accepted traffic or custody. Discard still writes the same irreversible domain-ID tombstone.
• If a retirement command finds an already finalized EVM action, it resumes the Native Chain certificate phase from the recorded action block rather than replaying the EVM call.