Settlement

Settlement is how Noren accounts for resource consumption. Today the daemon writes local receipts. The settlement chain is Robinhood Chain (chain id 4663): the settlement asset is USDG and gas is paid in ETH. Nothing is deployed on-chain yet; the contracts and the daemon-driven path that batches receipts and anchors them on-chain are coming soon.

Receipt

SettlementReceipt {
  id:               uuid,
  payer:            AgentId,            // who consumed resources
  resource:         "memory" | "compute" | "tool" | "message" | "registration",
  credits_consumed: u64,
  settled_at:       u64,                // unix milliseconds
  memory_record_id: uuid | null,        // set when resource == "memory"
  chain:            string | null,      // e.g. "robinhood-4663" once anchored on-chain
  cluster:          string | null,      // network label (mainnet / testnet) once anchored
  batch_id:         string | null,      // identifier of the receipt batch
  merkle_root:      string | null,      // batch merkle root to be committed on-chain
  tx_sig:           string | null,      // transaction reference of the anchoring tx (tx hash on EVM)
  slot:             u64 | null,         // block number where the batch confirmed
  confirmed_at:     u64 | null,         // unix milliseconds at confirmation
  onchain_sig:      string | null       // populated when flushed on-chain
}

Receipts accumulate in $NOREN_HOME/receipts/working.jsonl. The daemon writes one receipt per resource event. For example, every memory write produces a receipt with resource = "memory", memory_record_id, and credits_consumed proportional to bytes written.

Credit pricing

Each resource kind has a pricing function that maps the underlying unit (bytes, milliseconds, calls) to credits. The pricing functions are deliberately simple and live in one place, so operators can audit them at a glance and downstream integrations can replicate the math without a dependency.

The default for memory writes is one credit per kilobyte (round up). Compute, tool calls, and egress have their own pricing functions that compose the same way.

Planned on-chain flush (coming soon)

The on-chain side is planned as Solidity contracts on Robinhood Chain (built and tested with Foundry), with USDG as the settlement asset and ETH for gas. Credits are meant to be USD-pegged accounting units. The shape under design:

Buy credits: pay USDG into a treasury in exchange for credits at a configured rate.
Consume credits: destroy credits at the point of consumption (memory write, tool call, etc.), with a receipt_hash that binds the on-chain consumption to a specific local receipt batch for reconciliation.
Anchor a receipt batch: commit the batch merkle root so any receipt can be proven against it.

None of this is deployed. The intended production flow is for the daemon to batch local receipts and submit consumption to the contracts; once the transaction confirms, the receipt's onchain_sig can be populated with the transaction hash. The existing field names (tx_sig, slot) are retained for compatibility; on an EVM chain they carry a transaction hash and a block number. This reconciliation path is not yet production.

EVM contracts in the repository

The repository already contains Solidity contracts under agent-os/evm/contracts, with Foundry tests. They are source only and are not deployed (coming soon):

SpendGrantEscrow: a funder parks USDG behind a grant that bounds what a delegated agent may spend (per-call ceiling, total cap, expiry, provider allowlist). Funds for a call sit in a per-call hold and are released on delivery or on an attestor's EIP-712 quality verdict; with no passing verdict by the deadline the hold can be refunded.
BondReceiptVerifier and NorenReputationRegistry: stateless/low-state verifiers that check Noren-signed EIP-712 receipts with ecrecover.
RwaTradeGuard and GuardedTradeExecutor: policy guards (price band, notional cap, rolling spend window) for agent trades of tokenized assets.

Planned economic model

The target model is credits minted against an external payment input, credits consumed at resource-use time, and treasury policy that can route a portion of inflows toward provider payout. Those mechanics require contract audits, authority decisions, and deployment review before they should be treated as operational.

Storage layout

Path	Format	Purpose
`receipts/working.jsonl`	JSONL, append-only	Local receipts. Future flushed receipts can populate `onchain_sig`.

Reading recent receipts

noren chain status --json
noren receipts recent --limit 20 --json
noren chain flush-receipts --limit 20 --json
noren chain receipt-batches --limit 20 --json
# Or via HTTP:
curl -s '127.0.0.1:8421/receipts/recent?limit=20&since_ms=1714938000000' | jq

Verification

noren verify --json cross-checks memory writes against settlement receipts by memory_record_id when the receipt carries one, with owner/resource count fallback for older rows. Missing, duplicate, orphaned, or wrong-payer correlations surface as drift. The daemon is fail-soft on receipt write (a failed receipt does not cancel the memory write), so drift in this dimension is the principal operator-visible indicator of a settlement-side fault.

Backfill

When noren verify reports legacy receipts without a memory_record_id correlation, the operator can repair them with the noren settlement backfill-receipts --json CLI verb (HTTP equivalent: POST /settlement/receipts/backfill). Verify remains read-only; the backfill mutator runs only when explicitly invoked. The verb applies by default; pass --dry-run to report the row_count an apply would change without writing. Dry-run requires the settlement.backfill.dry_run capability; apply requires settlement.backfill.apply. See capabilities for the scope contract. An apply path writes a rollback checkpoint sibling file before mutation, fsyncs both the rewrite and the rename, then emits an operator-issued SettlementReceiptBackfillApplied audit row carrying row_count, rollback_path, and dry_run.

$ noren settlement backfill-receipts --dry-run --json
{"schema":"noren.settlement.backfill.v1","row_count":12,"rollback_path":null,"dry_run":true}

x402 payment rail

Distinct from the internal receipt flush above, Noren includes an agent-to-service payment rail over HTTP 402 (x402). The daemon can pay for metered x402 resources outbound by signing an EIP-3009 transferWithAuthorization over USDG on network eip155:4663. Public seller and facilitator endpoints on Robinhood Chain are coming soon. See Noren x402. The payment rail is a separate concern from anchoring internal resource receipts.

Release

Local receipts and recent-receipt reads are implemented. The Robinhood Chain settlement contracts (credits, escrow, on-chain receipt anchoring) are coming soon and not deployed. The daemon-driven per-intent settlement lifecycle that anchors internal resource receipts is not yet production.

Architecture: the settlement program in the broader system map.
Identity and keys: the same local identity signs capability grants today and is the planned signer boundary for future settlement transactions.
Audit log: settlement receipts pair 1:1 with memory writes; drift shows up here.