[heifner]

Summary

Bonding a sysio.synd request is what releases its deposits. This adds an underwriter to batch_operator_plugin that any depot account can run, enabled by batch-underwriter-account, with or without the relay. The team runs one at launch, at zero fees; others can run their own, more so once fees are on.

What it does each poll

1. Verifies each statement against its outpost. A request states the outpost, the depot epoch and the digest of the envelope the depot accepted. Each outpost keeps its own write-once record of every envelope it emits, the keccak256 of the canonical bytes, which is the protocol's epoch digest (Ethereum OPP.outboundEnvelopes, Solana's outbound EnvelopeLog). The underwriter reads that record at finality and bonds only when it carries the statement's digest, so whether a statement is true is checked against the outpost alone (amounts, states and windows still come from the depot's tables). A request can be verified only while its outpost still holds the record: 200 epochs on Ethereum by default, but only the last 10 records on Solana, so a Solana request must be verified within about 10 epochs or sysio rules it. Before setoutpost replaces an active outpost deployment, that chain's OPEN requests should settle.
2. Bonds each verified OPEN sysio.synd request, oldest first, for its whole remainder, within the token's exposure cap (batch-underwriter-max-exposure, counting bonds not yet claimed) and the account's balance.
3. Cranks sysio.synd, which releases what bonding allows and issues the next request: every poll while an envelope request is in play or has an outcome sysio.synd has not acknowledged, otherwise every 5 minutes.
4. Approves its requests after the challenge window, judged by chain time, claims them once approved or ruled VALID (and again while yield the pool could not yet cover is owed). Every 10 minutes it claims what a forfeited bond earned, which pays it into sysio.liq so the request can be pruned, and prunes sysio.bond / sysio.synd.

When it waits

Condition	Effect
An outpost cannot be read	That chain's requests wait
The outpost holds no final record for the statement's epoch	The request waits
The outpost recorded another digest for that epoch	Never bonded; an error log names both digests
The node cannot serve a chain (no RPC client, wrong chain id)	That chain's requests wait; the others go on
No cap, over the cap, or too little balance	The request waits
The sysio.andon cord is pulled	Nothing is bonded, approved or claimed until it clears
A request is challenged (HELD)	Reported, whether or not we bonded it
A bond of ours is ruled INVALID while the node runs, even one since claimed or pruned	Bonding stops until a restart; approvals and claims go on. A forfeited bond's principal is not returned
A table read fails, or a row behind one of our bonds does not decode	The pass does nothing, so no bond drops out of the cap

Each is logged on every poll it holds; deduplicating those lines is left to log tooling. Pushes are built in a read window and submitted from the main thread; only the signature is made on the polling thread.

Signing

Each role signs with the one operator-configured WIRE signature provider, of any key type, whose key alone satisfies its authority on chain: <operator>@active for the relay, the configured permission for the underwriter. At startup the node also checks that the key's signatures recover to it and that the authority may declare every action the role pushes. The relay previously signed with the first WIRE K1 provider on the node, which would be ambiguous once the underwriter's key is there too. With a dedicated permission, link it to sysio.bond::accept, approve, claim, prune and sysio.synd::crank, pruneenv only.

The node exempts the accounts it signs as from subjective CPU billing: both roles push on a schedule that loses some pushes, and billed failures would soon have the node refuse every transaction the account signs. An operator node must therefore not expose its transaction push API publicly.

Signers are chosen once, at startup. Each poll checks that each role's key still satisfies its authorization; after a rotation the underwriter stops pushing and the relay logs until the node is restarted with the new key.

Tests

• underwriter_tests: statement and row decoding, and the plan: bonding only a statement whose digest the outpost recorded, never one it recorded differently, waiting without a record (or with one for another epoch or chain); remainder, oldest first, the cap across unclaimed bonds and the same pass, balance, missing cap, malformed or mismatched statements, other issuers, approval at the window's end, claims and owed-yield claims, held, blocked and forfeited requests (including a bond since claimed or pruned), the freeze and the halt.
• read_emitted_envelope_digest_reads_the_outpost_record (Ethereum) and decode_envelope_log_digest_finds_the_epochs_record / envelope_log_shape_is_checked_for_the_underwriter (Solana): the record read, an absent record, a record for another epoch, malformed or oversized data, an ABI without the view, and a drifted IDL.
• The underwriter's own state: bond rows that do not decode or whose request did not, amounts beyond the asset range, the scan window, the crank's work test, remembered bonds, which forfeit halts, and an unreadable chain holding back only its own reads.
• role_config_tests: option parsing and the one-provider rule.
• chain_plugin_tests: key_alone_satisfies against single, owner, delegated and weighted authorities, and permission_satisfies_link against linked, unlinked and sysio.any actions.
• sysio_dispatch_tests/a_bond_releases_the_envelope_and_comes_back_after_the_window: a real delivery opens a request whose statement names the accepted digest, which is also the keccak an outpost records for the envelope (the canonical oracle); one account bonds it, a crank releases the deposit, approval is refused until the window passes, and the claim returns the whole bond.

Related PRs: Wire-Network/wire-tools-ts#120 runs flow-syndication-underwriting against the underwriter.

[huangminghuang]

[P2] Detect invalid bonds even after their yield is claimed

If an existing bond is ruled INVALID and has accrued yield, anyone can call the permissionless sysio.bond::claim(request_id, underwriter) before the next poll. That settles the forfeited yield and sets the bond's paid flag; it does not return the forfeited principal. This filter then hides the invalid request from note_forfeits, so the node continues bonding instead of halting after the loss.

Detect newly invalid bonds independently of their paid flag. A focused reproduction with an INVALID request and its paid bond returns no forfeiture from this function.

[heifner]

Fixed in ec19393. A forfeit is now any request the underwriter bonded that is ruled INVALID, whatever paid says. The node remembers the requests behind its bond rows, so a claim followed by a prune of the row is caught too (a_forfeit_is_reported_after_anyone_claims_or_prunes_the_bond).

[huangminghuang]

[P2] Retry claims when a paid bond still has outstanding yield

sysio.bond::claim can return the principal and set paid=true while retaining yield.owed_wire when the yield pool cannot cover the full payout. The existing contract test unbacked_yield_survives_pruning_and_never_repays_principal demonstrates this state and the subsequent claim needed to settle it. This condition permanently skips that bond, leaving yield uncollected even after funding becomes available and preventing its rows from being pruned.

Decode the remaining yield into bond_position and schedule claims while either principal or yield remains owed. A focused reproduction with an APPROVED request and a bond containing paid=true, yield.owed_wire=1 currently produces no claim.

[heifner]

Fixed in ec19393. bond_position decodes yield.owed_wire, and an APPROVED or VALID bond that is paid with yield still owed is claimed again each poll until the yield is paid (owed_yield_is_claimed_after_the_principal). Forfeited bonds are still never claimed.

[valthon]

The daemon should only underwrite statements it has explicitly verified to be true.

Currently, verification records a confirmed epoch for each outpost, and the planner accepts requests at or before that epoch. Although it decodes the statement’s digest, it never checks that digest against the verified evidence. This relies on sysio.synd constructing the correct statement.

Can we make the verification result identify the actual statements it proves—binding the chain, epoch, and envelope digest—and require that evidence before scheduling accept? Verification through a chained tip is fine, provided the proof is explicitly tied to the statement being underwritten.

Please add a negative test showing that a request with the right chain and epoch but an unverified or mismatched digest is not underwritten.

[heifner]

Changed in ec19393. Verification no longer goes through the depot. For each OPEN request the underwriter reads, at finality, the outpost's own write-once record of the envelope it emitted for the statement's epoch (Ethereum OPP.outboundEnvelopes, Solana's outbound EnvelopeLog; both hold the keccak256 of the canonical envelope, which is the epoch digest), and bonds only when it equals the statement's digest. A mismatch is never bonded and is logged with both digests; no record means the request waits. Negative tests: a_digest_the_outpost_did_not_record_is_never_bonded (right chain and epoch with another digest, then with no record) and a_statement_without_an_outpost_record_waits (records for another epoch or chain prove nothing). The contract test also checks that the statement's digest is the keccak an outpost records for the delivered envelope.

[huangminghuang]

[P2] Keep emitted records for the full verification window

This lookup searches only the current Solana EnvelopeLog, but the current wire-solana origin/next program hard-caps that log at 10 records (opp_states.rs:116, with eviction before age pruning at lines 864-872), even though the configured retention is 128 epochs. Its append_caps_at_ten_dropping_oldest test confirms that emitting record 11 removes epoch 1. If an OPEN request waits while ten newer envelopes are emitted, this reader returns no digest forever; because syndication processes a pair oldest-first, that request also blocks later automatic progress for the pair. Raise/migrate the on-chain cap to cover the retention window, or add a historical proof/recovery path and a cross-repository test.

[heifner]

Confirmed: MAX_TRACKED_ENVELOPES = 10 evicts the oldest record before the 128-epoch retention applies, while Ethereum keeps 200 epochs. For launch we are documenting this rather than adding state: the README now says a Solana request must be verified within about 10 epochs, after which sysio rules it. The underwriter verifies and bonds a request within a poll of its issue, so this applies only when one waits that long (the node down, a cap, the balance, a pulled cord).

[huangminghuang]

[P2] Preserve verification for requests from the previous deployment

When setoutpost changes an address, drop_stale discards the old client and all outstanding requests are subsequently checked only against the new deployment. The bonded statement contains chain, epoch, digest, and token, but no deployment identity, and sysio.chains::setoutpost permits replacing an active deployment without first draining unresolved requests. A valid OPEN request from the old deployment will therefore read as missing or contradictory on the new one and can stall its oldest-first pair until manual adjudication. Gate redeployment on draining those requests, enforce record migration, or retain versioned readers keyed by deployment.

[heifner]

Confirmed. Replacing an active outpost deployment is a rare governance step, so we are documenting the procedure rather than keeping versioned readers: before setoutpost replaces a deployment, let that chain's OPEN requests settle. It is in the README.

[huangminghuang]

[P2] Avoid scanning every account's bonds on each poll

read_all_rows fetches and ABI-decodes the entire global sysio.bond::bonds table every 15 seconds, then filters locally for this underwriter. The table has no underwriter index, and this all_rows path deliberately disables the row limit and read deadline, so unrelated accounts can grow the work and memory for every underwriter node without bound while holding a controller read window. Add an underwriter secondary index or maintain a bounded, paginated cursor/cache instead of doing a global full-table read per pass.

[heifner]

Changed in cd148fb: the bonds read now starts at the scan window, like the requests read. The table is keyed by request id first, and the window holds every request the underwriter has a bond on, so the read covers only requests still in play instead of the whole table. No contract index needed.

[huangminghuang]

[P2] The lower bound still leaves the suffix unbounded

The bound skips rows before from, but the primary key is (request_id, underwriter), so all_rows still copies and ABI-decodes every account's bond at every later request ID. A single OPEN envelope can pin underwriter_scan_from indefinitely (including the documented case where its outpost record has expired) while later global bond rows keep accumulating; all_rows also ignores limits and deadlines. Each 15-second pass can therefore grow without bound and monopolize a controller read window. Query an underwriter index or exact (request_id, underwriter) keys, or use bounded pagination/state.

[heifner]

Agreed on the mechanism: both reads walk every row from the cursor on, and all_rows has no limit or deadline. Leaving it for launch. The cursor is the oldest envelope request still in play, so the window is about one challenge window of requests: roughly 30 per pair, so about 70 request rows and 70 bond rows per pass. It grows only while a pair is stuck on a request sysio has not ruled, or while someone pays RAM for requests inside the window, and the cost is a slower pass on the underwriter node, never a wrong bond. The bounded form is to find requests through sysio.synd::envelopes and read sysio.bond by exact key; that is a follow-up for when third parties underwrite.

[huangminghuang]

[P2] Advance pruning past skipped requests

Every housekeeping pass restarts sysio.bond::prune at request 0. The contract increments its limit counter only for a request it deletes or one with paid bond rows; OPEN/HELD, retained, unresolved-token, and unpaid terminal requests consume no budget. A sufficiently large early unprunable prefix is therefore rescanned without bound on every ten-minute transaction, eventually exhausting CPU before later paid rows can be reached. Persist and wrap a scan cursor, and/or change the contract limit to count examined requests as well as mutations.

[heifner]

Measured on master's sysio.bond: a prune(0, 64) walk reaches the 150 ms transaction limit at about 7,000 ruled requests still inside their 7-day retention on JIT (about 15,000 on OC; Debug build). sysio.synd issues at most one request per token per active epoch, about 600 to 1,700 per token across that retention, so launch volume leaves roughly 2 to 5 times headroom. Bounding the walk needs the contract to count the requests it examines; that change is deferred and tracked for when tokens are added or epochs shorten.

[huangminghuang]

[P2] Remember a landed accept before its row can disappear

A successful submission is not added to underwriter_bonded; the ID is remembered only if a later irreversible-state poll observes its bond row. If the accept lands, then the system rules the request INVALID and a caller invokes the permissionless claim and prune actions before that poll, the paid bond row disappears while the retained request remains. This node never learns that it owned the forfeited bond and continues bonding despite the promised halt-on-loss behavior. Track submitted accepts as pending and reconcile them with irreversible transaction evidence, or retain the underwriter association on chain through the request-retention period; add a test for this ordering.

[heifner]

Leaving this as is. Missing the forfeit needs all of this inside one poll gap after our accept lands (about 15 seconds of irreversible state): sysio rules the request INVALID, a yield distribution lets the forfeited bond earn something, a claim marks it paid, and a prune erases it. A ruling normally follows a challenge and a hold. The worst case is a halt one forfeit late: balances and the cap come from chain state, so they stay right, and the next forfeit whose row survives a poll stops bonding. Counting a pushed accept as ours instead would halt a healthy node whenever an accept that lost a race to another underwriter was for a request later ruled INVALID.

[huangminghuang]

[P2] Drain pre-request envelopes before redeploying

Waiting for OPEN bond requests is insufficient because an accepted sysio.synd::envelopes row can still be OPEN or WAITING with request_id == 0. After setoutpost, the queue can issue that row's request with the old deployment's digest, while the underwriter has already rebuilt its client for the new deployment; it can no longer verify the request, and the pair stalls until manual adjudication. Require the procedure to clear the chain's pre-request OPEN/WAITING envelope rows too, or retain/version the old deployment reader.

[heifner]

Right: an envelope accepted before setoutpost can still be OPEN or WAITING with no request, and its request then states the old deployment's digest. Fixed in 077c47f: the README now says the chain's sysio.synd envelopes must drain first, those still waiting for a request included.

[huangminghuang]

[P2] Drain the ingress pipeline before redeploying

sysio.synd can be empty while an old-deployment envelope is still finalizing remotely, waiting for sysio.msgch quorum, or under dispute. Its sysio.synd row is created only when consensus later dispatches the attestations. Because setoutpost does not fence old deliveries and relay jobs switch only on refresh, this procedure can drain sysio.synd, redeploy, then have an old digest materialize that the new client cannot verify. Quiesce the old deployment, wait for remote finality and all pending sysio.msgch delivery/consensus/dispute work, and only then drain sysio.synd; or retain/version the old reader.

[huangminghuang]

Is active redeployment intended to be prohibited for launch?

If it is prohibited, the smallest safe pre-launch resolution is to enforce that in setoutpost: reject changing the deployment of an already-active chain, and document live redeployment as unsupported. The current runbook instruction alone still leaves the unsafe transition callable.

If active redeployment is supported, please version deployments by epoch instead of overwriting the address in place: schedule a cutover for a future epoch, have the relay and underwriter select the deployment for the request's epoch_index, and retain old deployment metadata/readers until requests from its epoch range are terminal and pruned. Since the statement already includes epoch_index, allowing only one deployment per epoch should avoid a statement-format change. If same-epoch emergency replacement must be supported, carry an explicit deployment generation through delivery, consensus, syndication, and the signed statement.

[heifner]

Not prohibited. Replacing an active outpost's deployment stays a privileged governance action for an emergency, run with the drain the README describes. The underwriter fails closed across a redeploy: a statement from the old deployment is never bonded, its request waits, and sysio rules it with sysio.bond::rslvvalid or rslvinvalid.

[huangminghuang]

[P2] Keep discovering bonds created below the cursor

next_scan_start advances past an OPEN request when it is not a sysio.synd envelope and no bond for it has been observed yet. The configured account can later call accept on that still-OPEN request through another permission or client; because this read starts at the newer cursor, the new bond is never discovered. It then never counts toward batch-underwriter-max-exposure, so this node may bond beyond the configured cap. Read through an underwriter index (which also bounds the global scan), or enforce and validate exclusive accept activity for this account.

[heifner]

Correct, for a request that is not a sysio.synd envelope request: the node never bonds those, so a bond made on one by hand after the cursor has passed it is not counted. Keeping every OPEN request in the window would let anyone pin the cursor with one unbonded request, and a periodic read from 0 is the full scan again, so 077c47f documents it instead: one underwriter node per account, and no bonding from that account by other means, since a cap counts only the bonds its node makes. The account's sysio.liq balance still limits what it can bond.

[huangminghuang]

[P2] Settle accrued yield before leaving INVALID

A forfeited shadow bond can still owe the yield it accrued before resolved_index. sysio.bond::claim(request_id, underwriter) settles that yield into sysio.liq without returning the forfeited principal and marks the bond paid; fully_paid otherwise prevents pruning it. This branch never schedules that claim, so without an unrelated external caller the request and bond can persist forever and pin underwriter_scan_from. Queue and retry the settlement claim for our INVALID bonds while continuing to treat the principal as forfeited. Do not gate the first attempt only on owed_wire, because that amount is computed when claim settles the yield index.

[heifner]

Fixed in 8567999. Every 10 minutes, with its prunes, the underwriter now pushes sysio.bond::claim for its INVALID bonds that are unpaid or still owed WIRE; the principal stays forfeited, and the attempt is not gated on owed_wire. It rides the housekeeping rather than every pass because a forfeited bond that earned nothing has nothing to claim, so that claim is refused until sysio.bond prunes the request 7 days after the ruling.

[huangminghuang]

Reviewed current head 63c23b5. No new blocking findings; the setoutpost explanation is accepted. Focused local validation passed, and all completed build/test CI jobs are green.