Short answer
An ATCE ruling is the verdict that ATCE, the Adaptive Trust, Compliance and Execution Engine, reaches on each transfer before value moves. It returns allow or deny, a numeric reason code, and a SHA-256 commitment that is the reference hash of the record. The rule is that no transfer moves value outside a ruling. Enforcement is on for every transfer on the live chain jil-mainnet-2.
What is the rule behind an ATCE ruling?
The rule is that no transfer moves value outside an ATCE ruling. This holds inside a sovereign site (one gated Layer-1 deployment for a nation or institution) and between sites. Native, token, currency and corridor release transfers are all ruled, and a release without an ATCE context is refused.
The design principle behind it is that a transfer is a consequence of a ruling. The ruling is not a check bolted onto a transfer. The act also never supplies the facts it is judged on. Identity level, jurisdiction, risk and sanctions state come from on-chain identity records that an authorized attester signed. Any context a holder puts inside a transaction is ignored.
Status, 2026-11-02: enforcement is on for every transfer on jil-mainnet-2, which has ten validators, all operated by JIL Sovereign Technologies, Inc. The consensus engine is self-written, has had no independent audit and has no external verifiers.
What does an ATCE ruling take as input?
ATCE reads three things for each act: the site profile, the identity records of both parties, and the review result filed for that act. From the records it builds a context. A reason code is the stable number that says why a ruling came out as it did.
| Input | What it holds | Where it comes from |
|---|---|---|
| Site profile | Required identity level, risk deny threshold, sanctions flag, allowed jurisdictions, default per-act limit, per-asset limit overrides | Pinned on chain by the reserved system account jil1atce |
| Context | Identity level, attestation present, origin and destination jurisdiction, amount, risk score, sanctions hit | Built from both parties' signed identity records plus the amount of the act |
| Party state | Identity record version, frozen flag and zone, for the sender and for the recipient | On-chain account state |
| Review result | Missing, denied or allowed, with a review hash | Signed by the reviewer key and filed on chain once per act |
The context combines the two parties conservatively. The identity level is the lower of the two. The risk score is the higher of the two. A sanctions hit on either party counts. The origin jurisdiction is the sender's and the destination is the recipient's. A party whose record is missing, revoked or expired makes the context carry no attestation, and the profile then denies the act.
Identity levels run from 0 (none) to 4 (institutional). Risk runs from 0 to 100.
What does an ATCE ruling output?
An ATCE ruling outputs a verdict, a reason code and one SHA-256 commitment. The commitment is unique to the act and is the reference hash of the record. The chain stores the hash. The full record, with the personal data behind it, belongs in a separate write-once store held by JIL, not on the chain.
The commitment binds the act's subject (its unique identity), the profile as applied, the context, both parties' record versions, freeze flags and zones, the review state and the reason code. Change any one input and the hash changes.
On an allow, the chain writes the subject-to-commitment and commitment-to-subject links and emits an atce_ruling event carrying kind, subject, commitment, reason, review hash and an exempt marker. A ruling cannot be recorded without its hash, and no hash or subject is recorded twice.
Status, 2026-11-02: the record writer that files the full record under each hash is built and not deployed. The production record store is designed. The commitment is to keep each record for 20 years or more, and storage for the record is allocated for each site when its license is signed. See the record.
What verdict classes does an ATCE ruling have?
The consensus code returns two verdicts, allow and deny. The reason code carries the detail, and reason codes are append-only so a code never changes meaning.
| Code | Name | Meaning |
|---|---|---|
| 0 | Allow | Every check passed and the review allowed the act |
| 1 | Identity below required | The lower of the two identity levels is under the profile's level |
| 2 | Origin blocked | Sender jurisdiction is not on the allow-list |
| 3 | Destination blocked | Recipient jurisdiction is not on the allow-list |
| 4 | Amount over limit | Amount is above the per-act limit, or is zero |
| 5 | Risk too high | Risk score is at or above the deny threshold |
| 6 | Sanctions hit | Either party carries a sanctions flag |
| 7 | Profile malformed | No jurisdictions, too many, or a threshold above 100 |
| 8 | Missing attestation | A party has no usable identity record |
| 9 | Review missing | All checks passed, but no review result is filed for the act |
| 10 | Review denied | The reviewer stopped an act every check allowed |
| 11 | Not configured | Enforcement is on but the profile or a trust anchor is not pinned |
| 12 | Account restricted | Either party is frozen |
| 13 | Zone mismatch | The two parties are not in the same zone |
ATCE's outcome is allow or deny. There is no third verdict in the code. Public copy calls a deny that waits for a person a "hold": for example the review denied the act (code 10) or no review result is filed (code 9). In plain terms, allow means value moves and deny means it does not. A denial reverts the transaction. Gas is still charged, and the rejection log carries the reason code and the commitment.
Why does it matter that an ATCE ruling is deterministic?
ATCE is deterministic so every validator reaches the same verdict from the same bytes. Consensus needs that: if two validators disagreed about a ruling, they would compute different state and the chain would fork.
The verdict is a pure function of the profile, the context, the parties and the review input. It calls no network service, reads no clock, uses no random numbers, no floating point and no map iteration order. The review itself runs off chain and enters consensus only as a signed, recorded result, so the ruling stays a function of on-chain bytes.
Anyone holding the inputs can recompute the commitment and compare it with the hash on chain. Enforcement is a one-way state marker, so replaying old blocks reproduces the earlier behavior and reaches the marker at the same height on every node.
In what order does ATCE run its checks?
ATCE runs its checks in a fixed order and reports the first failure, so the reason code is the same on every validator.
- Compute the act's subject, a SHA-256 over chain, kind, sender, recipient, asset, amount and the sender's sequence.
- If the sender is a named protocol account, record an exempt ruling with its own hash and stop.
- Load the site profile and apply the per-asset limit if one is pinned.
- Read both parties' identity records and build the context.
- Read the review result filed for this subject. Missing or already consumed counts as missing.
- Profile well-formed, attestation, identity level, sanctions, risk, origin jurisdiction, destination jurisdiction, then amount.
- Account restrictions: a freeze on either party, then the zone rule.
- The review: missing is code 9, denied is code 10.
- On allow, consume the review, record the ruling, then execute the transfer.
A review can stop an act the rules allowed. It can never turn a denial into an allow.
The rules are deterministic on purpose, and that has a cost. A ruling made only of fixed rules can pass an act that is still wrong, because every rule can be green while the act as a whole is not. This is why ATCE calls an agentic review that challenges the rules before the final ruling. That review is hold only: it can deny or hold an act the rules passed, it cannot release an act the rules denied, and a person decides after a hold. Status, 2026-11-02: the agentic review, the attester and the reviewer bridge are live on jil-mainnet-2. Without an attested identity record an act is denied (code 8), and without a pre-ruling review result an act is denied (code 9). See the agentic review.
How are both parties of an account-to-account move ruled?
ATCE rules the sender and the recipient, each against its own record, because account A may carry a restriction that account B does not. A restricted sender paying an unrestricted recipient is stopped. An unrestricted sender paying a restricted recipient is stopped. Both must clear.
The zone rule is strict: value moves only if both accounts are in the same zone, and an unzoned account counts as zone "none". None against a zone, or one zone against another, is code 13. Both unzoned, or the same zone, passes.
The genesis allocation accounts are not exempt. They are ruled like any account and each needs an identity record. Only three protocol senders are exempt, each with a recorded reason: jil1staking for staking rewards and unbonding payouts, jil1gov for governance deposits and refunds, and jil1ibcescrow for escrow refunds and credits.
Where in the block lifecycle is the verdict produced and recorded?
ATCE produces the verdict while the block executes, inside the same transaction as the transfer, before any value is debited. On allow, the ruling is recorded and then the transfer executes. On deny, the transaction returns an error and reverts.
The ruling therefore becomes part of block execution and of the state every validator agrees on, not a log written afterward. Because a denied transaction reverts, the chain keeps the commitment of an allowed act as state. A denied act leaves its reason code and commitment in the rejection log. On the ACL ledger a bare value message with no sender and no transaction id to rule on is refused outright once enforcement is on.
A corridor release is ruled after the receiving site's arrival gate, and its commitment includes that gate's decision hash.
What happens when something fails?
ATCE fails closed: a missing record, a missing review, an unpinned profile or an unconfigured trust anchor is a denial. There is no bypass to add.
- If the reviewer service is down, no review results arrive, so every ruled act is denied with code 9.
- If an identity record expires, the act is denied with code 8 until the record is renewed at a higher version. This includes records for treasury and genesis accounts.
What is the wire format, and what are the test vectors?
The identity record, the review and the commitment are fixed byte layouts, checked against a shared vector file. A vector is a worked example with known input and output bytes. The values below are for the Rust chain in l1/jil-abci. The ACL ledger uses a different binary encoding with different hashes by construction.
The subject is a SHA-256 over jil.atce.subject.v1|, then length-prefixed chain id, kind, sender, recipient and asset, then the amount (128 bits) and the sequence (64 bits). The commitment is a SHA-256 over jil.atce.ruling.v2, the subject, the canonical profile, context, parties and review bytes, and the reason (16 bits). The attester signs jil.atce.identity.v1| over chain id, account, level, risk, sanctions flag, jurisdiction, expiry height and version, using Ed25519. The reviewer signs jil.atce.review.v1| over chain id, subject, allow flag and review hash.
| Vector | Input | Result |
|---|---|---|
| Subject | chain jil-mainnet-2, kind transfer, jil1alice to jil1bob, asset ujil, amount 1000000, sequence 7 | 2d63d8ea82c80d67cd6787f22a9fb2f73a9ac66e0c575e9976d3476fcfb8041c |
| Commitment, allowed | That subject, review allowed, reason 0 | 31d4247053a60ff31ccfbc2ef24d40f09316ac1649c6e1a2d179d7b6a9f5cb16 |
| Commitment, review denied | Same inputs, review denied, reason 10 | 40b05b77e63247ac3e157a3ecf5558f9725e620c9f1a4ef7422a0e69ed105d94 |
The vector file also covers a missing review, a release, a frozen recipient and a zone mismatch, and a Rust test fails if the file drifts from the code. The off-chain services that build these bytes include the attester and the reviewer bridge, which are live, and the record writer, which is built and not deployed. For the hashes and the checks you can run yourself, see verification.
What edge cases does an ATCE ruling handle?
- A zero amount is denied with code 4. A per-act limit of 0 permits nothing, and so does a risk threshold of 0. An unset value never reads as "allow all".
- A per-asset limit replaces the default in both directions, so an asset can be tighter or looser than the default.
- A site lists up to 10 jurisdictions on the Rust chain, each three uppercase letters. The ACL ledger allows up to 64.
- A review is filed once per act and consumed on allow. A review filed for the wrong subject leaves the real act denied with code 9.
Status, 2026-11-02: the exact deployed values of per-asset limits, attested identity records and each sub-rule above follow the design and code as written here. They are not separately confirmed as deployed.
Questions about the ATCE ruling
What is an ATCE ruling?
An ATCE ruling is the decision the Adaptive Trust, Compliance and Execution Engine makes on a transfer before value moves. It consists of a verdict, a numeric reason code and a SHA-256 commitment that references the record of the act.
What verdicts can an ATCE ruling return?
The consensus code returns allow or deny, with one of fourteen reason codes from 0 to 13. Code 0 is allow. A deny that waits for a person, which public copy calls a hold, is still a deny, with its own code.
Are both sender and recipient ruled?
Yes. ATCE reads an identity record, a freeze flag and a zone for each party. A restriction on either side stops the act, and both must be in the same zone.
Can fixed rules alone pass a wrong act?
Yes, which is why ATCE calls an agentic review that challenges the rules before the final ruling. The review is hold only: it can deny or hold an act the rules passed, it cannot release an act the rules denied, and a person decides after a hold. The review is live on jil-mainnet-2. See the agentic review page.