Short answer
ATCE, the Adaptive Trust, Compliance and Execution Engine, enforces the policies each sovereign site writes and pins on chain. A site goes live when its policies are pinned, and ATCE enforces them from that site's first transfer. On jil-mainnet-2 enforcement is on for every transfer, and the one-way switch that makes it binding cannot be turned off.
Who writes the policy?
The sovereign site that operates a cell writes its own policy, and ATCE enforces that policy and nothing else. ATCE does not supply a rulebook. It evaluates each act against the profile the site pinned, and it commits the profile, the facts and the outcome to one SHA-256 hash, so the policy that was published is the policy that ran.
That authorship has a concrete path on the live chain. The transaction that pins the site profile, called ConfigureAtce, is accepted only from a reserved system account, jil1atce. The design document says that account is held by the founder-controlled governance path. On jil-mainnet-2 all ten validators are operated by JIL Sovereign Technologies, Inc., so there the author of the site profile is the JIL governance path. For another sovereign that runs its own cell, the same transaction would come from its own account of that name.
A sovereign site is a gated garden: a cell with its own chain id, validators, currency and compliance policy. A Tier 1 root is the sovereign that holds hubs and annexes. A corridor is the governed route that value takes between sites.
What is the 32-byte policy word?
The 32-byte policy word is a storage value that packs the scalar gates of an ATCE policy into one slot. The code packs it as follows, and unpacking it returns the same values.
| Bytes | Field | Meaning |
|---|---|---|
| 0 | required identity | The minimum identity level, 0 to 4. |
| 1 | risk deny threshold | Deny when the risk score is at or above this value, 0 to 100. A value of 0 denies everything. |
| 2 | flags | Bit 0: deny on a sanctions hit. Bit 1: an identity attestation is required. |
| 3 | reserved | Unused. |
| 4 to 15 | unused | Zero in the packing code. |
| 16 to 31 | per-transaction limit | A 128-bit big-endian ceiling in the asset's smallest unit. A limit of 0 permits no transfer. |
The word holds no jurisdictions. The site's allowed jurisdictions are stored beside it: up to ten, each three uppercase letters. The profile design commits a jurisdiction set by a sorted hash root so membership can be proven without storing the whole set in one slot.
The word fails closed on purpose. Thirty-two zero bytes are the strictest profile, because a risk threshold of 0 denies every score and a limit of 0 permits no amount. An empty jurisdiction list is malformed and denies. Whoever writes a policy has to open each gate deliberately.
A currency can pin its own word. For a currency, an all-zero word counts as unpinned, and a pinned word replaces the site scalars for that currency. A corridor differs: for a corridor, a stored word including all zeros is a policy, and only a missing slot means unpinned.
What is the designed versioned policy table?
The designed policy table is a write-once store of policy bodies, in which the 32-byte word is the name of a row and not its content. The ATCE log records only that name. The table records the chains of rules the name stands for.
One movement policy lists seven links, and a commit is refused unless all seven are present exactly once.
- Tier 1, buyer.
- Hub, buyer.
- Annex, buyer.
- Tier 1, seller.
- Hub, seller.
- Annex, seller.
- Currency, with the asset name as the party (for example ETH).
Each link carries its rules text, a version and a previous policy id. The policy id is the SHA-256 of a domain-separated canonical encoding of the links, sorted so one set of links has one body and one id. The name is therefore bound to that exact body.
| Rule | What the code states |
|---|---|
| Version 1 | Names no previous policy id. |
| Version above 1 | Must name the prior policy id. Version 0 is invalid. |
| Write once | A non-zero marker for an id refuses a second write. The marker is checked before any chunk is staged. |
| Storage | The body is stored as ordered 32-byte chunks under the account jil1policyworm, up to 48 KiB. |
| Field bounds | Tier up to 16 bytes, party up to 64 bytes, rules text up to 4,096 bytes. |
A later version is a new number, and the named row is never rewritten. Because the row is write once, a regulator who holds a policy id can fetch the exact body that id named at the time of a ruling, even after the site has moved on to a later version.
Status, 2026-11-02: the module that defines this table is in the Layer-1 source, and the release path reads it, so that a release event carries the policy id when the pinned word names a stored row. The public design copy says the versioned table and the corridor journal are the design and are not yet the record on every release. This page does not state whether the table holds rows on jil-mainnet-2.
How is a corridor policy pinned?
A corridor policy is pinned by storing a 32-byte word in the receiving cell's federation slot. The word is carried in the corridor configure transaction, FederationConfigure, which the admission check accepts only from the governance account. The write is optional in that transaction: it is skipped when the word is empty.
Presence is the policy. Once a word is stored, every release landing on that cell must carry an ATCE context and pass evaluation before the float moves. A corridor is bilateral, so the allowed jurisdictions are exactly the origin and destination carried in the context, and the scalar gates do the substantive work. The receiving cell's policy is the arrival gate, and the sending cell's policy is enforced on departure.
A release is also refused when the context amount differs from the release amount. This stops a submitter from obtaining a clean decision for a small amount and releasing a larger one.
What is the configure transaction and who may send it?
The configure transaction, ConfigureAtce, pins or rotates the trust anchors and the site profile, and optionally turns enforcement on. Only the reserved account jil1atce may send it. The admission check refuses any other sender with an unauthorized error.
| Field | Content |
|---|---|
| attester key | An Ed25519 public key of 32 bytes, or empty to keep the pinned key. The attester is the identity oracle that signs identity records. |
| reviewer key | An Ed25519 public key of 32 bytes, or empty to keep the pinned key. The reviewer signs the pre-ruling review result. |
| site scalars | The 32-byte policy word for the site, or empty. Any other length is rejected. |
| site jurisdictions | One to ten codes of three uppercase letters, unique. |
| asset limits | Per-asset overrides of the default per-act limit. The asset code is 1 to 64 bytes and unique. A limit of 0 permits no transfer of that asset. |
| activation accounts | Accounts that must hold a usable identity record before enforcement is accepted. |
| enforce | A boolean, one-way. |
Two other actions are not sent by the policy author. SetAccountIdentity may be relayed by anyone, and the attester signature is the authority. AtceReview may be relayed by anyone, and the reviewer signature is the authority.
How is a policy replaced or rotated?
A policy is replaced by sending another configure transaction. A site that sends new scalars, jurisdictions or asset limits overwrites the stored values, and an empty key field keeps the pinned key. The design documents treat this as the cheaper control after enforcement is on: rotate the attester or reviewer key, and widen the site profile or an asset limit, without a code change. A corridor word is replaced the same way by a later corridor configure transaction. The code read for this page stages the new word with no check against the old one.
Replacement within the scalar word and site profile is an overwrite, not a version. The record of what applied to a past act is the ruling commitment, which binds the profile, the facts and the outcome. The designed policy table is the mechanism that would also keep the superseded body readable, because a later version there is a new id.
Key rotation has one extra rule. Identity record versions only move forward, so after a key rotation the affected accounts are re-attested at a higher version. A site profile that is too strict is loosened the same way, and the design notes that limits and jurisdictions are updatable.
What does the enforcement switch do?
The enforcement switch makes ATCE binding on every ruled path. It is a state marker set when a configure transaction with enforce true executes, and from that block on, no ruled message moves value without a ruling.
- A release on a cell with no pinned corridor policy is refused, with or without a context.
- A release without an ATCE context is refused.
- A transfer is ruled on both accounts, and a missing record, a missing review, an unpinned profile or an unconfigured anchor is a denial (reason code 11, not configured, for the last).
- The parallel executor does not rule, so with enforcement on it moves no value.
The switch is one-way. A request with enforce false after it is on is refused with the message that enforcement is on and cannot be turned off. The reason it is state and not a code constant is replay. A new rule changes the outcome of any block that carries a ruled message, so a node replaying the chain must reproduce the legacy behavior before the marker and the new rules after it, and every node reaches the marker at the same height. Recovery after enforcement is not a code rollback. It would be a coordinated upgrade at an agreed height, which the design documents call a hard fork of the rules.
What must be in place before the switch turns on?
The chain itself refuses to turn the switch on until the following are true, and it states which accounts are missing.
- An attester key is pinned.
- A reviewer key is pinned.
- A well formed site profile is pinned.
- Every listed activation account, and every zoned account on chain, holds an identity record that is present, not revoked, unexpired at the activation height, and passes the site profile on its own. Named protocol flows (the staking pool, the governance authority and the IBC escrow) are exempt as senders.
The fourth condition exists because genesis, treasury, founders, operations and reserve accounts are ruled like everyone else. Without it, the treasury would freeze at the first block after the switch. The refusal lists the first ten accounts that lack a record. The runbook order is: pin the keys and profile with enforce false, have the attester sign and relay an identity record for each genesis account in an earlier block, then send the configure transaction with enforce true.
The same design notes a consequence: an identity record that expires after activation makes that account's outflows deny with reason code 8 until it is renewed at a higher version.
Status, 2026-11-02: the founder confirmed that enforcement is on for every transfer on jil-mainnet-2, inside a sovereign site and between sites. The activation prerequisites are in place and live: the attester key and the reviewer key are pinned, and the attester and the reviewer bridge are running. The agentic review is live and hold-only: it can deny an act the rules passed, and it cannot release an act the rules denied. On the live chain an act with no attested identity record is denied (reason code 8), and an act with no pre-ruling review result is denied (reason code 9). The record writer, in services/atce-rulings, is built and merged and is not running in production. This page does not state the exact profile values or the activation account list.
How does a site go live?
A site goes live when its policies are written and pinned. The sovereign writes its identity levels, jurisdiction zones, sanctions posture, limits and rules. The site profile is pinned with the configure transaction, a corridor policy word is pinned for each corridor, and the attester signs identity records for the accounts the site rules on. Once the policies are pinned and the activation conditions below are met, ATCE enforces them from that site's first transfer. Each site's record store is allocated when its license is signed, and the retention commitment is 20 years or more.
The process belongs to the site. Pinning the corridor word is what arms a corridor, and a cell that has not pinned one refuses every release instead of passing it ungated. Enforcement is its own one-way marker on each chain, set with the same preconditions, so each chain's activation is its own decision.
What must an operator provide?
A sovereign that wants ATCE enforced on its cell supplies the following, and ATCE supplies the evaluation.
- The site profile: required identity level, default per-act limit, risk threshold, sanctions flag, allowed jurisdictions, and any per-asset limits.
- A corridor word for each corridor it receives value on, and a pinned word for each currency that needs its own policy.
- An attester key and a reviewer key, held by parties different from whoever submits transactions. The chain does not check that separation, so key custody is an operational control.
- Identity records, signed by the attester, for every account the activation checklist names, with expiries long enough to cover the soak and a plan to renew before they lapse.
- The account that sends the configure transaction, and a decision about who holds it.
The operator also carries the consequence of a strict word. A misconfigured cell moves nothing, because the defaults deny.
Frequently asked questions
Who writes the policy ATCE enforces?
The sovereign that operates the site writes it. ATCE, the Adaptive Trust, Compliance and Execution Engine, only enforces the published policy. On jil-mainnet-2 the configure transaction must come from the reserved account jil1atce, which the design documents say is held by a founder-controlled governance path.
Can ATCE enforcement be turned off once it is on?
No. The enforcement switch is one-way. A configure transaction that asks for enforcement off after it is on is refused with the message that enforcement is on and cannot be turned off. Undoing it would take a coordinated upgrade at an agreed height, which is a change of the rules.
What must exist before the switch can be turned on?
The chain refuses the switch until an attester key, a reviewer key and a well formed site profile are pinned. It also refuses until every listed activation account and every zoned account holds a valid identity record that passes the site profile, and it names the first ten that do not.
Is the policy rewritten when it changes?
In the designed policy table, no. A later version is a new policy id and the row already named is never rewritten. In the scalar word and site profile the code reads, a later configure transaction replaces the stored value.
Does an unconfigured cell let transfers through?
No, not once enforcement is on. A release on a cell with no pinned corridor policy is refused, and an all-zero policy word is the strictest profile, which permits no amount. Before the switch, an unpinned corridor ran the legacy path.
Is ATCE enforcement on today?
Yes. The founder confirmed on 2026-11-02 that enforcement is on for every transfer on jil-mainnet-2, inside a sovereign site and between sites. The attester, the reviewer bridge and the agentic review are live on that chain. The record writer is built and merged and is not running in production.