AliceNet and the network: a note for Matt

Matt — this is the technical companion to the point of view we're walking through today. You built AliceNet; Precise needs its machinery; nobody else can rule on half of what follows. Read it as an engineering brief and an invitation, and tear it up where it's wrong. — Adam (assembled with Claude, 2026-08-05, from a four-lane audit of both codebases)

Why this, why now

The network's whole reason to exist is the problem nothing else solves: Company A's agent uses Company B's capability, and later both sides must prove things about what happened — authority, provenance, contribution — without anyone opening their books and without a hyperscaler as the trusted middleman. The mechanism is credentials (portable authority), Merkle commitments (disclosure-free sealing of Calls), anchoring (a clock nobody owns, so sealed-before-outcome is checkable across company lines), selective disclosure (the proof crosses, the data stays home), and contribution settlement (the order book). That stack is the thing we have been circling since MAD Network. It runs on machinery you built.

What the audit found (2026-08-05, both repos)

The honest state, verified line by line:

• Our sealing discipline is real and unusually honest — to ourselves. Canonical sha256 digests, hash-chained ledgers, a homegrown Merkle tree with working inclusion proofs (research-core), purged walk-forward courts, replay-by-recompute. But every "seal" bottoms out in an unsigned content hash in storage we control. It proves integrity to us and nothing to anyone else. The file owner can rewrite entry n and recompute every downstream seal in seconds.
• AliceNet is not used anywhere in the precise repo today. Zero imports, no Ed25519. The mentions are honest stubs: context-server's seal_ref ("swaps to AliceNet block id when live"), config.ts "partner-alicenet, stubbed both sides", proof-orchestrator's never-run Valence anchor mode. The OMG "sealed decisions" seat rests on the sha256 stub.
• Next door, konstantin.ai/lib/alicenet is real: Ed25519 W3C verifiable credentials (Operator/Decision/Precedent) and a MerkleService, correctly consumed by two production paths (v-extract correction ledger, adjudication court). Credential issuance is exercised only by tests. Chain anchoring fails closed everywhere — no ChainAnchorAdapter exists.
• The refuse-to-fake posture is exemplary and must be preserved: anchored:false hardcoded in the gateway envelope, SealedReceipt forcing realized:null, qualification records noting that self-declared JSON is not attestation. The courts' no-lookahead and purged folds are genuinely good holdout hygiene.
• Overclaims we are fixing: docs showing anchored:true states no code path can produce; "the Merkle job that exists" (two unmerged commits on a fork, never run e2e); lib/alicenet/index.ts listing on-chain anchoring with a cost model as a capability over a fail-closed stub; and the word "sealed" meaning, everywhere, "unsigned sha256 in our own storage."
• Trust-ladder position: rung 1 (signed local) exists as code, mostly next door; rung 2 (Merkle-committed) exists in pieces; rung 3 (anchored) exists nowhere; rungs 4–5 (BBS disclosure, settlement) are unstated aspiration.
• A schema gap that blocks the Call: DecisionCredential covers known (evidence_merkle_root, why_trace_hash) and chosen (action), but has no fields for predicted, happened, or taught. The five-field Call cannot ride a VC until they exist.

What we need from AliceNet (the asks)

1. A packaged, versioned SDK of lib/alicenet (CredentialService, MerkleService, AnchorService) importable from the precise repo — today it lives inside the konstantin.ai app tree and cannot be a dependency.
2. A working ChainAnchorAdapter or hosted anchor endpoint. AnchorService currently fails closed with CHAIN_ANCHOR_UNAVAILABLE everywhere.
3. An issuer identity for Precise — did:alice:precise or delegated authority under did:alice:konstant — with a stated key custody, rotation, and revocation convention.
4. A normative anchor_ref format plus third-party verification instructions. The gateway schema, envelope, and BQ decision_seals columns are all waiting on its shape.
5. A ruling on the Call credential schema: extend DecisionCredential with predicted/happened/taught, or pair it with an OutcomeCredential — and who owns schema versioning.
6. A boundary decision on Valence vs AliceNet as the anchor rail. proof-orchestrator targets Valence; everything else names AliceNet. One rail, or a stated relationship between them.

Questions only you can answer

1. What chain does AnchorService actually target, is anything live today, and are the index.ts numbers (~$1/M rows, <1s tx) measured or aspirational?
2. What is the anchor's finality/latency guarantee, and does the chain timestamp serve as the sealed-before-outcome clock at hourly-frontier cadence (Polymarket resolution windows)?
3. Canonicalization: konstantin.ai signs over stableReplayString; precise digests canonical-JSON v2 (lexicographic). Which is normative for cross-company verification, or do we tag both by algorithm?
4. Is BBS+ selective disclosure actually planned in lib/alicenet (today it is Ed25519 eddsa-jcs-2022 only), and on what timeline — should our Merkle leaves be designed for salt-based disclosure now and BBS later?
5. Is there a DID resolver a counterparty can run to verify did:alice:konstant signatures without trusting us, and what is the revocation story for an issued DecisionCredential (a court verdict later found wrong)?
6. The context-server stub promises an "AliceNet block id" — does any block-id API exist, or should that stub be retargeted to anchor_ref?
7. MerkleService's generateProof/verifyProof are exercised only by tests (both real consumers rebuild the full tree) — are inclusion proofs production-stable, and is the duplicate-last tree shape frozen as a spec?
8. AnchorService.anchorBatch (root → tx, poller flips status): is that contract stable enough to build the gateway anchor job against now?

The first build (proposed — your call on the canonicalization)

Committed Call batches on the PMXT prospective forward frontier. At each hourly publication cut, build a Merkle tree over the batch's prediction-time Call rows via MerkleService; store the root in the existing publication receipt with honest vocabulary (trust_tier: merkle_local, chain_anchor_status: not_requested — never "anchored" until a rail exists); retain leaves and salts privately; add a court-side verifier that checks per-row inclusion after market resolution.

Proposed leaf: sha256 over canonical-JSON-v2 of {schema: "precise.call-leaf/v1", batch_id, call_id (decision_at+condition_id), tenant, known (evidence refs incl. plan_hash, semantics_hash), chosen (action/selection), predicted (value + payoff semantics), salt (32 random bytes hex)}. Per-row salt so revealing one leaf preimage never lets a counterparty dictionary-attack sibling leaves with low-entropy fields — disclosure-free sealing now, BBS-compatible later. Only known/chosen/predicted go in the leaf; happened/taught arrive post-resolution as a separate graded record referencing the committed leaf, preserving sealed-before-outcome ordering. Open item riding on you: whether leaves must use stableReplayString for cross-repo verification — we proceed with canonical-JSON-v2 plus an algo tag until you rule.

The integration map after that (ranked by the audit)

1. small — result-store: require sealRef to resolve to a real chain entry whose payload hashes to the predicted value before an OutcomeRecord writes; refuse unverifiable refs. No AliceNet dependency; prerequisite for anchoring to mean anything.
2. small — hash-chain the eval/floors JSONL (the audit story's own foundation is currently rewritable), anchor heads once a rail exists.
3. small — extend DecisionCredential (ask 5).
4. medium — issue Ed25519 DecisionCredentials over the existing content hashes across the estate (qualification digests, experiment receipts, game_hash/phi, court verdicts): the whole estate moves to signed_local in one pattern.
5. medium — the first build above.
6. medium — one working anchor rail end-to-end (gated on your answers).
7. medium — periodic Merkle commitment over per-tenant seal-chain heads, anchored; only then does anchored:true become producible.
8. small — attach anchor refs at the two seams that already reserved them in comments (markov map root, context-server seal_ref) — this is what finally makes the OMG "sealed decisions" claim true.

What we want from you beyond answers

Your point of view. You ran this chain; you know what it was built to carry and where it groans. If the order book is arriving bottom-up through customers, the question is what AliceNet must become to be its settlement floor — and what it must refuse to become. Argue with the ladder, the leaf, the rail choice, all of it. The code's posture is already yours in spirit: never fake success.

---

Same-day research addendum (2026-08-05, later)

We ran the org repos, the alicebobs feat/valence-sdk-pipeline branch, and the local lib through a three-lane read after writing the above. The canonical reference is now ALICENET.md; it answers several questions and corrects two assumptions in this note.

Answered:

• Q1 — the chain is live and a dev-tier rail exists. AliceNet 1.0 mainnet is an Agglayer CDK Validium, EVM chain 1042, RPC api.prod.alice.net, on Ethereum since L1 block 20441993. A working anchor path exists on testnet 10042 through the hosted Valence credential service — the branch's integration test asserts real anchored txHashes. The ~$1/M-rows and <1s figures are unsourced everywhere; treat as aspirational.
• Q4 — BBS is further along than we assumed. The org commits all AliceNet VCs to BBS on BLS12-381 with NIZK selective-disclosure VPs, and the Valence side has it implemented at dev tier (real BBS+ issuance, selective disclosure, ZK possession proofs, integration-tested). Salt-now/BBS-later for our leaves matches the platform's own direction. Konstant lib stays Ed25519-only for now.
• Q5 — no counterparty-runnable DID resolver exists. did:valence resolves only through the hosted service (HTTP, API key). Revocation is spec'd but implemented as a Mongo flag. Our did:alice:* names are a convention, not a method — they must not be presented as resolvable.
• Q6 — no bespoke block-id API is needed. Chain 1042 is standard EVM JSON-RPC. Retarget the context-server stub to anchor_ref = {chain_id, tx_hash, block_number} — with one caveat: the Valence SDK returns only txHash today (block_number is 0 everywhere in the branch), so a real adapter adds a tx-to-block lookup.
• Q7 — duplicate-last is dead. The platform spec explicitly forbids duplicated nodes and mandates RFC 9162 (SHA3-256, 0x00/0x01 domain separation). Three incompatible Merkle constructions coexist across the repos, and none has production-stable inclusion proofs. The call-leaf/v1 first build should adopt the RFC 9162 shape, not bless duplicate-last; the konstantin tree's missing leaf/interior domain separation is a known second-preimage surface.
• Q8 — the anchorBatch contract assumption was wrong. The adapter promise expects final {txId, blockNumber, timestamp, network} inline; no poller exists, and the verify side has no batch kind — batch anchors currently have no chain-verification path. The obvious unbuilt bridge: a ChainAnchorAdapter over @valence-eng/credential-sdk.createDataTransaction.
• Ask 6 — resolved in substance: not two rails. Valence is the hosted identity/credential service tier operating over the AliceNet chain. The decision narrows to: integrate through the Valence service (a packaged SDK exists — @valence-eng/credential-sdk ^0.2.1 on GitHub Packages, partially answering ask 1) or write the EVM directly with ALCB gas — noting the ALCB bridge is one-way, so gas inventory strands on the L2.

New finding: konstantin's credentials are labeled eddsa-jcs-2022 but sign over stableReplayString, which is not RFC 8785 JCS — off-the-shelf verifiers will fail until the label and the serializer are reconciled.

Still yours to answer: prover/batch cadence to L1 finality (published nowhere; operators only) · whether the did:valence registry contract is deployed on mainnet, and DAC membership/custody · whether the Valence SDK's BBS+ and createDataTransaction are cryptographically real end-to-end or service-simulated · real ALCB gas costs · the canonicalization ruling (canonical-JSON-v2 vs stableReplayString vs true JCS) · the Merkle shape ruling (RFC 9162 per the spec) · the Call credential schema (unchanged from ask 5).

ℹ Safe-chain: Some package versions were suppressed during package metadata resolution due to minimum package age. To disable this check, use: --safe-chain-skip-minimum-package-age