Distribute encrypted availability.
Encrypt the entity, erasure-code it, send shards to nodes, and append a signed commitment.
Commit.Reconstruct.
PROTOCOL LAB / RESEARCH PROTOTYPE / REVIEWED 4 AUGUST 2026
Lattice explores a receiver-bound handoff backed by encrypted distributed shards, signed commitments, and on-chain anchors.
The Lattice Transfer Protocol begins by encrypting an entity, erasure-coding it, and distributing shards to storage nodes. The sender signs a commitment to what was stored. A receiver later gets a small, receiver-bound ML-KEM envelope containing the content key and the commitment reference, then retrieves enough shards to reconstruct.
The direct handoff can stay roughly constant in size after distribution. Total system bandwidth does not. Content still has to be encrypted, sharded, distributed, retrieved, and reconstructed. The design moves work into a different topology; it does not repeal network cost.
Where secrecy comes from
Erasure coding supplies recoverability when some shards are missing. It is not secret sharing. Confidentiality comes from authenticated encryption and protection of the content-encryption key. That distinction matters because a protocol should claim only the property its mechanism actually provides.
A capability crosses the boundary.
The receiver gets the means to verify and reconstruct a committed entity. The design keeps shards distributed and the commitment signed, while the receiver checks integrity before accepting the result.
- HANDOFF
- A receiver-bound ML-KEM envelope with key material and a commitment reference.
- CONFIDENTIALITY
- Authenticated encryption plus protection of the content key.
- RECOVERY
- Erasure-coded shards distributed across storage nodes.
- ATTESTATION
- Signed commitments, Merkle structures, and recorded on-chain anchor contracts.
Commit. Seal. Rebuild.
The repository describes a three-stage sequence. Production remains open work.
Seal for one receiver.
Encapsulate the content key and commitment reference in a receiver-bound ML-KEM envelope.
Verify, retrieve, rebuild.
Check the commitment, fetch enough shards, decrypt, decode, and confirm the reconstructed entity.
- STATUS
- Research prototype. In the source snapshot reviewed on 4 August 2026, the project's whitepaper described no production deployment.
- CRYPTO
- Uses algorithms from the FIPS 203 and 204 families plus authenticated encryption. This is not a claim of a FIPS-validated implementation.
- TESTNET
- Project files record reference-contract addresses for a SUWAPPU test network and Base Sepolia. This page does not claim verified source code or a mainnet deployment.
- OPEN WORK
- Production multi-node transport, direct on-chain aggregate verification, external code audit, and production infrastructure remain unfinished.
- ASSURANCE
- Internal red-team work is self-assessment, not an independent audit. Formal verification work is not complete.
- SOURCE STATUS
- The configured public repository location was unavailable during review, and licensing metadata conflicts. A source CTA is intentionally withheld until those are resolved.
- BASE SEPOLIA
- 0x79eF1B7914f98C5C1404617449AB1f377c475996
These commands confirm the RPC chain identifier, retrieve the bytecode currently returned for the recorded address, and attempt two registry-interface reads. They do not establish source-code provenance, audit status, contract identity, or that a particular anchor was recorded.
cast chain-id --rpc-url https://sepolia.base.org
cast code 0x79eF1B7914f98C5C1404617449AB1f377c475996 --rpc-url https://sepolia.base.org
cast call 0x79eF1B7914f98C5C1404617449AB1f377c475996 "version()(uint256)" --rpc-url https://sepolia.base.org
cast call 0x79eF1B7914f98C5C1404617449AB1f377c475996 "admin()(address)" --rpc-url https://sepolia.base.org
Lattice is strategically useful to FAEI because proof-gated finance also needs commitments, availability, receiver capabilities, and auditable state. The project explores those boundaries with post-quantum-oriented primitives and on-chain anchors.
It does not yet meet the report's central condition for a Bridgeless Bridge: direct destination enforcement of the relevant proof without trusting a relay to decide validity. Any future convergence has to close that gap in code, tests, governance, and independent review.