Destination verificationworking dossier.

WORKBENCH FILE BB-01 / JUNE 2026 / NOT A DEPLOYED NETWORK

Delivery is not authority. A proof crosses the boundary, a verifier checks it locally, and only then does an application earn the right to change state.

A validity rollup proves its activity to a base chain so withdrawals can settle. Nothing in the verification model requires the checker to be that rollup's own base layer. The same arrangement can cross a system boundary: a source system proves an event and a verifier on a destination system checks it before acting.

That is the proposed Bridgeless Bridge design. A compatible destination verifier can replace the signer set that normally vouches for a cross-chain event. A relayer can still carry evidence and a prover still has to produce it, but neither gets a vote on whether a false message becomes true.

Scope of the evidence

The proof can establish that a specified computation or state transition occurred. It cannot establish that an oracle told the truth, a market is solvent, an asset is legally fungible, or the business logic is economically sound. Those are separate assurance problems, and the architecture keeps them separate.

PILOT FILE / OPEN INTERFACE

Evaluation unit: one recurring corridor.

Suwappu and Lattice do not call each other today. Their convergence is a testable architecture, not an integration announcement.

  1. 01 / OBSERVE

    Choose a route that already runs.

    Use Suwappu demand, failures, and route receipts to select one recurring stablecoin or treasury corridor.

  2. 02 / SHADOW

    Form the evidence beside it.

    Express source finality and settlement conditions, then emit an LTP evidence package without moving production value.

  3. OPEN Destination-enforced proof

    No signer, relay, administrator, or arbiter decides whether the message is valid.

  4. 03 / COMPARE

    Let the destination reject.

    Run the verifier and shadow contract locally, then compare cost, latency, liveness, and recovery work with the existing rail.

EXIT CRITERIA

Real value stays off until every line is testable and independently reviewed.

INVALID EVIDENCE
The destination rejects it without consulting an operator.
FINALITY
Source confirmation and reorg behavior are explicit.
UPGRADES
Verifier changes are reviewable, delayed, and reversible where appropriate.
OPERATIONS
Cost, latency, liveness, fallback, and incident ownership are measured.
ASSURANCE
Independent review covers the verifier, application contract, and economic assumptions.

Mechanism plate: local verification.

The simple diagram is conceptual. A real corridor also has finality rules, provers, relayers, verifier upgrades, custody, and incident controls.

Proof-gated cross-chain settlement A source event enters a prover, a relay carries the proof, a destination verifier checks it, and a shadow contract authorizes a business action. Source event Prover Verifier Shadow contract LOCK / BURN / COMMIT PRODUCE EVIDENCE CHECK LOCALLY MINT / PAY / EXECUTE UNTRUSTED DELIVERY MESSAGE INTEGRITY IS CRYPTOGRAPHIC. APPLICATION SAFETY IS ENGINEERING.

The relay affects availability and censorship, but a sound verifier should reject false evidence. The destination contract remains load-bearing and needs audit, change control, and a clear finality model.

Commercial file: the verifier boundary.

A shadow contract is ordinary programmable logic gated by verified cross-system evidence. Authorizing a mint is only the first use. The same permission can govern treasury payments, individual trades, loan actions, and issuer operations.

STRATEGIC MARKET
Stablecoin and RWA issuers that need one rulebook across systems.
FIRST WEDGE
A recurring Suwappu route, reproduced in shadow mode before it carries value.
MEASURE
Latency, cost, availability, signer-risk reduction, and implementation burden.
DO NOT ASSUME
Proofs do not create liquidity, compliance, legal equivalence, or sound market design.
Cover of the FAEI Bridgeless Bridge technical and business brief
Vendor-neutral architecture and business brief, June 2026.

Governance annex: propose-only software.

Suwappu now demonstrates useful controls around machine execution. The report's Shadow Agent is different: a future, propose-only role for governed software change.

INTENT

Versioned constraints.

Owners state goals, bounds, and user-protection invariants in a versioned specification that can be checked.

PROPOSAL

A proposed change.

Software compares behavior with intent, identifies drift, and prepares a change with explicit proof obligations and rationale.

AUTHORITY

Authority outside the agent.

Machine checks, independent review, human approval, and a timelock decide. The agent has no general merge or signing power.

AVAILABILITY
If provers or relayers stop, settlement pauses. The system needs retries, alternative delivery, and an incident path.
FINALITY
A source event must be final enough for the destination's risk policy. Deep reorg behavior needs explicit design.
VERIFIER
The destination's proof checker is load-bearing code. Audits, upgrade controls, and compatible versions are mandatory.
APPLICATION
Proofs authorize the state they describe. They do not repair flawed prices, liquidation rules, custody, or governance.
OPERATIONS
Relayer incentives, censorship, solvency, stale state, cross-domain atomicity, and MEV remain system-design work.