Short answer
ATCE, the Adaptive Trust, Compliance and Execution Engine, rules on each transfer using an identity record stored on chain for each account: level, risk, sanctions flag, jurisdiction, expiry and version. An attester service signs that record from a stored KYC or KYB result. Personal data stays off chain. The attester is live on the chain jil-mainnet-2 as of 2026-11-02.
What identity facts does ATCE read?
ATCE reads one identity record per account, plus two account-level states (freeze and zone). A ruling never takes identity from the transaction itself: the context a holder puts in a transaction is ignored.
The record is created by a SetAccountIdentity message. Its fields are:
| Field | Range or form | What ATCE does with it |
|---|---|---|
| account | The account the record describes. For a counterparty on another cell, the key is built from the destination chain id and the receiver. | Ties the facts to one party. |
| level | 0 to 4: none, basic, KYC, KYB, institutional. Level 0 means revoked. | The ruling uses the lower of the two parties' levels and compares it with the level the site profile requires. |
| risk | 0 to 100 | The ruling uses the higher of the two parties' scores and denies at or above the site's risk threshold. |
| sanctions_hit | yes or no | A hit on either party is a sanctions hit. The site profile decides whether a hit denies. |
| jurisdiction | Three uppercase letters on jil-abci; up to eight uppercase ASCII bytes on acl-app | The sender's record gives the origin and the recipient's gives the destination, each checked against the site's allowed list. |
| expires_height | A block height | The record stops counting at that height. |
| version | A number that must rise with every new record | Stale or replayed records are refused. The version is bound into the ruling's hash. |
| attester_sig | Ed25519 signature on jil-abci; hybrid Ed25519 plus ML-DSA-65 on acl-app | The signature is the authority. Anyone may relay the message, but it counts only if it verifies under the pinned attester key. |
Two further facts are read per party but are not part of the identity record. The freeze state denies the act when either party is frozen. The zone must match: value moves only when sender and recipient are in the same zone, and an unzoned account counts as zone "none". The ruling's hash binds each party's record version, freeze flag and zone, so the record states exactly which state was used.
Are KYC and KYB a condition of settlement?
Yes. ATCE evaluates identity inside consensus, on the transfer itself, so a counterparty without a usable record produces a transfer that never settles rather than a failed report afterward.
KYC is know-your-customer verification of a person. KYB is know-your-business verification of a company. Both checks are performed at each site under local law. The attester turns the stored result into the on-chain record, and the ruling then reads it for both accounts in every move.
What does the attester do?
The attester is an off-chain service that reads the latest KYC and KYB result from JIL's KYC service and signs a SetAccountIdentity message. It decides nothing about a person. It reports what the stored evidence supports.
The level it signs follows one table:
| Stored evidence | Level signed |
|---|---|
| Approved KYB (auto-approved, or an analyst case resolved approved) | 3 |
| Approved KYC and no approved KYB | 2 |
| Anything else: held, rejected, pending, unreviewed, absent or stale | 0, expiring now (a revocation) |
Levels 1 and 4 are never issued, because nothing in the KYC tables establishes either. The attester fills the other fields as follows:
- Risk is the highest stored combined score, and 100 when there is no result.
- Sanctions flag is set when either stored result has a hit, even if the other result is clean.
- Jurisdiction is the stored nationality or jurisdiction, mapped from a two-letter ISO 3166-1 code to its three-letter form through a 249-entry table. A value that maps to nothing is refused, never guessed.
- Expiry is the current chain height, read from the node, plus a configured lifetime in blocks.
- Version is the larger of the last version plus one and the current time in milliseconds, saved per account so versions only move forward across restarts.
The attester reads a fixed-shape KYC answer with no names or documents. A result older than the maximum age counts as not approved. The attester never rounds a level up: doubt becomes a lower level or a refusal.
What does the attester do when something is missing or down?
The attester signs nothing. It fails closed and never reads an error as a clearance.
| Condition | Result |
|---|---|
| KYC service unavailable, or the facts route returns an error | Nothing is signed |
| KYC service refuses the attester's credential | Nothing is signed |
| Stored jurisdiction is not an ISO code | Refusal, nothing signed |
| Chain node unreachable or catching up | The attester refuses; no stale answer is used |
| No submit address configured | The attester returns signed_not_submitted and never claims a submission it did not make |
Status, 2026-11-02: the attester is live on jil-mainnet-2. Without an attested identity record, ATCE denies the act with reason 8.
How do the facts get on chain?
The attester signs the record, anyone relays it, and the chain accepts it only if the signature verifies under the pinned attester key and the version is higher than the last one.
- The KYC service holds a verification result for an account.
- The attester reads the latest KYC and KYB result and signs the identity bytes: chain id, account, level, risk, sanctions flag, jurisdiction, expiry height and version.
- A relayer submits the SetAccountIdentity message. The sender of the relay has no authority; the signature does.
- The chain stores the record. A new record under a higher version replaces the old one.
What is the pinned attester key?
The pinned attester key is the public key the chain trusts to sign identity records. ATCE enforcement cannot be turned on until the attester key, the reviewer key and the site profile are all pinned.
Only the reserved system account jil1atce can pin or rotate the key, through a ConfigureAtce message. That account is held by the founder-controlled governance path. On jil-abci the key is Ed25519. On acl-app it is a hybrid Ed25519 plus ML-DSA-65 key, and both halves must verify.
If the key is compromised, a forged record could be filed. The handling is to rotate the key with ConfigureAtce and re-attest affected accounts at a higher version, then audit the rulings made during the key's window. The chain does not check that the attester is a different party from whoever submits transactions, so key custody is an operational control. Who holds the key, and whether a KMS or HSM replaces the key file, are open decisions.
How do genesis accounts get identity records?
Genesis accounts are ruled like any account. Founder decision 2026-11-01: the genesis allocation accounts are not exempt, because insider outflow is the concern. Each needs an identity record and a counterparty in the same zone.
The design prevents a lockout at activation. When enforcement is switched on, the ConfigureAtce message lists the accounts that must be ready, and the chain refuses to flip, naming the first ten missing, unless every one holds a record that is present, not revoked, unexpired and passes the site profile on its own. On jil-abci every zoned account is added to that list automatically. The runbook order is:
- Pin the attester, the reviewer and the site profile with enforcement still off.
- For each genesis account, the attester signs a record at version 1 with an expiry far enough ahead to cover the soak.
- Check zones: a genesis account in the internal zone can pay only another internal account.
- Send ConfigureAtce with enforcement on and the list of genesis accounts. Enforcement cannot be turned off afterward.
A genesis or treasury record that expires after activation denies that account's outflows until it is renewed. The design calls this both the insider-outflow control working and a freeze risk, and it calls for an alarm on records near expiry.
What happens when a record is missing, expired, revoked or frozen?
ATCE denies the act. A record counts only if it is present, not revoked and not expired at the current height. The check covers both parties, and one failing party is enough to deny.
| Situation | Result | Reason code |
|---|---|---|
| No record for either party | Denied, no attestation | 8, missing attestation |
| Record expired, including mid-flow | Denied | 8 |
| Record revoked (level 0) | Denied | 8 |
| Lower of the two levels is below the site requirement | Denied | 1, identity below required |
| Sanctions hit on either party, when the profile denies on a hit | Denied | 6, sanctions hit |
| Risk at or above the threshold | Denied | 5, risk too high |
| Either party frozen | Denied, in both directions | 12, account restricted |
| Sender and recipient in different zones, or one unzoned | Denied | 13, zone mismatch |
A restricted sender paying an unrestricted recipient is held, and so is the reverse. A denied transaction reverts, gas is still charged, and the rejection log carries the reason code and the commitment.
Does any personal data go on chain?
No. ATCE keeps personal data off the chain by design, because chain data is immutable and replicated to every node.
The chain gets an account identifier, a level, a score, a flag, a three-letter code, an expiry, a version, and later a hash that references the full ruling record. Names, documents and check results exist only inside an encrypted record that JIL holds off chain. That record uses a per-record key, so an erasure destroys a key and not a block. Personal data is not written to an event, a log line or a response outside the record store's authenticated read.
Status, 2026-11-02: the record store is designed and the record writer is built, merged and not running in production. The retention commitment is 20 years or more; storage for the record is allocated for each site when its license is signed. See the record.
Who is responsible for what?
| Party | Responsibility |
|---|---|
| The site or cell operator | Runs KYC and KYB under local law and publishes the site profile (required level, risk threshold, allowed jurisdictions, limits). |
| JIL | Operates the attester, signs the identity records, holds the attester private key and holds the encrypted off-chain record. |
| The KYC service | Holds the verification results and answers the attester's fixed-shape request. |
| The governance account jil1atce | Pins and rotates the attester key and the site profile, and switches enforcement on. |
| Any relayer | Carries a signed record to the chain. It has no authority of its own. |
| The validators | Verify the signature, check the version and apply the same ruling to the same facts. |
Status, 2026-11-02: ATCE enforcement is on for every transfer on the live chain, 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, merged and not running in production. This page describes the identity mechanism as the design and code state it. A site goes live when its identity levels, zones, sanctions lists, limits and policy are written and pinned, and ATCE enforces them from that site's first transfer. The consensus engine is self-written, has had no independent audit, and has no external verifiers yet.
Frequently asked questions
Does ATCE put KYC data on the blockchain?
No. The chain holds an account identifier, a level, a risk score, a sanctions flag, a three-letter jurisdiction code, an expiry height and a version. Names, documents and check results exist only inside an encrypted record that JIL holds off chain. The chain references that record by a hash.
What happens if an account has no identity record?
ATCE treats the act as having no attestation and denies it with reason code 8, missing attestation. This applies to either party: a transfer needs a usable record for both the sender and the recipient.
Can the person sending a transaction supply their own identity level?
No. ATCE ignores any context a holder puts in a transaction. Level, jurisdiction, risk and sanctions state come only from the record an authorized attester signed.
Does the attester ever round a level up?
No. The attester signs the lowest level the stored evidence supports. Doubt becomes a lower level or a refusal, and a missing field is never guessed.
Is the attester running in production?
Yes. As of 2026-11-02 the attester is live on jil-mainnet-2, where ATCE enforcement is on for every transfer. An account without an attested identity record is denied with reason 8.
What happens when the attester is down?
Existing unexpired identity records still work. New records cannot be added, and a record that reaches its expiry height stops counting until it is renewed.
Are genesis accounts exempt from the identity rule?
No. Founder decision 2026-11-01: the genesis allocation accounts are ruled like any other account and each needs a usable identity record.