Sign the constitution.
Owners state goals, bounds, and user-protection invariants in a versioned specification that can be checked.
A proposed pathpast bridge signers.
ARCHITECTURE BRIEF / JUNE 2026 / NOT A DEPLOYED NETWORK
A validity proof crosses the boundary. The destination verifies it for itself, then a contract decides what that evidence is allowed to do.
A validity rollup proves its activity upward to a base chain so withdrawals can settle. Nothing in the idea of verification requires the checker to be that rollup's own base layer. Re-point the evidence sideways: 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 an invalid message becomes true.
The useful distinction
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.
Verify, then act.
The simple diagram is conceptual. A real corridor also has finality rules, provers, relayers, verifier upgrades, custody, and incident controls.
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.
Settlement becomes a business surface.
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 gate a treasury payment, a trade, a loan, or an issuer action.
- STRATEGIC MARKET
- Stablecoin and RWA issuers that need one rulebook across systems.
- FIRST WEDGE
- A controlled treasury or settlement corridor with measurable operations.
- 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.
No keys for the agent.
The Shadow Agent is a forward assurance design. It is not Suwappu's trading-agent API and no implementation is claimed here.
Observe and draft.
Software compares behavior with intent, identifies drift, and prepares a change with explicit proof obligations and rationale.
Gate every change.
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.