Prepare availability.
Encrypt the entity with a fresh CEK, erasure-code it, distribute encrypted shards, and append a signed commitment.
Commit.Rebuild.
PUBLIC REFERENCE IMPLEMENTATION / TESTNET DEPLOYMENTS / PRE-GA
Lattice turns a prior encrypted distribution into a compact, receiver-bound handoff. The codebase now extends into gateways and corridor attestations. Production trust still has to be earned.
COMMIT encrypts an entity, erasure-codes it, distributes the encrypted shards, and signs the commitment. LATTICE then creates a receiver-bound ML-KEM envelope. MATERIALIZE verifies the commitment, retrieves enough shards, decrypts them, and reconstructs the entity.
The receiver envelope is roughly 1.3–1.6 KB, depending on serialization and commitment fields, after the entity has already been distributed. This is a compact handoff, not constant total bandwidth. Storage, retrieval, and reconstruction costs remain.
Two mechanisms, two properties
Erasure coding supplies availability: enough shards can reconstruct the entity when others are missing. It does not make those shards secret. Confidentiality comes from authenticated encryption and protection of the content-encryption key, or CEK.
The implementation uses ML-KEM and ML-DSA through pinned libraries. That supports a post-quantum-oriented design; it does not establish a FIPS-validated module, federal authorization, or production assurance.
A capability crosses the boundary.
The receiver gets what it needs to locate, verify, and recover one committed entity. It does not receive another copy of the entity itself.
- ENVELOPE
- Receiver-bound ML-KEM material plus the commitment reference; roughly 1.3–1.6 KB after prior distribution.
- CONFIDENTIALITY
- Authenticated encryption protects shard contents; the CEK remains load-bearing.
- AVAILABILITY
- Erasure-coded shards tolerate missing storage nodes. This is recoverability, not secret sharing.
- ATTESTATION
- Signed commitments, Merkle structures, corridor formats, and testnet registry anchors make claims inspectable.
Commit. Lattice. Materialize.
The three phases remain the stable center while the surrounding gateway and corridor stack expands.
Bind one receiver.
Seal the CEK and commitment reference for a receiver with ML-KEM. The payload remains in the distributed storage plane.
Verify and recover.
Verify sender and commitment, retrieve enough encrypted shards, decrypt, decode, and confirm the reconstructed entity.
The public repository now includes gateway APIs and deployment preflight, node and storage components, committee and DKG machinery, corridor integration, registries, bridge contracts, operator runbooks, diagnostics, and monitoring surfaces.
A concrete corridor format
The corridor path specifies a 7-of-9 BLS aggregate attestation and carries Python/Rust digest-parity tests. That cross-language work reduces a common source of consensus failure: two implementations signing different bytes while believing they agree.
These components are implemented and tested as software. They do not demonstrate nine independently operated nodes, adversarial production traffic, or a production multi-node corridor. The public roadmap keeps multi-chain corridor expansion in flight and general availability later.
What exists now.
Three evidence levels keep shipped code, testnet state, and future trust from collapsing into one claim.
| Ledger | Status | What the evidence supports |
|---|---|---|
| Implemented | Public reference stack | COMMIT/LATTICE/MATERIALIZE; gateway and operator surfaces; encrypted availability; 7-of-9 BLS corridor format; Python/Rust digest parity; registry, governance, optimistic-bridge, and verifier source. |
| Deployed on testnet | Base Sepolia + SUWAPPU testnet | Registry, governance, bridge, and verifier addresses are recorded publicly. Base Sepolia is useful for integration testing, but its fast path is simulated and its optimistic path is administratively resolved. |
| Not yet | Pre-GA | No mainnet, production multi-operator corridor, externally audited codebase, deployed proof-secured fast path, production bond economics, or completed official Verifpal run. |
- FAST PATH
- The live Base Sepolia verifier is in
MODE_SIMULATED. Its hash-tag check is not a zero-knowledge proof and supplies no cryptographic finality guarantee. - OPTIMISTIC PATH
- A challenge commits to an off-chain fraud-proof hash. The contract does not verify that proof; an admin or appointed arbiter decides, with time decay as a backstop.
- BONDS
- Operator and challenger minimum bonds are both zero. Slashing logic exists, but zero collateral gives it no economic force on the live deployment.
- GOVERNANCE
- Testnet administration uses a 2-of-2 multisig and a 60-second timelock. Stronger limits exist in newer source and await redeployment.
- PROOF BACKENDS
- The Solidity STARK mode checks proof structure and hash tags, not an FRI-plus-ML-DSA proof. An SP1 guest verifies ML-DSA in source but lacks deployed end-to-end integration; the RISC Zero path is a placeholder.
- ASSURANCE
- Fuzzing, invariant harnesses, threat models, and internal red-team work are present. There is no claimed external code audit. The Verifpal model is authored; its official symbolic run remains pending.
- MAINNET
- No mainnet deployment is claimed. The current use is development, testnet integration, and audit preparation, not production value transfer.
- TIP CI
- At public commit e52c4f0, the ETP CI run recorded 4,030 Python tests passed and 10 skipped; 333 Forge tests passed and one skipped; five dedicated invariant tests and the Anvil integration passed.
- CHECKS NOTE
- This is not an all-checks-green claim. A separate lint workflow was red because Ruff formatting requested changes in two files. The security job reported no known dependency vulnerabilities; that audit was non-blocking. Slither passed its configured gate while still reporting 40 findings and gating only high severity.
- SOURCE TERMS
- The repository is public. Its root LICENSE says Elastic License 2.0, while the README and package metadata say MIT. Until that conflict is resolved, FAEI calls it public source, not unqualified open source.
- BASE SEPOLIA
- Registry proxy 0x79eF…5996 · Optimistic bridge 0x5083…7Dd0
Read the repository's bridge trust model before relying on a testnet anchor. The commands below confirm network and bytecode state; they do not prove source provenance, contract correctness, or production readiness.
cast chain-id --rpc-url https://sepolia.base.org
cast code 0x79eF1B7914f98C5C1404617449AB1f377c475996 --rpc-url https://sepolia.base.org
cast code 0x5083194d9e8EB54Fc397E69A518Be9503C767Dd0 --rpc-url https://sepolia.base.org
cast call 0x79eF1B7914f98C5C1404617449AB1f377c475996 "version()(uint256)" --rpc-url https://sepolia.base.org
The current architecture adopts a better business sequence: use approved stablecoins for operator bonds, consider shared operator capital later, and introduce a native token only after usage and governance demand justify one. That lets customers evaluate a corridor without also underwriting a speculative asset.
This design is not implemented. The live testnet bonds are zero, and the mapping from stablecoin collateral to operator or consensus rights is not in production code.
The risks move; they do not vanish
Stablecoin bonds bring issuer freeze and depeg risk, custody and compliance obligations, capital concentration, opportunity cost, and hard questions about bond floors, slashing, griefing, and operator returns. Those rules need code, adversarial testing, and empirical calibration before they can secure value.
A business before mainnet
Lattice can support paid gateway deployment, corridor integration, verification tooling, evidence packaging, and audit-readiness work in controlled environments. That is a credible pre-GA service business. It is not yet a production bridge business.
One corridor. Shadow mode first.
Suwappu and Lattice do not call each other today. The first joint proof should run beside an existing rail, on one observable corridor, before it is allowed to move value.
- INPUT
- A recurring Suwappu route with explicit source finality and a narrow destination action.
- TRIAL
- Produce a Lattice evidence package and measure latency, cost, liveness, recovery work, and trust dependencies against the incumbent route.
- EXIT GATE
- The destination rejects invalid evidence locally; no signer, admin, or arbiter decides message validity; upgrades and reorg behavior are constrained and independently reviewed.
- UNTIL THEN
- Lattice is the public pre-GA attestation and corridor program. It is not a completed Bridgeless Bridge.
Browse the public repository. For the live bridge boundary, read the Bridge Trust Model. For assurance scope, read the formal-verification status and the deployed-contract record.