16. Settlement

Collaborators pay for their footprint with credits, and a credit exists on Makechain only because a deposit was proved on an external settlement chain. This chapter fixes what may raise a credited cumulative, the single proof kind that imports one, the settlement state the chain keeps, the deadline after which an anchored external identity is no longer trusted, and how governance replaces that identity. The settlement interface fixes the contract's administrative ABI, its immutable-code boundary, its complete storage layout, and its verifier contract; this chapter fixes the beneficiary slot derivation and the amount encoding, because both decide whether an import proof is valid.

16.1 The settlement source and its profile

Tempo is the first settlement source behind an abstract interface. Tempo's configurable accounts do not touch this chapter: the cumulative is keyed by a raw beneficiary address, configurable accounts carry no code, and the proofs never inspect how a deposit transaction was authorized.

A settlement profile is the explicit consensus data that identifies the accepted settlement source and its verification rules. A profile is never a network-name shortcut.

R-16.1. A deployed chain MUST pin the complete settlement profile of its row above, and MUST accept only the proofs that row admits.

R-16.2. A settlement profile MUST include the Tempo chain identity, the certificate and header formats, the settlement contract and immutable runtime-code identity, the accepted asset, the beneficiary storage-key derivation and amount width, the initial threshold identity and checkpoint, and the trust and skew limits.

R-16.3. A settlement profile MUST bind the certified header to the EVM state root, the account proof, the storage root, the beneficiary slot derivation, the amount width, and the strict-advance rule, not only to the certificate encoding.

R-16.4. Compiler artifacts, runtime code hashes, deployment addresses and checkpoints, and fixture-qualified proof bounds are deployment inputs, and the exact storage, artifact, and deployment pins remain a release gate (section 19).

R-16.5. No network may claim a complete settlement profile, and no network may run the positive funded qualification slice, until those inputs are fixed and a compatible deployment exists.

The interface's provisional devnet bounds are not measured limits and are not a mainnet calibration.

R-16.6. A partial profile, a sentinel contract, and a node-local source choice are each invalid.

R-16.7. Tempo certificates use a network-neutral signing namespace, so profile deployment and anchor replacement MUST establish that the accepted group key is unique to the selected Tempo network over its admissible epochs, and a chain-ID label MUST NOT be used to disambiguate same-key cross-network certificates.

R-16.8. If that uniqueness cannot be established, imports are paused until a reviewed profile supplies authenticated source separation.

R-16.9. A settlement-disabled profile is permitted only for an unfunded, nondeployed local diagnostic chain, and a deployed devnet, a testnet, and mainnet MUST NOT use one.

R-16.10. Under a settlement-disabled profile every settlement transition, meaning both credit import and checkpoint refresh, is deterministically invalid, and no alternate credit path, sentinel address, or alternative funding mechanism exists.

A settlement-disabled chain therefore cannot run a positive application slice and cannot qualify any deployment.

16.2 Mint authority

Mint authority is stated completely here. A credit exists on Makechain when the settlement contract's cumulative for a beneficiary rises. A declared USD currency and six decimals establish scale, not value, and a worthless USD-labelled token would otherwise mint real credits.

R-16.11. There is exactly one accepted asset, it is fixed in the settlement contract's code, and only a deposit of that asset through the real deposit path can raise a beneficiary cumulative, so that the contract has:

• (a) no asset setter;
• (b) no discretionary grant path and no mint path;
• (c) no cumulative decrement path and no cumulative reset path.

The value of the accepted asset is the depositor's trust assumption.

R-16.12. Governance MAY install a successor profile, whose reviewed migration MUST preserve every beneficiary cumulative exactly and MUST NOT raise, reduce, or reset one.

R-16.13. Genesis creates no credit ledger and allocates no credits (section 5).

Issuer risk and depeg risk of the accepted asset are stated in the threat model (section 4). The resulting trust bound is informative: credit-mint safety cannot exceed Tempo's live BFT safety, the honesty of its open identity, the value of the accepted asset, and the honesty of Makechain's governance.

INV-SETTLE-05. Only a deposit of the fixed accepted asset can raise a beneficiary cumulative that Makechain will honor.

INV-SETTLE-08. Genesis creates no credit ledger and allocates no credits; the only positive funding transition is a valid strict-advance IMPORT_CREDITS.Credit under the chain's Tempo profile.

16.3 The settlement contract

The settlement contract is a dedicated cumulative-credit deployment on Moderato and on Tempo mainnet. Its administrative ABI, immutable-code boundary, complete storage layout, and verifier contract are defined by the settlement interface. A code fix requires a new deployment under section 16.10.

R-16.14. A deployment whose global issuance, receipt or log claim model, unpaid operator-credit path, or proxy behaviour does not establish the beneficiary cumulative assumed here is not a compatible substitute, and its certificate and header verification code and authentic fixtures MAY be reused only after conformance to this profile.

R-16.15. The contract code MUST be immutable and non-proxy, with no delegatecall, no implementation slot, and no in-place upgrade path.

R-16.16. The fixed code MAY support deposit pausing, administrator rotation, and treasury withdrawals through mutable operational storage, but none of those operations may change a beneficiary cumulative, which only a real deposit of the fixed accepted asset may raise.

R-16.17. All Makechain monetary values, meaning credited, spent, locked, prices, deposits, and charge ceilings, use the unsigned 256-bit Amount type, encoded as exactly 32 big-endian bytes; every arithmetic operation on an Amount, including products and conservation sums, is checked, overflow is invalid, and EVM proof values retain their native canonical RLP integer encoding.

16.4 The single proof kind: credit import

A credit import is an Ethereum MPT storage proof of a beneficiary's monotonic lifetime cumulative, under a Tempo header certified by the Tempo threshold identity currently anchored in state. The settlement interface fixes the proof framing and the verifier contract.

R-16.18. The contract's monetary mapping is mapping(address => uint256) at slot zero, a beneficiary's logical slot is keccak256(left_pad_32(beneficiary) || uint256_be_32(0)), and the storage-trie lookup hashes that logical slot again.

R-16.19. A credit import whose proved cumulative does not strictly exceed the beneficiary's credited cumulative is invalid.

R-16.20. A credit import is uncharged and fully metered (section 10).

R-16.21. The beneficiary is the storage slot's owner and the amount is the contract's cumulative, both proven and never supplied by the submitter.

R-16.22. There is no genesis allocation, no Makechain faucet, no local mint, no operator grant, and no positive-verifier bypass.

R-16.23. Acquiring the accepted test asset from a Tempo Moderato faucet is external to Makechain and is allowed, but funding still requires a real deposit to the dedicated contract followed by a real certified storage proof.

R-16.24. The first successful IMPORT_CREDITS.Credit for an unseen beneficiary creates and charges its ledger under section 9, and a beneficiary may execute INIT_ACCOUNT only after that ledger exists.

R-16.25. IMPORT_CREDITS has a permissionless, metered refresh-only variant that carries a certified header and no storage proof, and that advances the checkpoint and mutates nothing else.

R-16.26. A refresh-only import whose certified header does not strictly advance the checkpoint is invalid.

R-16.27. A credit import performs the same refresh when its header strictly advances the checkpoint, and a failed credit import never refreshes as a side effect.

A healthy identity that never rotates keeps the bridge alive through refreshes alone.

INV-SETTLE-01. A credit import finalizes only when it strictly advances the beneficiary frontier.

INV-SETTLE-04. A relayer can never redirect credits: the beneficiary is the storage slot's owner and the amount is the contract's cumulative, both proven, never supplied.

16.5 Settlement state

SettlementAnchor {
  identity   { group_key, from_epoch, installed_at_makechain_height },
  checkpoint { tempo_height, tempo_timestamp_ms, accepted_at_makechain_timestamp_ms },
  imports_paused
}

from_epoch: u64 is the first Tempo certificate epoch accepted under the installed group key. It is a Tempo epoch, never a Makechain installation epoch and never a value supplied by the proof, and it introduces no autonomous identity following. imports_paused is a governed flag (section 16.7).

R-16.28. State holds exactly one fixed-size SettlementAnchor record together with the per-beneficiary frontiers, and no identity history, interval record, or evidence record is state.

R-16.29. A beneficiary's import frontier is the credited cumulative already kept in its AccountLedger (section 9), a first import creates and charges that ledger once, and a ledger including its locked deposits survives anchor replacement and contract replacement.

R-16.30. Bootstrap and anchor replacement install from_epoch together with the key and the checkpoint, and a refresh changes neither the key nor from_epoch.

R-16.31. Every credit certificate and every refresh certificate MUST satisfy certificate.epoch >= from_epoch.

INV-SETTLE-07. Settlement state is one identity anchor, one checkpoint, one pause flag, and the per-beneficiary frontiers; no identity history, interval, or evidence record is state.

16.6 Source time and the dual trust deadline

Trust in the open identity ends at the earlier of two deadlines:

deadline = min(accepted_at_makechain_timestamp_ms + T,
               tempo_timestamp_ms + T + max_source_skew)

The exact source fields and their codec are properties of the pinned external profile and its conformance vectors, and are never inferred from whichever Tempo or Commonware version a node happens to run.

R-16.32. The pinned external header profile MUST authenticate every source timestamp component, and a source timestamp MUST be normalized before any deadline comparison or skew comparison, as tempo_timestamp_ms = checked_u64(tempo_seconds * 1000 + tempo_millis_part) with tempo_millis_part < 1000.

R-16.33. T, max_source_skew, and Makechain consensus timestamps use the same millisecond unit, and ignoring the authenticated millisecond part, truncating it, mixing units, and overflowing the conversion are each invalid.

R-16.34. The deadline MUST be evaluated in Makechain consensus time, and MUST be checked before any refresh or transition is authenticated under the identity.

R-16.35. A source timestamp ahead of Makechain time by more than max_source_skew is invalid.

R-16.36. A forward settlement transition, meaning a credit import or a refresh, MUST be refused once the deadline has passed, regardless of how the deadline was last extended.

R-16.37. After expiry, only a release installs a new anchor.

A staircase of stale but increasing headers therefore cannot keep an idle identity alive, and re-submitting old headers never renews trust.

INV-SETTLE-03. Forward settlement transitions (credit import, refresh) are refused once the dual trust deadline of section 16 has passed, regardless of how the deadline was last extended.

INV-SETTLE-06. Trust ends at the earlier of the local-acceptance deadline and the source-checkpoint-age deadline, both evaluated in Makechain consensus time before any forward transition under the identity is authenticated.

16.7 The pause flag

R-16.38. imports_paused is a governed parameter, set by a parameter release or an emergency release (section 18), for example when two valid certificates for one Tempo height are observed off chain.

R-16.39. While imports_paused is set, every credit import and every checkpoint refresh is deterministically invalid, and imports already finalized and the credits they funded stand.

R-16.40. The settlement contract's deposit pause and Makechain's imports_paused are independent: the first stops new Tempo deposits, the second stops Makechain credit imports and checkpoint refreshes, neither implies the other, and neither changes an existing cumulative or a finalized credit.

16.8 Anchor replacement

Makechain does not follow Tempo's identity. Tempo's group key is invariant across its per-epoch reshares and changes only on a full DKG, which Tempo's contract owner schedules explicitly through its validator configuration (next_network_identity_rotation_epoch, unset by default), so a rotation is a rare, announced governance event on Tempo's side. Imports pause between a Tempo identity change and the release that anchors the new identity, and nothing is lost, because the contract's cumulative keeps growing and imports resume against the new anchor.

R-16.41. A Tempo identity enters Makechain state only through genesis or through a release whose activation installer writes it (section 18).

R-16.42. No command installs, rotates, follows, or freezes a Tempo identity; a rotation response and an equivocation response are both governance actions (section 18).

R-16.43. An anchor-replacing installer writes a new {group_key, from_epoch, installed_at_makechain_height} and a fresh checkpoint, and MUST preserve every beneficiary frontier and every spent cumulative.

R-16.44. Governance supplies the source key, the epoch floor, the checkpoint, and the pause bit, while execution derives installed_at_makechain_height and accepted_at_makechain_timestamp_ms from the activation block's height and timestamp, never from installer input.

R-16.45. At genesis, accepted_at_makechain_timestamp_ms equals the chainspec genesis timestamp.

R-16.46. If a release also carries an import-pause delta, that delta's value MUST equal the installer's pause bit, or the descriptor is invalid.

R-16.47. The old anchor is not retained, headers certified under it are no longer accepted, and the history of imports made under it is ordinary finalized history.

Reusing an identity known to have equivocated is a governance choice that re-accepts its risk. There is no other exit from an expired or distrusted identity.

INV-SETTLE-02. A Tempo identity enters state only through genesis or a release's activation installer (section 18.6); no command installs or rotates one.

16.9 Guard table

Each settlement transition has its own eligibility condition and its own progress condition.

16.10 Contract and relayer duties

R-16.48. The settlement contract keeps one monotonic cumulative per beneficiary under the profile's pinned storage-key derivation, raised only by permissionless real deposits of the fixed accepted asset.

R-16.49. A successor is a new contract deployment, installed only through SCHEDULE_RELEASE, after a separately reviewed migration carries every predecessor beneficiary cumulative forward exactly and passes the qualification vectors.

Completeness of that migration is a governance obligation, not a proof.

R-16.50. A relayer is a protocol-external role with exactly two duties: submitting credit imports, and archiving the certified headers and state proofs behind pending imports before Tempo prunes them.

R-16.51. The evidence window is a chainspec value whose number is a calibration item (section 19), because an under-archived deposit waits for a later header that still covers it.

16.11 Credits

R-16.52. Credits are non-transferable between accounts and non-refundable, meaning there is no external redemption, and a deposit discharge (section 9) is an internal unlock within one ledger, never a settlement refund.

R-16.53. A mis-directed deposit is permanent: anyone may import it for its beneficiary, and a monotonic lifetime cumulative admits no decrement.

16.12 External certificate profile

Tempo's finalization certificates are decoded by Makechain's own Commonware pin, while Tempo produces them under its own. No second Commonware copy is vendored.

R-16.54. The selected source reference is Tempo 25b216a661c2cac72807174583371b582b75c286, using Commonware 2026.9.0 and Finalization<Scheme<Ed25519PublicKey, MinSig>, TempoBlockDigest> under namespace TEMPO, where TempoBlockDigest encodes the 32-byte Keccak header hash.

R-16.55. The external profile MUST be independently identified and qualified: an authentic Moderato fixture MUST decode, re-encode to identical bytes, and verify under both the current pin and any target pin before a bump goes live.

R-16.56. Neither source agreement alone nor byte-compatibility evidence gathered under a different pin qualifies or pins a deployed Tempo profile.

R-16.57. A Tempo upgrade that changes certificate bytes mints a new profile, activated by release height, and a profile is never sniffed from the bytes, because certificates carry no in-band version.

16.13 Rationale

This subsection is informative.

A single accepted asset fixed in the contract's code exists because a currency label and a decimal count establish scale, not value. The contract keeps a monotonic cumulative rather than emitting events because a cumulative is provable by one storage proof and admits no double import. There is no operator grant at launch because every path that raises a cumulative is a trust assumption that must be stated. The settlement identity is anchored by a governed release rather than followed autonomously: the settlement chain's group key changes only on an explicitly scheduled full key generation, an identity change merely pauses imports without loss, and an autonomous equivocation response would need lineage state whose only purpose is to have something to freeze. The dual trust deadline follows the trusting-period pattern of inter-chain light clients. A transferable credit would be a token, and would reintroduce every obligation the single-asset rule removes.