Short answer
ATCE, the Adaptive Trust, Compliance and Execution Engine, applies at two layers. Layer 2 runs inside a sovereign site, between the Tier 1 root and its annexes. Layer 1 runs between sites, on the corridor, on departure and again on arrival. Enforcement is on for every transfer on the live chain, jil-mainnet-2, as of 2026-11-02.
What is a sovereign site, and why is it called a gated garden?
A sovereign site is a sovereign cell: a chain with its own chain identifier, its own token, its own rulebook and its own ATCE profile. The founder rule of 2026-11-01 calls it a gated garden. Value may move freely inside the garden only as far as ATCE rules allow, and anything that leaves the garden goes through ATCE and a corridor.
The site is a tree with three places. The Tier 1 root is the sovereign and holds the corridor credential. A hub sits under a root and holds hub rules. An annex is a leaf under a hub and holds local allow lists and local limits. Depth stops there: a hub under a hub is rejected, and neither a hub nor an annex opens a corridor. Only the Tier 1 root does.
A corridor is the bilateral, ruled link between two sites. A rule set here means the published ATCE rules of one party in one place of the tree. A ruling is the decision ATCE returns for one act: allow or deny, a reason code, and a SHA-256 commitment that binds the inputs and the outcome.
What are the two layers of ATCE?
ATCE has two layers. Layer 2 is inside the site. Layer 1 is between sites. Both call the same engine, so one rulebook format, one verdict format and one commitment scheme apply at each.
| Layer | Where it applies | Whose rules | What it covers |
|---|---|---|---|
| Layer 2 | Inside one sovereign site: between the Tier 1 root, its hubs and its Tier 2 annexes | The site profile, with hub and annex rules in the tree | Account-to-account transfers, token transfers and currency transfers inside the site |
| Layer 1 | Between sites, on the corridor | The sending site on departure, the receiving site on arrival, plus a currency site rule where a stablecoin or another layer 1 asset is in use | A release from one site to another, and a send out of a site |
How does ATCE work inside a site (layer 2)?
ATCE rules on both parties to a transfer. A plain account-to-account move is ruled on the sender and the recipient, because account A may carry a restriction that account B does not. In order, the chain computes a unique subject for the act, loads the site profile, reads both parties' identity records, builds the context from the two records, reads any review result filed for the act, and rules.
The deterministic checks run in a fixed order: profile well-formed, attestation, identity level, sanctions, risk, origin, destination, amount. Account-level restrictions of either party follow, then the agentic review. The outcome is allow or deny. A review can stop an act the rules passed. It cannot turn a denial into an allow.
The ruled paths are the native transfer, the token transfer, the currency transfer and the federation release on the jil-abci chain, plus the matching paths on the acl-app chain. Only three flows are exempt, by name, with a reason recorded in the ruling: staking payouts from jil1staking, governance deposits and refunds from jil1gov, and IBC escrow movements from jil1ibcescrow. The ten genesis allocation accounts are not exempt. A treasury account is ruled like any other account.
See the ruling and identity and attestation.
What is the zone rule?
The zone rule says both accounts must clear and must sit in the same zone. Value moves only if the sender and the recipient are in the same zone. ATCE treats an unzoned account as being in zone "none". A zone against no zone, or one zone against a different zone, is denied with reason code 13. Both unzoned, or the same zone, is allowed.
The founder set this as strict on 2026-11-01. It is not loosened for protocol or genesis accounts. A treasury in the internal zone can pay another internal account, and is denied with reason 13 when it pays an unzoned one. The remedy is to assign zones to the accounts it must pay, not to relax the rule.
A freeze works the same way in both directions. A frozen account on either side denies the transfer with reason code 12. A missing, revoked or expired identity record on either side denies with reason code 8.
How does ATCE work between sites (layer 1)?
ATCE rules on a corridor movement twice: on departure, under the sending site's rules, and on arrival, under the receiving site's rules. Neither jurisdiction has to trust the other's onboarding, because each re-runs its own rulebook against facts that traveled with the value.
- The sending site's ATCE rules on the departing release or send.
- The value crosses the corridor. A release on the receiving cell needs the hub's signature, and its exactly-once slot is keyed by the settlement identifier.
- The receiving site's arrival policy rules on the release. After that, the agentic review is added.
- Each ruling gets its own commitment, and the chain references the record by that hash.
Two paths leave a site on the acl-app chain. A corridor release needs a pinned policy and a context once enforcement is on. An IBC send is ruled like a release: the sender is one party, and the receiver on the destination cell is the other, identified by a receiver key that the attester must attest like any account. A zoned sender therefore cannot send to a receiver key that has no zone. A bare send with no envelope is refused.
On the jil-abci chain, once enforcement is on, a release on a cell with no pinned corridor policy is refused, with or without a context.
Which rule sets must a corridor hop satisfy?
A corridor hop must satisfy up to seven rule sets. ATCE retrieves each one, and one refusal stops the hop. The buyer brings three: the buying Tier 1 root, the hub inside it, and the annex under that hub. The seller brings the same three. When the movement uses a layer 1 asset or a stablecoin, the currency site's rule for that asset is a seventh set.
| Seat | Rule sets ATCE must address |
|---|---|
| Buyer | Tier 1 root, hub, annex |
| Seller | Tier 1 root, hub, annex |
| Currency | The one currency site rule for that stablecoin or layer 1 asset, when one is in use. The buyer Tier 1 and the seller Tier 1 must each have enabled that asset |
A currency site, also called a Shared Resource or Tier 2 in the corridor paper, defines the rules for one stablecoin: what receipt counts, how many confirmations, and which lock or custodian is accepted. It has no hubs and no annexes of its own. A Tier 1 registers once to use it, and that registration covers every hub and annex under that Tier 1.
What happens when a rule set is missing, refused or unpinned?
The hop does not move, and the refusal is recorded. ATCE fails closed. A missing record, a missing review, an unpinned profile or an unconfigured anchor is a denial, and a denied transaction reverts. The rejection log carries the reason code and the commitment.
| Situation | Result |
|---|---|
| A rule set is missing, refused or unpinned | The hop does not move. The refusal is written down. |
| A release arrives with no ATCE context | Refused. |
| The receiving cell has no pinned corridor policy (jil-abci, enforcement on) | Release refused. |
| No review result is filed for the act | Denied with reason code 9. Public copy calls a deny that waits for a person a hold. |
| No attested identity record for a party | Denied with reason code 8. |
Can anything leave a site without ATCE?
No. The founder rule is that anything leaving a site goes through ATCE and a corridor, and no transfer moves value outside an ATCE ruling. The claim is that rule, and nothing wider.
Status, 2026-11-02: enforcement is on for every transfer on jil-mainnet-2, inside a sovereign site and between sites, The attester, which signs attested identity records, the reviewer bridge and the hold-only agentic review are live on the same chain. The review can deny or hold an act the rules passed, and it cannot release an act the rules denied. A person decides after a hold. A site goes live when its policies are pinned: the sovereign writes its identity levels, jurisdiction zones, sanctions lists and limits, and ATCE enforces them from that site's first transfer. The record writer is built and not deployed. Enforcement is a one-way chain-state marker. It cannot be unset by a transaction, and replay of old blocks stays deterministic because the marker appears at the block where it was set.
What are corridor profiles and vote thresholds?
A corridor profile is a later-launch plan, not the recorded fleet in service. The public copy states it as follows: a profile names ten processes and spans at most two shown regions. Eight of the named ten must vote yes. Seven does not pass. Silence is not a yes.
That bar is not the rule of the recorded fleet. The live fleet is 10 permissioned validators, all operated by JIL, with 100% agreement among responding validators and a halt on divergence. That bounds accident and partial compromise. It is not Byzantine fault tolerance against the operator.
The eight-region fleet is a later launch. Four regions are shown and four are shadow, and the shadow regions are not named.
Status, 2026-11-02: designed, as a plan. The corridor profile is not in service.
What is the InterOp multi-hop router?
The InterOp multi-hop router is a designed component that finds an allowed path when the direct move is not allowed. It does not hold funds, set rates or override a site's rules. Status, 2026-11-02: designed. It is not built, deployed or sold.
The design has three parts. A deterministic planner enumerates legal paths by dry-running an ATCE evaluation of every hop against that hop's profiles. An agentic selector chooses among surviving paths. It can drop a path or hold the request. It can never add a path or change a hop. An executor then asks for a real ruling at each hop and never moves value without a ruling hash for that hop.
In the design example, a site sets its USDC limit to 0, so the direct path is denied with reason code 4 and nothing moves. The planner finds a path through a second site that may hold USDC: a corridor hop to that site, then a rail leg out through an InterOp connector. The sites are illustrations, not products.
- Every hop is its own ATCE act with its own unique reference hash. Sanctions and risk are checked at every hop, not only at the ends.
- The maximum is 10 hops, and a rail leg counts. A path may not revisit a site.
- Atomicity: escrowed legs for any path with an irreversible leg, staged commit with reversal where every leg is reversible. A path with no safe mode is rejected up front.
- Fees apply only to a confirmed path. The published corridor hop is 5 basis points of settled gross. Negotiated per-hop rates are designed, not built or published.
The rails and connectors are all designed. None is a live connection. The Ethereum bridge deposit path is the one exercised piece, and its withdrawal path awaits the key ceremony.
Questions about where ATCE applies
Does ATCE rule on transfers inside a sovereign site?
Yes. ATCE rules on every transfer on the live chain, jil-mainnet-2, including transfers inside a sovereign site. In an account-to-account move it rules on both the sender and the recipient.
What does ATCE do when a corridor rule set is missing?
The hop does not move, and the refusal is recorded. ATCE fails closed. A release with no ATCE context is refused, and a missing, refused or unpinned rule set stops the hop.
How many rule sets does a corridor hop need?
Up to seven. The buyer brings a Tier 1 root, a hub and an annex rule set, and the seller brings the same three. When a stablecoin or another layer 1 asset is in use, the currency site's rule is a seventh set. One refusal stops the hop.
Can an unzoned account pay a zoned account?
No. ATCE counts an unzoned account as being in zone "none", so a transfer between an unzoned and a zoned account is denied with reason code 13. Both accounts must clear and sit in the same zone.
Is the eight-of-ten vote threshold in force?
No. The threshold belongs to a corridor profile, which is a later-launch plan. The recorded fleet of 10 validators operated by JIL runs on agreement among responding validators, which is a different rule.
Is the InterOp multi-hop router built?
No. The InterOp multi-hop router is designed. It is not built, deployed or sold, and no rail or layer 1 connector is live. The ruling on each hop is the part ATCE already performs for a single transfer.