System architecture
T.A.L.A. runs a client first flow backed by decentralized storage and a simple on chain contract. This page shows how each layer works and where guarantees come from.
Core layers
Three parts, one guarantee
Creates AES 256 keys, encrypts files locally, and clears secrets after upload.
Pins encrypted payloads with immutable content identifiers for later verification.
Holds the key, enforces unlock time, and emits an audit trail of events.
Flow
What happens from upload to release
Browser generates a fresh key and encrypts the document before anything leaves the device.
Encrypted data is pinned to IPFS through Pinata. The CID is the integrity anchor shared with stakeholders.
The contract stores CID, key, and unlock moment. No override path exists outside on chain logic.
When block time reaches the policy, the contract returns the key. Clients decrypt in the browser without servers.
Request path
Data moves with proof
Client
-> generate AES 256 key
-> encrypt file locally
-> upload encrypted file to IPFS
-> receive CID
-> submit CID + key + unlock time to contract
-> contract records state
-> emits VaultCreated event
-> waits until block time >= unlock time
-> returns key on unlock request
-> browser decrypts and rendersAssurance
Properties that hold under stress
Non custodial
Keys live in the browser during creation and on chain after commit. Servers never keep them in plaintext.
Deterministic timing
Unlock checks read validator time. The schedule cannot be moved by configuration or support requests.
Immutable evidence
Uploads, voids, and unlocks emit events that anyone can prove later in an audit or dispute.
Global access
IPFS distribution and Polygon validation keep the release available even when a region is offline.