Short answer
ATCE, the Adaptive Trust, Compliance and Execution Engine, gives every ruling its own SHA-256 hash. The Layer-1 holds only that hash. JIL commits to hold the full record, write once and read many, for 20 years or more. That retention is a commitment of 20 years or more, and storage for the record is allocated for each site when its license is signed. On the live chain the review result is already hashed into each ruling's commitment. The full record that the record writer files is not yet written.
What record does ATCE leave behind?
ATCE leaves two things for each ruling: a hash on the chain and a full record held by JIL. A ruling is the decision ATCE reaches on one act before value moves. The hash is the reference. The record is the evidence.
The record holds the ATCE rules that applied, the agentic review approval, the buyer and seller details including their KYB and KYC checks, and the ruling itself. KYB is know your business, the check on a company. KYC is know your customer, the check on a person. The agentic review is the service ATCE calls before its final ruling. It is live and hold-only: it can deny an act the rules passed, and it cannot release an act the rules denied. A deny that waits for a person is called a hold.
The record is write once, read many, usually shortened to WORM. Once it is filed it is not edited, and it can be read as often as an authorized reader needs.
What is the unique hash of a ruling, and what does it bind?
The hash is a SHA-256 commitment that ATCE computes over the ruling's inputs and outcome. Every ruling has its own, and no hash is reused. The hash binds the facts the ruling used to the decision it reached, so none of them can be swapped later without the hash changing.
For an ordinary ruling the commitment is a SHA-256 over these parts, in order:
- The subject of the act, itself a SHA-256 over the chain identifier, the kind of act, the sender, the recipient, the asset, the amount and the sender's account sequence.
- The profile as ruled: the identity level required, the accepted jurisdictions, the limit that applied to this act, the risk ceiling, the sanctions posture and whether an attestation is required.
- The context as ruled: the identity level and attestation of the counterparty, origin and destination jurisdiction, the amount, the risk score and the sanctions flag.
- Both parties' state: for the sender and for the recipient, the version of the identity record used, the freeze flag and the zone.
- The review result: whether the review is missing, denied or allowed, and the review hash when there is one.
- The reason code of the ruling.
Because the parties' record versions are inside the hash, the record states exactly which version of each account's state the ruling read. Changing either party's record version, or a party's zone, changes the commitment. Exempt flows and releases use their own prefixes, so their commitments cannot collide with an ordinary ruling.
| Ruling kind | What the commitment covers |
|---|---|
| Ordinary ruling | Subject, profile, context, both parties' state, review result, reason code |
| Exempt flow | Subject and the recorded reason text for the exemption |
| Release | Subject, the arrival decision, the review hash (zeros if none) and the reason code |
What does the chain hold?
The chain holds the hash and a small set of non-personal fields. It does not hold names, documents or check results.
For every ruling the chain stores the link from subject to commitment and from commitment to subject, written by one function, and emits an event carrying the kind, subject, commitment, reason code, review hash and an exempt flag. That function refuses a zero commitment, a commitment already recorded, and a subject already ruled. A ruling cannot exist without its hash, and no hash is reused.
The other chain data that ATCE reads is also limited to an account identifier, a level, a score, a sanctions flag, a three-letter jurisdiction code, an expiry height and a version. JIL signs the reference with hybrid Ed25519 and ML-DSA-65 signatures, the same pair the attestation seals use.
The reason personal data stays off the chain is durability. Chain data is immutable and replicated to every validator, and the record has to survive 20 years or more. An erasure or privacy obligation in one jurisdiction cannot be met by deleting from a chain.
What does JIL hold?
JIL holds the full record in a JIL-held object-lock WORM store, local to JIL and not on the chain. The founder decided this on 2026-11-01, after an earlier draft had placed the body with the sovereign site.
| Piece | Where it lives |
|---|---|
| The ATCE rules and policy number that applied | JIL record |
| The agentic review approval and its rationale | JIL record |
| Buyer and seller details, with KYB and KYC results | JIL record, encrypted |
| The ruling and its outcome | JIL record |
| The unique hash and the reason code | Layer-1 and the JIL record |
KYC and KYB checks are still performed at each site under local law. JIL stores the results in the record. Each record is encrypted with AES-256-GCM under its own random data key. The commitment is bound in as additional authenticated data, and the data key is wrapped by a JIL-held master key and kept apart from the stored objects.
How does write once, read many work here?
The record writer, a service named in the next section, has no delete and no overwrite. A second filing of the same record is answered as already recorded. A different body under the same commitment is refused as a conflict. After each write the writer lists the stored versions and raises a critical error if there is more than one, because a locked second version cannot be removed.
Each object carries a retention date, set when it is written, for the configured term in whole years. A legal hold can be placed on and lifted from a record, and a held record cannot be erased. Legal hold overrides expiry. Expiry never deletes the commitment on the Layer-1.
Erasure is off by default. When it is enabled it needs a legal reference and a named requester. The writer first writes an erasure receipt to the same locked store, then destroys the record's key and leaves a tombstone so the key can never be recreated. The locked object, its digests and the chain reference remain. The body becomes unreadable. That is the intended trade between retention and erasure: an erasure destroys a key, not a block.
What is the record writer service?
The record writer is the ATCE service that files each record, in services/atce-rulings on port 8576. It files a record under the ruling's commitment only after a chain of checks has passed.
- The body must fit the schema.
- The subject is recomputed from the act.
- The review hash is recomputed from the review artifact.
- The commitment is recomputed from the profile, context, both parties' state, review and reason, and must equal the commitment in the request path.
- The chain, read over CometBFT RPC, must hold that same commitment, on the named network, and must not be catching up. For an allowed act the writer reads the ATCE storage entry. For a denial it looks up the failed transaction.
- Only then does it create a key and a locked object.
At start the writer reads the bucket's Object Lock configuration and versioning, and refuses to run unless both are enabled. It creates no bucket. The lock mode and the credentials source have no default, so nothing weakens the lock by omission.
Failure is stated in advance. If a write fails, the chain has a hash with no record, and the writer retries from the chain. An unfiled hash is an alarm. If a recomputed commitment does not match, that is also an alarm and the record is investigated before either side is trusted. A lost master key leaves every record unreadable, so its backup is an open item.
What is hashed today and what is not. On the live chain the review artifact is hashed into the ruling commitment: without an attested identity record an act is denied (reason 8), and without a review result before the ruling an act is denied (reason 9). The full record that this writer files, with the rules as ruled, the review artifact and rationale, and the buyer and seller details, is not yet written, because the writer does not run.
Status, 2026-11-02: the record writer is built, not deployed. Its code is written and merged and has 52 tests, but it does not run in production. The orchestrator that builds the full record from the ruling event does not exist yet, so nothing feeds the writer today.
What does the corridor journal store?
The corridor journal is the Layer-1 trust record of a corridor hop. A corridor is the route value takes between sovereign sites. The journal stores the full policy text and the transaction, and it refuses a later edit of an entry already written.
For each entry the journal lists:
- When the entry was created.
- Who bought, and what was bought.
- Who sold.
- The source of funds or of the commodity.
- The history of that source.
- The buyer's ATCE accreditation and the seller's ATCE accreditation.
- The policy numbers and the version chains those numbers name.
The journal sits beside three smaller stores. The 32-byte policy word holds the policy name, a policy number, and not the body of the rules. The ATCE log holds that policy number. The policy table holds the version chains for it, write once. The ATCE transaction record described on this page is the retention layer of the journal. It is not a second journal.
See The Corridor Journal for the buyer, seller and currency rules the journal records.
How long does JIL keep the record, and how is storage allocated?
JIL keeps the record for 20 years or more. That is a commitment of 20 years or more. Storage for the record is allocated for each site when its license is signed, at petabyte-level capacity.
The exact capacity figure per record class is still open, as is the retention length for each class and who owns a legal hold. The key custody must also outlive the bytes. The wrapped data keys and the master key have to be kept and recovery-tested for the same horizon, or the stored ciphertext cannot be read.
Status, 2026-11-02: the 20-plus-year commitment stands. The production record store is designed. Each site's storage is allocated at licensing.
Where will the records be kept?
The store is designed, not chosen for production, and residency is undecided per jurisdiction. The writer is provider neutral: endpoint, region, bucket, credentials source, lock mode and retention all come from configuration, and it uses only standard S3 Object Lock calls.
The founder created a bucket with Object Lock enabled at creation on 2026-11-01. It has no default retention. An earlier JIL bucket could not take Object Lock, and Object Lock cannot be added to an existing bucket of that provider. These points are not decided:
- Whether that bucket is the production store, or the record moves to another cloud with SOC 2 and HITRUST reports.
- Compliance mode or governance mode. A compliance lock cannot be removed.
- Data residency per jurisdiction and per record, so that a record about a party in one jurisdiction can be kept in a bucket in that jurisdiction, and the limits on moving KYC and KYB data across borders.
- Whether crypto-shredding is accepted as deletion by a given jurisdiction, and who can order it.
- A recorded exception for holding KYC and KYB data in a JIL-local store, with a data-classification review, before any real customer data is written.
How would an auditor verify a record?
An auditor verifies a record by recomputing its hash and comparing it with the one the chain references. The design gives five steps.
- JIL gives the auditor or regulator the record body, decrypted under JIL's own authority, and its unique hash.
- The auditor recomputes the canonical SHA-256 hash from the body.
- The auditor reads the Layer-1 reference to the transaction by that hash and verifies the JIL signature.
- A match means the record is unchanged since the ruling. A mismatch means it was altered.
- The auditor asks for the exact version of the stored object and confirms the Object Lock retention by reading it back, never by trusting a bucket label.
Without any personal data, a third party can see 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 behind JIL's authority. After an erasure the signature and commitment still prove a ruling was made, but the body can no longer be recomputed.
What is the journal not?
The journal and the transaction record are the Layer-1 trust record, and nothing more than that. They are not the payment-integrity product at jilsovereign.com, which is the same company and a different product. They are not CourtChain. They are not a statement that a court will admit the file. A court decides admission.
They are also not a guarantee against tampering on the chain. The consensus engine is self-written, has had no independent audit, and has no external verifiers. The rule ATCE states is narrower: no transfer moves value outside an ATCE ruling.
What is verifiable today?
Verifiable today is the byte format of the hashes, not a stored record. The commitment and subject formats are tested across two codebases. A Rust test in the chain code writes the act subjects, the identity and review signing bytes, the ruling storage slot and seven ruling commitments to a vectors file. The record services reproduce every one in TypeScript. The Rust test also checks the signatures the services produce, with the same library consensus uses. If consensus changes a format, the Rust test fails first.
The writer was also exercised on 2026-11-01 against the founder's bucket with a governance lock, a two-minute retention and one throwaway object holding no real data. The start-up lock check, create, create-again, read, legal hold on and off, single version, refusal to delete before retention and cleanup all behaved as required. Not yet verified are conditional-write enforcement on a true race, compliance-mode behavior, and the transaction indexer the denial lookup needs.
Status, 2026-11-02: live: chain jil-mainnet-2 enforces ATCE rulings on every transfer, and the attester, the reviewer bridge and the agentic review are live, so the commitment and the review hash are written with each ruling. Built, not deployed: the record writer. Designed: the production record store, the retention capacity and the residency choice. No stored record exists for a past transfer that a reader can re-open today.
Questions about the transaction record
Does ATCE put personal data on the blockchain?
No. The chain holds the ruling's SHA-256 hash, a reason code, a review hash and a few non-personal fields such as a level, a score and a jurisdiction code. Names, documents and KYB or KYC results exist only in the encrypted record JIL holds.
How long does JIL keep the ATCE record?
JIL commits to keep it for 20 years or more. Storage for the record is allocated for each site when its license is signed.
Can an ATCE record be edited after it is filed?
No. The record writer has no delete and no overwrite, and a different body under an existing commitment is refused. The stored object also carries a retention date that the lock enforces. This describes the built writer, which is not deployed yet.
What happens to a record when a jurisdiction requires erasure?
The design destroys the record's encryption key and leaves a tombstone. The locked object, its digests and the chain hash remain, so they still prove a ruling was made, but the body can no longer be read. Whether each jurisdiction accepts this as deletion is undecided.
Where will ATCE records be stored?
The store is designed but not chosen for production. A bucket with Object Lock exists for testing, and residency per jurisdiction and per record is undecided. The writer needs only configuration to move to another provider.
Does the transaction record prove a court will accept it?
No. The record is the Layer-1 trust record. It is not the payment-integrity product and not CourtChain, and it makes no statement that a court will admit the file. A court decides admission.