Short answer
ATCE, the Adaptive Trust, Compliance and Execution Engine, refuses an act by returning a numbered reason code, and it fails closed: a missing identity record, an unpinned policy or a missing review is a refusal, not a pass. A refused transfer reverts and moves no value. The reason code and the ruling hash are carried in the rejection log. The cost is availability.
When does ATCE refuse an act?
ATCE refuses an act whenever any one of its ordered checks fails, or whenever it lacks a fact it needs. The checks run in a fixed order, so every validator reports the same first failure: the policy profile is well formed, an attestation is present, the identity level is high enough, no sanctions hit, the risk score is under the threshold, the origin jurisdiction is allowed, the destination jurisdiction is allowed, and the amount is above zero and within the limit.
Then ATCE checks both parties' account state: a frozen account on either side refuses the act, and so do accounts in different zones (no zone counts as zone "none"). Last comes the pre-ruling review by the agentic reviewer, which can stop an act the checks allowed and can never turn a refusal into an approval. A reason code is the number for the first failing check. Codes are append only.
What are all the ATCE reason codes?
ATCE defines fourteen reason codes, 0 to 13, in the Rust code of both chain implementations. The last column is drawn from the design documents' failure-handling tables; where they name no party, the table says so.
| Code | Name | Meaning | Who can fix it |
|---|---|---|---|
| 0 | Allow | All checks passed and an allowing review is on record. | Nothing to fix. |
| 1 | Identity below required | The lower of the two parties' identity levels is under the level the site profile requires. | The attester, with a new record once evidence supports a higher level. The cell operator, by changing the required level. |
| 2 | Origin blocked | The sender's jurisdiction is not on the site's allow-list. | The cell operator, by widening the list. The attester, if the record is wrong. |
| 3 | Destination blocked | The recipient's jurisdiction is not on the allow-list. | The same parties as code 2. |
| 4 | Amount over limit | The amount is above the per-act limit, or is zero. A limit of 0 permits no transfer of that asset. | The sender, by sending less. The cell operator, by changing the limit. |
| 5 | Risk too high | The higher risk score of the two parties is at or above the deny threshold. A threshold of 0 denies everything. | The attester, with a new score. The cell operator, by changing the threshold. |
| 6 | Sanctions hit | Either party's record carries a sanctions flag and the profile denies on a hit. | The attester, when the stored screening results change. |
| 7 | Profile malformed | The profile is unusable, for example it has no allowed jurisdictions. | The cell operator, through the configure transaction. |
| 8 | Missing attestation | A party has no identity record that is present, not revoked and unexpired at this height. | The attester, by issuing or renewing the record. |
| 9 | Review missing | Every check passed, but no review result is on chain for this act, or it was already used. | The reviewer service, by recording a result for that exact act. |
| 10 | Review denied | The agentic review said stop, though every check was green. | No override. A review is filed once per act and never overwritten. |
| 11 | Not configured | Enforcement is on but the site profile or a trust anchor is not pinned. | The holder of the reserved ATCE system account. |
| 12 | Account restricted | One of the two parties is frozen, on either side of the act. | The freeze holder. The sources do not name that party. |
| 13 | Zone mismatch | The two accounts are not in the same zone. Two unzoned accounts, or two in one zone, pass. | Whoever assigns zones. |
The ACL application chain returns a denial as 0x4C440200 combined with the reason code, so the reason travels in the outcome digest. Its other codes, 0x4C440110 to 0x4C440119, cover a bare value body after enforcement (110), site not configured (111), bad signature (112), stale identity version (113), review already filed (114), configure from the wrong account (115), configuration refused (116), ruling hash zero or recorded (117), field out of range (118) and activation checklist incomplete (119).
What is the difference between a hold and a deny?
ATCE's outcome is allow or deny; the code has no third verdict. Public copy calls a deny that waits for a person a "hold", for example when the review denied the act (code 10) or the review is missing (code 9). The agentic review is hold-only: it can stop an act the rules passed and cannot release an act the rules denied. A person decides after a hold.
The reviewer bridge uses the word in a narrower way. When the reviewer, the agentic review service, answers "Held", the bridge signs a deny, which ATCE reports as code 10. When the review is pending, absent, over budget, refused or fails with an error or a timeout, the bridge signs nothing, and the act is denied with code 9 until a result is recorded. The first is a decision. The second is the absence of one.
The InterOp design uses "hold" for a different thing, a provisional hold on credited value in a multi-hop path. That belongs to the router, which is designed and not built, and is not a ruling outcome.
What do the sender and the receiver experience when ATCE refuses?
The sender's transaction fails and reverts, so no value moves. On the jil-abci chain gas is still charged. The error carries the reason code and the ruling commitment, a SHA-256 hash of the ruling. On the ACL chain the error is the denial code above.
The receiver sees no credit, because the whole transaction reverts. The design documents describe no receiver notification. For a refused corridor release, no float moves and no replay marker is set, so a compliant retry can still settle.
A corridor release that carries no ATCE context is refused, and so is a release on a cell with no pinned corridor policy.
Is a refusal still recorded?
ATCE records a refusal in the rejection log, not in chain state. An allowed ruling writes the pair subject-to-commitment and commitment-to-subject into state and emits an event. A denial reverts the transaction, so nothing is written to state, and its commitment is carried in the rejection log instead.
The design has the record writer file the full record for a denial too, found by a failed-transaction lookup that needs the CometBFT transaction indexer on. Whether it is on is an open item.
Status, 2026-11-02: enforcement is on for every transfer on the live chain, jil-mainnet-2. The record writer is built and not deployed, and the production record store is designed. Retention is a commitment of 20 years or more, and storage for the record is allocated for each site when its license is signed.
How does ATCE fail closed, and what does that cost?
ATCE treats every unknown as a denial. Missing records, an empty jurisdiction list, a limit of zero, a risk threshold of zero, an unpinned profile and an absent review all refuse. A misconfigured cell moves nothing.
The cost is availability. If an input ATCE needs is unavailable, honest traffic stops with the dishonest, and the design offers no bypass: its handling for a reviewer outage is "do not add a bypass". Loosening happens only through the governed configure transaction. A lapsed identity record on a treasury or genesis account denies its outflows with code 8, which the design calls both the insider-outflow control and a freeze risk.
What happens when something ATCE depends on is missing or down?
Consensus calls no network service and reads no clock, so each dependency fails in its own way. The table follows the design documents' failure tables.
| Missing or down | Effect on rulings | Handling stated in the design |
|---|---|---|
| An identity record for a party (unregistered, revoked, expired) | The act is denied with code 8. | Renew the attestation. |
| The attester service | No new records. Unexpired records still work. | Renew records before their expiry height. Nothing is signed if the identity source or the chain node is unreachable or catching up. |
| The identity source (kyc-service) denies or errors | Nothing is signed. A stored jurisdiction that is not an ISO code is refused, never guessed. | Retry, or fix the stored value. |
| The site profile or a trust anchor (unpinned) | Enforcement cannot be switched on. If it is on, the act is denied with code 11. | Pin it with the configure transaction. |
| The review service | No review result is recorded, so every ruled act is denied with code 9. | Restore the service. No bypass. |
| The record writer | The ruling is unaffected, because consensus does not call it. A hash with no record is an alarm. | The writer retries from the chain and refuses to file if the chain lacks the commitment (409) or cannot be read (503). |
| An attester or reviewer key (compromised) | A forged record or result could be filed. | Rotate the key, re-attest at a higher version, audit the key's window. |
| Validators on mixed versions | The chain forks at the first block that carries a ruling message. | Upgrade together, at an agreed height. |
The code requires a review for every ruled act. Whether every transfer needs one, or only some classes, is an open decision. Three protocol flows are exempt by name (staking payouts, governance deposits and refunds, IBC escrow), and each still gets its own ruling hash with the exemption reason. The genesis allocation accounts are not exempt.
Status, 2026-11-02: enforcement is on for every transfer on the live chain. The attester, the reviewer bridge and the agentic review are live, so reasons 8 and 9 are live behavior of the chain: without an attested identity record an act is denied, and without a pre-ruling review result an act is denied. The record writer is built and not running in production.
How do replay and determinism affect refusals?
ATCE makes every refusal reproducible. Each validator re-runs the same evaluation over the same on-chain facts and reaches the same answer, because the ruling reads no clock and no outside service. The order of checks is fixed, the reason codes are append only, and the commitment binds the act's subject, the profile, the context, both parties' record versions, freeze flags and zones, the review result and the reason.
Enforcement is a one-way chain-state marker, not a code constant. A node replaying old blocks reproduces the legacy behavior until the block where the marker is set and applies the rules from then on, so replay is deterministic. No transaction turns it off; reversing it is a coordinated upgrade, a hard fork of the rules.
One review authorizes one act once. A second submission of the same act is denied, and a review filed for another amount or subject does not authorize this act.
What happens if validators disagree about a refusal?
ATCE depends on every validator computing the same ruling. The design calls determinism the security property: a node that computed a different decision would produce a different state hash and be caught. Agreement is 100 percent among the responding validators, and all ten validators on the live chain are operated by JIL Sovereign Technologies, Inc., on one hosting provider.
The consensus design document treats divergence as zero tolerance, and divergence detection is built as monitoring that rates an application hash divergence critical. It also proposes a revised model in which one dissent fails a single request and the chain halts only below seven voting validators. That is a design proposal, and the sources do not establish that the live chain runs it.
Status, 2026-11-02: the consensus engine is self-written, it has no independent audit yet and no external verifiers yet, and the ten validators are operated by JIL. Agreement among one operator's validators bounds accident, not a dishonest operator.
What does ATCE not do?
- ATCE does not write the rulebook. The cell operator publishes the policy profile, and ATCE does not replace a compliance officer or local law.
- ATCE does not turn a refusal into an approval. The review can only add a stop.
- ATCE does not compute risk scores or run sanctions screens. They reach it as attester-signed identity records, never as context the transacting party supplies.
- ATCE does not rule gas and fee distribution, staking or governance messages. The design lists the bridge withdrawal path and EVM contract execution as outside the ruling change.
- ATCE does not decide whether a court will admit a record.
- ATCE does not claim the chain cannot be tampered with. The rule is narrower: no transfer moves value outside an ATCE ruling. ATCE is patent pending.
Frequently asked questions
What happens to transfers if the reviewer service is down?
Every ruled act is denied with reason code 9, because ATCE does not rule before the reviewer has been heard. The design says to restore the service and not to add a bypass. This is live behavior of jil-mainnet-2 as of 2026-11-02.
Can the agentic review approve something ATCE would refuse?
No. The review can stop an act that every check allowed, and it can never turn a denial into an allow. A review is filed once per act and is consumed when the act is ruled.
What if an identity record expires?
The act is denied with reason code 8 until the attester issues a renewed record at a higher version. The design recommends alarms on records near expiry.
Does ATCE halt the chain when it refuses a transfer?
No. A refusal reverts one transaction and the chain continues. The consensus design describes a single chain-level halt below seven voting validators, which is a design proposal and not an established property of the live chain.