The local mesh
The repository ships a runnable, three-stage local mesh that brings up OGONG’s verification
spine on an ephemeral solana-test-validator: independent ogong-validatord processes
discover each other from the on-chain registry and co-sign settlements over real QUIC. It is a
local, ephemeral test network you run on your own machine, the fastest way to watch the
whole spine work end to end before pointing the same processes at a live network.
The scripts live in llamamp/chain/scripts/ and are documented in
llamamp/chain/scripts/MESH.md. Run them from llamamp/chain.
Components
- chain program (
programs/chain) - staking pool, validator registry, escrow, and the quorum-gatedsettle(a release needskregistered-validator co-signers). - validatord (
ogong-validatord, built--features settlement) - generates its own cert, reads the on-chain registry every ~30s to discover peers, and (when it holds the settlement sink) settles a release by gathering peer co-signatures over QUIC. - verifierd (
ogong-verifierd) - re-runs a committed trajectory to score an audit (Stage 3).
Stage 1 - registry-driven discovery
bash scripts/run-mesh-stage1.sh
Chain up → N validatords (each writes its cert) → a provisioning script stakes and registers
each one with its real endpoint and cert (consensus_id = sha256(cert)) → after one
registry refresh, a discovery check shows every node found the others purely from the
chain. No manual peer config.
Stage 2 - quorum settle over real QUIC
bash scripts/run-mesh-stage2.sh
Three validatords: val0 is the handling node (holds the settlement sink, OGONG_QUORUM=2
plus the authority/mint/fee-owner env); val1/val2 are cosign-only peers (sink env
stripped). A driver pushes a metered RELEASE to the peers first (each holds its reply so it
will co-sign), then to the handling node, which fires its sink, gathers the two peers’
co-signatures over real QUIC, assembles authority + 2 co-sigs, and submits the on-chain
quorum settle. Verified by the provider’s fee account balance equalling the gross.
Stage 3 - audit-gated settle (fully live, engine-backed)
# 1. bring up the reference engine (ACE-Step) in commit mode:
LLAMAMP_COMMIT=1 llamamp-audio-server \
-m ~/models/ace-step-v1-3.5B/ace-full-f16.gguf \
--vocab ~/models/ace-step-v1-3.5B/vocab.json --port 11436
# 2. run the capstone:
bash scripts/run-mesh-stage3.sh
The capstone: a real generation is audited before its escrow releases, and only an Accept
settles. A verifierd points at the engine; three validatords register on-chain where
val0 audits every reply (--alpha 1) via the verifierd and holds the settlement sink
(quorum 2), and val1/val2 are cosign-only (--alpha 0). A driver generates a real
trajectory on the engine, commits its true root, and pushes the record. val0 audit-selects
it, dispatches to the verifierd (which re-runs sampled denoising steps on the engine and
scores the drift), adjudicates Accept, and only then gathers val1/val2’s co-signatures
over QUIC and submits the on-chain quorum settle.
When it works, the reply audits Accept, the mesh quorum-settles it on-chain, and the provider’s fee account ends up equal to the gross.
Notes
--alpha 0= no audit (immediate unaudited release), used in Stage 2 to isolate the settlement mesh.--alpha 1+--verifier-endpoint/--verifier-certwires the audit path.- The engine serves generic provider endpoints
/v1/trajectory/:id(the committed dump) and/v1/replay/:id(the original request) so a stockverifierdaudits it directly - no in-process bridge. Co-locating the verify-engine with the provider is a demo convenience; soundness uses a separate engine instance (--audio-engine-url). - Both the registry reader and the settlement client use confirmed commitment, so a settling node sees just-confirmed registrations/accounts without waiting for finalization.
examples/traj_audit_loopis the in-process, CI-friendly equivalent - no chain or live engine required.