Short answer
ATCE, the Adaptive Trust, Compliance and Execution Engine, enforces every transfer on the live chain jil-mainnet-2, inside a sovereign site and between sites. A reader can inspect the published design and the hash a ruling produces. There is no independent audit of the consensus engine, no external verifier, and no production ruling record to replay. JIL claims one rule: no transfer moves value outside an ATCE ruling.
What can an outside reader verify about ATCE today?
An outside reader can verify the design as published, the construction of the ruling hash, and the facts about the chain that this site states. A reader cannot verify a production ruling end to end, because the production record store is designed and no external verifier runs.
What is available now, in order of how much work it takes a reader to check:
- The published design. The white paper (section 9, "Trust, Records, and Compliance in Detail") and the pages in this section state what a ruling is, what it holds and how each part is meant to be checked. Every status in them is dated and marked live, built, not deployed, or designed.
- The chain facts this site states. The chain jil-mainnet-2 was genesised on 2026-08-21 with ten validators, all operated by JIL Sovereign Technologies, Inc. The site recorded it at height 103,364 on 2026-11-01, not catching up. A reader who is given access to a node or an RPC endpoint in a briefing can compare those facts with the running chain. They are not an independent source until a party other than JIL reads them.
- The hash a ruling produces. A ruling carries one SHA-256 commitment. The code builds it from a fixed domain tag (the text
jil.atce.ruling.v2) followed by the act's subject, the policy profile, the context, the state of both parties, the agentic review result and the reason code. The domain tag keeps a ruling hash from ever being mistaken for another kind of hash on the chain. A reader with a ruling's inputs can recompute the hash and compare it with the one the chain references. - The wire-format test vectors. The source tree holds a checked-in file of vectors: three act subjects (a transfer, a token transfer and a release), the storage slots for rulings, the bytes that the attester and the reviewer sign, and seven example commitments. Cases include an allowed act, a denied review, a missing review, a frozen recipient, a zone mismatch and the largest possible record version. A Rust test in the chain code regenerates the file and fails if a single byte differs. These vectors are not published on this site. An evaluator should ask for them (see the briefing section below).
The vectors matter for a specific reason. The off-chain services (the attester, the reviewer bridge and the record writer) are written in TypeScript. The chain is written in Rust. The two must agree byte for byte, or a signature the service makes would be rejected on the chain, or a record would be filed under a hash the chain does not hold. The same file is checked from both sides, and a second test confirms that signatures the services make verify under the same Ed25519 code that consensus uses.
Status, 2026-11-02: the ruling on every transfer is live on jil-mainnet-2. The attester, the reviewer bridge and the agentic review are also live. The record writer is built, not deployed: the code is merged and does not run in production. The vectors and tests run in development. No production ruling record is available for a stranger to inspect, and the white paper says so in section 9.5.
How is an outside party meant to verify a ruling? (design)
The design has an auditor obtain the ruling record, recompute its hash, check the signatures against keys pinned on the chain, and replay the ruling from the pinned profile. This is the verification design in section 9.4 of the white paper. It is a design. It is not a procedure available today.
- Obtain the record. The auditor receives the ruling record, decrypted by JIL under its own authority, with the ruling hash that the chain references.
- Recompute the hash. The auditor recomputes the canonical SHA-256 hash from the record body and compares it with the hash on the chain. A match means the record is unchanged since the ruling. A mismatch means it was altered.
- Check the signatures. The auditor checks the signatures on the identity records (the attester) and on the review result (the reviewer) against the keys pinned on the chain.
- Replay the ruling. The auditor replays the ruling from the pinned profile and the recorded context and confirms the same verdict. The engine is deterministic, so the same inputs give the same answer.
- Confirm the store. The auditor requests the exact version of the stored object and confirms the write-once retention setting. The design says never to infer write-once storage from a bucket's label.
Steps 2 to 4 need no trust in what JIL says. They need only the record and the chain. Step 1 does depend on JIL producing the record, which is why the commitment to retain records for 20 years or more matters and why this page treats it as a gap, not a feature.
Without any personal data, a third party could verify that a ruling existed at a block height, which policy number applied, that the agentic review was part of the ruling, and that the stored body still matches. Who the parties were stays hidden unless JIL uses its authority to release it. After a legal erasure the key to the record is destroyed. The commitment and signature stay on the chain and still prove that a ruling was made, but the body can no longer be recomputed. That is the intended trade between privacy law and evidence.
A separate part of the design, the verifier plane, is what the white paper calls the entire correctness argument: independent parties outside JIL who check the chain and may contradict it. The consensus design treats a node that stays silent and a node that answers differently as opposite events. Silence is tolerated. A contradiction is recorded and adjudicated and is not outvoted. This plane is designed.
Status, 2026-11-02: designed. The Attested Consensus Layer, which carries the contradiction rule, is built and has not been rolled onto the ten live validators, which run the original engine. The production record store is designed. Storage for the record is allocated for each site when its license is signed.
What can an outside party not check today?
An outside party cannot check that the consensus engine is correct, that independent verifiers agree with JIL, that two operators exist, that the running software matches the source, or that any past ruling is on file. The white paper states each of these.
| Gap | What it means for a verifier | Status, 2026-11-02 |
|---|---|---|
| Consensus engine is self-written and unaudited | No independent party has audited it. The pure consensus core is about 3,100 lines, small enough for an auditor to read. JIL calls that a mitigation and not an answer. | External audit not started (gate G2) |
| No external verifiers | Nobody outside JIL checks the chain. The correctness argument is JIL's own until an independent verifier runs. | Not started (gate G2) |
| One operator | All ten validators are operated by JIL Sovereign Technologies, Inc. The rule bounds accident and partial compromise. It does not bound a malicious operator. | Sovereign-hosted validators designed (gate G7) |
| One hosting provider | The ten validators share one provider. A node named for a compliance zone is labeled for that zone and is not located in it. | Designed (gate G7) |
| No reproducible builds | A reader cannot prove that the binary on a validator was built from the published source. Without them, a rolling upgrade can look like a one-against-many divergence. | Not started (gate G1) |
| No production record store | There is no production archive of rulings to request. An Object Lock bucket exists for tests only. Storage for the record, retained for 20 years or more, is allocated for each site when its license is signed. | Designed (gate G6) |
| Hybrid seals verified in part on chain | Only the Ed25519 half of a hybrid seal is verified on the chain. The ML-DSA half is carried and anchored off chain. | Designed (gate G4) |
| No load measurement | Behavior under sustained traffic on a production-shaped chain (seven validators, aged state) has not been measured. | Not started (gate G5) |
Two more limits apply to what a reader can see. The fault rule for settlement is 100% agreement among responding validators, which is not Byzantine fault tolerance. And the white paper notes that a signature-encoding defect was found and fixed in one signed structure, and that a systematic check of every signed structure in the estate is not done.
Status, 2026-11-02: every row above is as stated in the white paper, section 10.2 and the gate table in section 11.1. None has been upgraded since.
Does JIL claim that ATCE has no backdoors?
No. JIL does not claim that ATCE has no backdoors, and it does not claim that the chain cannot be tampered with. With one operator, one hosting provider, a self-written engine and no audit, no one could back that claim with evidence today.
JIL claims a narrower rule, and states it as a rule of the running chain: no transfer moves value outside an ATCE ruling. Enforcement is on for every transfer on jil-mainnet-2, inside a sovereign site and between sites. Account-to-account moves are ruled on both parties. A release with no ATCE context is refused.
The failure behavior is part of the same live rule. ATCE's outcome is allow or deny. An act whose parties lack an attested identity record is denied (reason code 8). An act with no review result before the ruling is denied (reason code 9). The agentic review can only add a hold: it can deny an act that the rules passed (reason code 10), and it cannot release an act the rules denied. A person decides after a hold.
The rule is checkable in kind, though an outsider cannot check it independently today. It is a statement about code paths: each way value can move either carries a ruling or is refused, and the test suites in the chain code exercise each refusal. The exempt list is short and named in the design: three protocol flows that are not transfers between parties. The genesis accounts are ruled. An evaluator can ask for the list of exempt flows and the tests that cover them, and can test the claim by trying to find a path that moves value without a ruling.
Status, 2026-11-02: the rule is live. Whether any one sub-rule, such as per-asset limits or an identity record for a given account, is set exactly as the design describes is a question for the briefing, not something this page asserts.
What should an evaluator ask for in a briefing?
An evaluator should ask for the items that turn each gap above into something testable. A good briefing can produce some of these now and should say plainly which it cannot.
- The test vectors file and the Rust and TypeScript tests that check it, so the evaluator can reproduce the byte-level agreement on their own machine.
- The list of ruled message types and the exempt list, with the tests that show each refusal.
- The pinned attester key and reviewer key on jil-mainnet-2, and the identity of whoever holds them.
- The current policy profile values for the site: identity level, default limit, risk threshold and jurisdictions.
- Read access to a node or an RPC endpoint, so the evaluator can read chain height, validator count and the stored ruling references for themselves.
- The size and source of the pure consensus core, and the state of the plan for an external audit and for reproducible builds.
- The plan and date for an independent verifier, and for validators hosted outside one provider and one operator.
- The record retention commitment (20 years or more) in writing, and how storage is allocated for each site.
To request a briefing, use the briefing request at /connect/. The security page at /security.html carries the current table of what runs in production and what is on the roadmap.
Questions about verifying ATCE
Can I verify an ATCE ruling today?
Only in part. You can read the published design and recompute the hash construction from a ruling's inputs. You cannot fetch a production ruling record, because the production record store is designed. No external verifier runs.
Has anyone audited the ATCE consensus engine?
No. The consensus engine is self-written and has had no independent audit. An external audit of the pure core is a stated precondition and is not started. JIL treats the small size of that core, about 3,100 lines, as a mitigation and not as an answer.
Does JIL say ATCE has no backdoors?
No. JIL says that no transfer moves value outside an ATCE ruling on the live chain. That is a rule about code paths and can be tested. A claim of no backdoors would need an independent audit, independent verifiers and more than one operator. None of those is in place today.
How do I recompute an ATCE ruling hash?
The design takes a SHA-256 over a fixed domain tag, the act's subject, the policy profile, the context, both parties' state, the review result and the reason code. The test vectors give worked examples with inputs and expected commitments. Ask for them in a briefing.
Who operates the validators that run ATCE?
JIL Sovereign Technologies, Inc. operates all ten validators on jil-mainnet-2, and they share one hosting provider. This is a single-operator, permissioned design. The rule it supports bounds accident and partial compromise, not a malicious operator.
How do I request an ATCE technical briefing?
Use the briefing request at /connect/. Ask for the test vectors, the exempt list, the pinned keys and read access to a node. JIL should state for each item whether it is live, built and not deployed, designed, or not started.
Request a briefing
Bring the list above. A useful briefing states what can be checked and what cannot.