Questions people ask about ATCE

ATCE, the Adaptive Trust, Compliance and Execution Engine, is the part of the JIL Layer-1 that rules on an act before value moves. It reads a site's published policy and the facts about the parties, then returns allow or deny, a reason code and a SHA-256 commitment. See What is ATCE and The ruling.

ATCE stands for Adaptive Trust, Compliance and Execution Engine. The consensus layer that runs it is called ACL, the Attested Consensus Layer, because agreement on ordering and agreement on whether an act is admissible are produced in the same pass. Terms are defined in the Glossary.

No transfer moves value outside an ATCE ruling. A ruling is made for each ruled act, and an account-to-account move is ruled on both parties. A release with no ATCE context is refused. See The ruling.

JIL Sovereign Technologies, Inc. (Delaware) operates the Layer-1 host at jilsovereign.net under license from JIL Sovereign Holdings, LLC (Wyoming). The operator of each sovereign site publishes that site's policy. JIL supplies the engine that makes the published policy binding.

ATCE is part of the chain. It runs inside the Layer-1 consensus application, so every validator re-runs the same evaluation over the same inputs. The attester, the reviewer bridge and the record writer are separate off-chain services beside it. The attester and the reviewer bridge are live on jil-mainnet-2, and the record writer is built, merged and not running in production (see Status ledger).

No. ATCE enforces the rules the site operator publishes. Local law and the operator's own authority still govern, and a human remains responsible for the rulebook.

ATCE does not write anyone's rulebook, and it does not screen people itself. It rules over identity and sanctions facts that a signed on-chain record supplies, produced off chain by the attester. See Identity and attestation.

ATCE reads on-chain identity records that an authorized attester signed. The context a holder puts in a transaction is ignored, because the act never supplies the facts it is judged on. See Identity and attestation.

ATCE uses five levels: 0 none, 1 basic, 2 KYC, 3 KYB, 4 institutional. The attester service, which is live, signs only level 3 for an approved KYB, level 2 for an approved KYC with no approved KYB, and level 0 for anything else. Levels 1 and 4 are never issued, because nothing in the KYC tables establishes either.

A record holds the account, a level from 0 to 4, a risk score from 0 to 100, a sanctions flag, a three-letter jurisdiction code, an expiry height, a version and the attester signature. Versions only move forward, so an old record cannot replace a newer one.

A record counts only if it is present, not revoked and not expired at the current height. If either party's record does not count, the context has no attestation and the act is denied with reason 8. Renewal needs a new record at a higher version.

No. The chain receives a level, a score, a flag, a three-letter code, an expiry and a hash. Names, documents and check results exist only inside the encrypted record that JIL holds. See The record.

The attester is an off-chain service that turns the KYC and KYB result JIL already holds into a signed identity record. It signs the lowest level the evidence supports and treats doubt as a lower level or a refusal. The attester is live on jil-mainnet-2: without an attested identity record, an act is denied with reason 8.

The profile is the site's published policy, stored in chain state. It carries the required identity level, a default per-act limit, a risk threshold, a sanctions flag, the allowed jurisdictions (up to 10 in one implementation, 64 in the other) and per-asset limit overrides. See Policy and activation.

The operator of the sovereign site writes it, under its own law and authority. JIL supplies the engine and never supplies the rulebook. ATCE guarantees that the published policy is the policy that actually executed.

A sovereign site writes its own identity levels, jurisdiction zones, sanctions lists, limits and policy, and the policy is pinned. A site goes live when its policies are pinned, and ATCE enforces them from that site's first transfer. See Policy and activation.

Yes. Status, 2026-11-02: ATCE is deployed and enforcing on jil-mainnet-2, on every transfer inside a sovereign site and between sites. The attester, the reviewer bridge and the agentic review run in production.

The sovereign that operates the site writes them, under its own law and authority. JIL supplies the engine that makes the pinned policy binding on every transfer. See Policy and activation.

Under the design, only the reserved ATCE system account jil1atce can send ConfigureAtce, which pins the attester key, the reviewer key, the site profile and per-asset limits. That account is held by the founder-controlled governance path. Custody of the keys and of that account is listed as an open decision.

No. Enforcement is a chain-state marker set once by ConfigureAtce, and it cannot be unset by a transaction. After enforcement, rollback is a coordinated upgrade to a build that does not read the marker, which is a hard fork of the rules.

Yes on jil-mainnet-2. Status, 2026-11-02: the founder confirmed that ATCE enforcement is on for every transfer on that chain, inside a sovereign site and between sites. Arming another cell is opt-in and needs a coordinated validator upgrade with that cell's operator.

The switch is refused until the attester key, the reviewer key and the site profile are pinned. It is also refused, with the missing accounts named, unless every listed activation account holds an identity record that is present, not revoked, unexpired and passes the profile. This stops a treasury freezing on the first block after the switch.

ATCE fails closed. A per-act limit of 0 permits no transfer, a risk threshold of 0 denies everything, and an empty jurisdiction list is malformed and denies all. A misconfigured site moves nothing instead of quietly moving everything.

A per-asset limit overrides the site's default per-act limit for one asset. It can be tighter or looser than the default, and a limit of 0 permits no transfer of that asset. See Limits and currencies.

JIL commits to keep a write once, read many (WORM) record holding the ATCE rules that applied, the agentic review, the buyer and seller details with their KYB and KYC checks, and the ruling. The record is filed under the ruling's unique hash. See The record.

JIL commits to keep the record for 20 years or more. Storage for the record is allocated for each site when its license is signed. See The record.

The 20 year commitment is made, and each site's record store is allocated when its license is signed. Status, 2026-11-02: the production record store is designed, and the record writer is built and not deployed.

JIL makes the retention commitment, and storage for each site's record is allocated when that site's license is signed. Commercial terms are agreed in the license (see Licensing).

JIL holds the record in its own write once, read many store, local to JIL and not on the chain. The production store is designed, and data residency per jurisdiction is undecided. The chain holds only the hash that references the record.

No. JIL holds the record locally, and the chain references it by hash. Personal data does not go on the chain, so an erasure obligation in one jurisdiction does not collide with an immutable ledger.

The record writer has no delete and no overwrite. A second filing of the same record reports already recorded, and a different body under the same commitment is a conflict. The record writer is built and merged, and it is not running in production.

Under the design, erasure is off by default. When enabled, it needs a legal reference, writes an erasure receipt first, and destroys the record's key, so the body becomes unreadable while the locked object, its digests and the chain reference remain.

No transfer moves value outside an ATCE ruling, and a refusal reached by the published policy cannot be turned into an approval by any single operator. The operator can change the policy through the governed path, and JIL operates all ten validators, so a coordinated upgrade that changes the rules is possible. The protection is that every change is visible and recorded, not that the operator is unable to act.

JIL does not claim there are none, and the chain is not claimed to be tamper-proof. The claim is the rule: no transfer moves value outside an ATCE ruling. The consensus engine is self-written and unaudited, and the documented exemptions are three protocol flows. See Refusals and failure modes.

JIL Sovereign Technologies, Inc. operates all ten validators on jil-mainnet-2, with one hosting provider. That is permissioned and attributable by design, and it is not a claim of decentralization.

Yes. Consensus calls no network service and reads no clock, so every validator reaches the same answer from the same inputs. A divergent node forks and is caught by the application hash check.

Take the record body and recompute the SHA-256 commitment, then read the chain's reference by that hash and compare. A match means the record is unchanged since the ruling. A third party can confirm that a ruling existed, which policy applied and that the review was part of it, without seeing who the parties were. See Verification.

A forged identity record or review result could be filed. The response is to rotate the key with ConfigureAtce from jil1atce, re-attest affected accounts at higher versions, and audit rulings made in the key's window.

They are not re-judged. Enforcement is a state marker, so replay from genesis reproduces the earlier behavior exactly until the block where the marker is set, then applies the new rules from that block.

Monitoring tools reconstruct afterward whether value should have moved. ATCE rules at the only point where refusing is still possible, and produces the evidence as a by-product of the decision. See ATCE compared.

A token-level allowlist lives in one contract. ATCE sits in the chain's consensus application and rules native transfers, token transfers and currency transfers with one engine, one reason-code set and one commitment scheme.

Front-door KYC is checked once and trusted afterward. ATCE evaluates the required identity level inside consensus on the transfer itself, with facts from a signed record, so a counterparty that has not satisfied KYC produces a transfer that never settles.

A permissioned ledger limits who may participate. ATCE rules each act by policy, identity, jurisdiction, limit and zone at the moment of movement, and records the reason. JIL's validators are also permissioned and attributable, which is separate from what ATCE does.