What makes federation border enforcement "dual-side"?

Every cross-cell transfer is checked twice by two independently governed parties: the sending cell enforces departure-side checks (cell certification, an explicitly enabled corridor, rolling firewall caps, and independent re-derivation of the value lock) before it will issue a release authorization, and the receiving cell separately enforces an arrival-side check, evaluated in consensus against its own genesis-pinned policy, before it will release value to the recipient.

What happens if a corridor between two cells has not been explicitly enabled?

The transfer is denied. Corridors are default-deny: a corridor between a source and destination cell for a given asset must be explicitly configured and enabled before any value can move across it.

Does the receiving cell simply trust the sending cell's claim that a lock occurred?

No. The settlement layer independently re-derives the claimed lock from the source cell's own registered chain by fetching the specific block and confirming the expected transfer, memo, asset, and amount are actually present, rather than trusting a forwarded claim from a relayer.

Where does the arrival-side check happen?

Inside block execution on the receiving cell, before the transferred value is credited to any recipient account. If the operator has pinned a corridor compliance policy for that cell, every release must carry the required policy context and pass evaluation, or the release is rejected with no state change.

Dual-Side Federation Border Enforcement

Executive Summary

A JIL Sovereign federation is a network of independently governed Sovereign Cells that exchange value through a hub-mediated bridge. Most cross-chain bridges enforce compliance, if at all, at a single point of trust — typically a validator signature the destination chain accepts on faith. JIL's federation border enforces twice, on two independently governed sides of every crossing.

On departure, the sending cell's hub verifies that both cells are registered and certified, that the specific transfer corridor between them has been explicitly enabled, that the transfer sits within rolling and cumulative drawdown limits for that corridor, and that the claimed value lock actually exists on the source cell's own chain — not merely as a forwarded claim. Only then does the hub issue a signed release authorization. On arrival, the receiving cell independently evaluates that authorization, in consensus, against a jurisdiction-scoped policy pinned into its own genesis state, before any value is credited to a recipient.

Core Innovation: Two independently governed enforcement points — departure-side hub choreography and arrival-side in-consensus policy evaluation — each capable of unilaterally denying a crossing and each producing its own anchored evidentiary record, rather than a single trust point either side must simply accept.

Problem Statement

Cross-chain and cross-cell bridges are consistently the weakest link in federated blockchain architectures. Industry losses to bridge exploits stem overwhelmingly from single-point-of-failure designs: a validator multisig is compromised, a relayer's claim is trusted without independent verification, or the destination chain has no way to apply its own jurisdiction's policy to an inbound transfer it did not itself originate.

$2B+

Lost to bridge protocol exploits in 2022 alone (published industry estimates)

Independent enforcement points per crossing, vs. the industry-typical single point

Corridors enabled by default — every pair requires an explicit allow

Why Existing Solutions Are Insufficient

Guardian/validator-signed bridges: a fixed validator set signs a message; the destination chain verifies the signature and mints, with no independent re-evaluation of jurisdictional fit on arrival.
Generic cross-chain messaging protocols: designed to pass arbitrary messages reliably, with no built-in concept of a compliance corridor, a drawdown cap, or a jurisdiction-scoped arrival policy.
Wrapped-asset bridges: the destination mint typically proceeds on a relayer's forwarded claim about a source-chain lock, without independently re-deriving that lock from the source chain's own state.
Centralized bridge operators: a single company's internal policy stands in for enforcement on both sides, with no structurally separate departure and arrival checks.

Technical Architecture

Side	Enforced By	Checks
Departure	Sending cell / federation hub	Cell registration + certification status; corridor explicitly enabled (default-deny); rolling-24h, total, and hard-stop firewall caps; independent lock-proof re-derivation
Arrival	Receiving cell (in consensus)	Genesis-pinned corridor policy evaluated against the transfer's origin and destination jurisdiction before any value is credited

Departure-Side Enforcement (Sending Cell)

The federation hub processes a settlement request only after confirming both the source and destination cells are registered and carry a certified or approved status. It then requires the specific (source-cell, destination-cell, asset) corridor to be explicitly enabled — an unconfigured corridor fails closed rather than defaulting open. The transfer amount, priced to USD, is checked against three independently maintained corridor limits under a database row lock before the settlement is allowed to proceed further.

Independent Lock Re-Derivation

Rather than trusting a relayer's forwarded claim that a source-chain lock occurred, the hub fetches the specific block the claim references directly from the source cell's own registered RPC endpoint, confirms the block's chain ID matches that cell's registered chain ID, and searches the block's transactions for the expected transfer message carrying the exact lock memo, asset, and amount. Only a positively re-derived lock allows the settlement to proceed.

Arrival-Side Enforcement (Receiving Cell)

Each cell may pin a corridor policy scalar into a dedicated storage slot at genesis. When a policy is pinned, every incoming FederationRelease message must carry a compliance context identifying the origin and destination jurisdiction, which is evaluated in consensus — inside block execution, before the transferred value is credited — against that pinned policy. A denial rejects the release outright with no state change. A cell that has not configured an arrival policy runs the legacy, ungated path, so the fail-closed behavior is explicit and operator-controlled rather than silently assumed.

Evidence Traveling With the Transaction

The hub signs the canonical release authorization — binding the settlement identifier, asset, amount, recipient, and destination cell — and anchors the departure-side decision as a settlement event. On arrival, the resulting policy-evaluation decision is attached to the release event so both the departure and the arrival decision are independently anchored and later reconstructable.

Prior Art Differentiation

System	Verification Model	Arrival-Side Policy Gate?	Corridor Default
Guardian-multisig bridges	Single validator-signature check	No	Varies, often open
Generic message-passing protocols	Message delivery guarantee only	No	N/A
Wrapped-asset relayer bridges	Trust forwarded lock claim	No	Open once listed
JIL Sovereign	Independent lock re-derivation + signed release	Yes, in consensus	Default-deny per corridor

Patent Claim

Independent Claim 83: A computer-implemented method for enforcing cross-jurisdictional value transfer between independently-governed blockchain cells in a federation, comprising: at a sending cell, verifying that both a source and destination cell are registered and certified, confirming an explicitly-enabled transfer corridor between them, evaluating a proposed transfer against rolling and cumulative drawdown limits maintained for that corridor, and independently re-deriving proof of a value lock from the source cell's own consensus state rather than relying solely on a forwarded claim; issuing, only if all such departure-side checks pass, a cryptographically signed release authorization binding a settlement identifier, asset, amount, and recipient; and at a receiving cell, evaluating, within block execution and prior to releasing any value, the signed release authorization against a jurisdiction-scoped compliance policy pinned into that cell's genesis state, and rejecting the release when either the departure-side or the arrival-side evaluation denies the transfer.