FAQ

General Questions

How does ATL differ from a Blockchain?

ATL is an append-only log with cryptographic proofs, not a full blockchain. It sacrifices decentralized consensus at the ingestion level for extreme performance (millions of TPS) and privacy, while maintaining immutability through periodic anchoring in existing blockchains like Bitcoin.

Why use TSA (RFC 3161) AND Bitcoin?

They solve different problems:

TSA provides legally recognized proof of time from a centralized authority.
Bitcoin provides mathematically guaranteed proof of existence from a decentralized network. Using both ensures that your proof remains valid even if a TSA service goes down or a blockchain changes.

Privacy & Security

Does the Log Operator see my private data?

Only if you explicitly choose to provide it.

By default, the ATL Protocol only requires a cryptographic hash to guarantee integrity. If you provide only the hash, the Log Operator never sees your original data.

However, some Log Operators may offer optional data custody services. In this case, you may choose to send the original data (payload) to the operator for long-term storage and easier proof generation. This is always an opt-in feature and is not required for the protocol to function.

Yes. Since ATL only stores hashes in the immutable log, you can comply with the “Right to Erasure” by deleting the original data (payload) from your storage. The hash in the log remains as a mathematical constant but no longer links to any personal information.

Technical Details

Why use JCS (RFC 8785)?

Traditional JSON is not deterministic (keys can be in any order, whitespace varies). JCS ensures that the same JSON object always produces the same hash, regardless of the library or language used to generate it.

Do I need to trust the Log Operator?

No. Trust in ATL is derived exclusively from external anchors (RFC 3161 TSA, Bitcoin blockchain), not from the Log Operator. The operator’s checkpoint signature serves only as an integrity check — it binds the data together but does NOT establish trust.

A valid ATL receipt with at least one verified anchor is trustworthy even if you’ve never seen the Log Operator’s public key before. The anchor IS the trust anchor.

What happens if the Log Operator disappears?

Because ATL receipts are self-contained, they can be verified offline. As long as you have the receipt and the original data, you can prove your fact’s integrity forever, even without the operator’s infrastructure. Trust is derived from the external anchors embedded in the receipt, not from the operator’s key.

How do I know the Log Operator hasn’t deleted or changed old entries?

ATL v2.0 uses the Super-Tree architecture to mathematically guarantee that the log is append-only across all Data Trees. Every Receipt-Full includes a consistency_to_origin proof linking it to the genesis_super_root (the first Data Tree’s root hash). This proves your receipt belongs to the same unbroken chain of history from the very beginning.

If the operator tried to delete or modify any entry, the consistency proof would fail — proving fraud without downloading the entire log.

Combined with external anchoring (RFC 3161 timestamps for Data Trees, Bitcoin for Super Root), this makes history rewriting detectable and provable.

What is Cross-Receipt Verification?

In ATL v2.0, any two Receipt-Full documents from the same log instance can be verified against each other without contacting the server. Simply check that both receipts have the same genesis_super_root and valid consistency_to_origin proofs. Since Merkle trees are append-only and both receipts prove consistency with the same genesis, this mathematically guarantees the log history between them was not modified.

What are Receipt-Lite, Receipt-TSA, and Receipt-Full?

These are trust tiers based on which anchors are present:

Receipt-Lite: No external anchors. Proves internal consistency only.
Receipt-TSA: Has RFC 3161 timestamp. Provides legally-recognized proof of time from a TSA.
Receipt-Full: Has both RFC 3161 + Bitcoin OTS. Provides eternal immutability and global consistency verification.

FAQ