Precise · internal · canonical reference · how AliceNet functions and acts

How AliceNet functions and acts

Authority: canonical reference for AliceNet across the Precise/Konstant estate. Synthesized 2026-08-05 from three verified lanes: the github.com/alicenet org (README, docs, whitepaper, contracts), the alicebobs feat/valence-sdk-pipeline branch, and konstantin.ai/lib/alicenet read line-by-line. Every claim below carries its source or is marked design intent. Other atlas docs cite this file instead of restating it; the engineering brief and open asks live in ALICENET-NOTE-FOR-MATT.md.

1. What AliceNet is

AliceNet is a public blockchain with MadHive lineage (the whitepaper still opens "Mad Network") that has lived two technical lives: a bespoke Proof-of-Stake UTXO sidechain described in the whitepaper (preserved as branch legacy/0.0.11, retired), and the current AliceNet 1.0 — an Agglayer CDK Validium in the Polygon zkEVM family, live on Ethereum mainnet since L1 block 20441993 as EVM chain ID 1042 (public RPC https://api.prod.alice.net/, explorer block-explorer.prod.alice.net; Sepolia testnet is chain 10042 at api.staging.alice.net). Around the chain sits Valence, an identity and credential layer: the did:valence DID method, verifiable credentials with BBS selective-disclosure signatures as the stated platform target, and a hosted credential service that mediates all chain access for its clients. In the Precise/Konstant thesis, AliceNet is the inter-network contract and durability layer — the place a sealed decision goes so that a counterparty on the other side of a company boundary can check it without trusting the party that wrote it. (Sources: alicenet/alicenet README + docs/contracts.md; alicenet/whitepaper; alicebobs branch.)

2. The chain, technically

Two generations — history vs. current, dated

The two architectures are incompatible; conflating them is the most common error in older material.

Legacy chain (whitepaper era, retired) AliceNet 1.0 (current, live)
Stack Custom Go node Agglayer CDK / cdk-erigon (upstream Polygon code, not custom)
Consensus PoS, Tendermint-style BFT rounds (Proposal/PreVote/PreCommit/NextRound); validators stake via an Ethereum contract; EthDKG-derived BLS threshold group signatures (BN254) + secp256k1 ECDSA There is no validator set. Single sequencer (0x48d51a36…), a prover (0x13b3Eb34…), and a Data Availability Committee; governance is multisig + timelock with an Emergency Consul halt role
Ethereum relationship Periodic BLS group-signed snapshots posted to Ethereum L2 anchored by ZK validity proofs (Agglayer zkEVM). Transaction data is not posted to Ethereum — the DAC holds it off-chain. That is the "validium" tradeoff: Ethereum-grade proof of state validity, committee-grade data availability
State model UTXO; DataStores (below); Compact Sparse Merkle Trie state commitment Standard EVM accounts; standard JSON-RPC
Storage/encoding BadgerDB; Cap'n Proto canonical object encoding Standard EVM

(Source: alicenet/alicenet README; whitepaper tex/consensus.tex; docs/contracts.md.) The org's own naming wobbles: the README says "AliceNet 1.0" while the zkevm-contracts repo (pushed 2024-12-06) says "modified to work with AliceNet 2.0." Same stack, two labels — cite "AliceNet 1.0 (Agglayer CDK Validium)" and note the alias when precision matters.

The DataStore model belongs to the legacy chain only

The dated key-value DataStore with deposit-funded rent is real in the whitepaper (tex/transactions.tex, tex/data_structures.tex): a DataStore is a UTXO type bound to an epoch, indexed within a namespace derived from the signer's pubkey hash, with O(1) named access; ValueStores convey tokens; state commits in a modified-Aergo Compact Sparse Merkle Trie yielding compact inclusion and exclusion proofs per block. AliceNet 1.0 carries none of this at protocol level — it is a plain EVM chain, and any dated-storage semantics must be built as contracts or supplied by the Valence service layer.

Tokens

Dual token (README + docs/contracts.md):

Other published L1 contracts: zkEVM 0x3072b422…, Rollup Manager 0x8DA537B4…, Exit Root, Bridge 0xF2aC62e8…, Data Committee 0xbbEf2b8F…, Timelock.

Finality and latency — what is and is not stated

L2 sequencer inclusion is near-immediate but soft (single-sequencer trust). Ethereum-grade finality arrives when the batch's ZK validity proof verifies on L1, and data availability rests on the DAC rather than Ethereum. The org publishes no sequencer-batch or prover cadence, and no repo in any lane contains a confirmation poller or block tracker. Sealed-before-outcome at hourly cadence therefore gets an instant L2 timestamp and an undocumented lag to independently verifiable L1 finality; the cadence numbers must come from the operators (Matt-note question 2, still open at that layer).

Activity status, honestly

Maintained but quiet. alicenet/alicenet: last substantive human commit 2025-09-18 ("Link v0.0.11 history as ancestor; keep v1.0.0 tree" — the repo now holds only docs + smart contracts; the node software is upstream Agglayer CDK); dependabot activity into Feb 2026. utilities (indexer→GCP Spanner, JSON-RPC proxy) pushed 2026-03-05. The whitepaper repo was pushed 2025-09-16 but its content describes the legacy chain. alicenetjs, explorer, wallet, and all UI repos have been dormant since 2022–2023. The mainnet chain itself is live and answering RPC. Call the platform live but low-velocity: an operating chain with a small maintained surface, not a dead project and not a bustling one.

3. The primitives it provides

DIDs and verifiable credentials

Platform commitment (alicenet/alicenet docs/w3c_discussion.md): W3C DIDs/VCs via the did:valence method — DID = u + 43 base64url chars encoding 32 bytes (SHA3-256 of the pubkey, Ethereum-address style); self-signed DID documents (Subject == Controller); verification keys secp256k1 ECDSA or ed25519; issuer DID documents stored in a smart contract on AliceNet so "AliceNet acts as its own PKI"; Valence handles registration and revocation, both only after authentication. Status: the design is written in future tense; no resolver software, registry contract address, or status-list mechanism is published. In practice today, did:valence resolution happens through the hosted Valence credential service over HTTP with an API key (alicebobs did.service.ts, 5-minute Redis cache) — a counterparty cannot yet run an independent resolver. Separately, Konstant's did:alice:* identifiers (did:alice:konstant, did:alice:<tenant>:<operatorId>) are a naming convention with no method spec, DID documents, or resolver — they are not the did:valence method and should not be presented as resolvable.

Signature suites

Three suites coexist, at different maturity:

Merkle trees and proofs — one spec, three incompatible constructions

This is the sharpest conflict in the audit and it must be resolved before cross-party proofs mean anything:

  1. The AliceNet/Valence spec (alicebobs specs/verification/merkle_trees.md, specs/identity/merkle_tree_libs.md) mandates RFC 9162: SHA3-256, 0x00/0x01 leaf/interior domain separation, split-at-largest-power-of-two — and explicitly forbids duplicate-last: "No nodes should be duplicated… makes it possible to provide incorrect inclusion proofs." Reference code exists in Python only.
  2. The alicebobs backend implementation contradicts its own spec: duplicate-last SHA-256, no domain separation, single leaf returned unchanged as root — and it computes roots only; it never generates or verifies inclusion proofs.
  3. Konstant's MerkleService is a third shape: duplicate-last SHA-256 over concatenated hex strings (not raw bytes), leaf = sha256("id:content"), no domain separation. Its proofs are real and strictly verified (odd-tree inclusion, tamper/index rejection, proof.length === ceil(log2(leaf_count)) enforced — which makes its proofs incompatible with RFC 9162 proofs by construction).

Ruling status: the duplicate-last shape is not frozen anywhere and the platform spec forbids it. Inclusion proofs are production-stable nowhere in the stack (Konstant's are well-tested code without a written frozen spec; both production consumers rebuild the full tree rather than use proofs). Any leaf format Precise freezes (see §5) should be designed so the tree shape above it can move to RFC 9162 without changing leaf preimages.

Selective disclosure

Live on the Valence side (BBS presentations + ZK threshold/possession proofs, integration-tested, dev tier). Absent in Konstant's lib (Ed25519 only; the sole partial-reveal mechanism is Merkle inclusion). The interim answer for Precise is salt-based disclosure: per-row salts in Merkle leaves so revealing one preimage never lets a counterparty dictionary-attack siblings — deliberately BBS-compatible later, matching the platform's own stated direction. One named org project wants deterministic VPs with consistent identifiers computed from the NIZK BBS proof — data lineage over presentations — which is adjacent to exactly what the Call needs (design intent, unbuilt).

The anchoring path

Two candidate paths onto chain 1042/10042, neither wired into the Precise/Konstant estate:

4. The SDK surfaces

alicenetjs — legacy chain only, dormant

AliceWallet(chainId, rpc) with secp256k1/BN accounts, Transaction.createValueStore / createDataStore(address, index, duration, rawData, issuedAtEpoch), UTXO-selecting sendTx, an RPC module. README self-describes as "highly unstable" alpha; npm package is @alicenet_/alicenetjs-legacy; dormant since 2023-03-01. It cannot talk to the 1.0 EVM chain — that takes ordinary ethers/viem. Do not build on it.

@valence-eng/credential-sdk + the feat/valence-sdk-pipeline branch

There is a packaged SDK Precise could import: @valence-eng/credential-sdk ^0.2.1 on GitHub Packages (@valence-eng scope; needs GITHUB_TOKEN in .npmrc). It is an HTTP client — new ValenceClient({baseUrl, apiKey}) — to the hosted Valence credential service. Surface exercised by alicebobs: authenticate/createAndAuthenticate (USER|ISSUER), getDid, resolveDid, createCredential, verifyCredential, createPresentation, verifyPresentation, proveRating, provePossession, createDataTransaction, createDAGEntry, healthCheck, alcb.{getBalance, transfer, burn, faucetClaim}.

What the branch proves: a working dev-tier anchor rail exists. The integration test hard-fails unless the service answers /v1/health, then asserts real did:valence creation, BBS+ issuance, selective disclosure, ZK proofs, and a signal anchored with a transaction_hash on chain 10042. Dev infra runs on Valence's GKE (*.dev.valence-platform.xyz); the live service URL is a CI secret.

What the branch does not prove: production anchoring. block_number is hardcoded 0 in every stored Anchor, the anchor timestamp is the local clock, anchoring is best-effort (failures logged and swallowed; the record is stored unanchored), the SDK returns only txHash with no tx→block lookup, nothing mainnet or public is committed, and the SDK internals (whether BBS+/ZK proofs are cryptographically real, whether createDataTransaction commits a root on-chain or a blob in a tx) are unverifiable from the repo. This branch is also the moment alicebobs deleted its previous simulated AliceNet (a mock with a fabricated local block counter) — the estate's refuse-to-fake norm arriving there too.

konstantin.ai/lib/alicenet — the local trust library (exact API)

Five source files + one test (~700 lines; trust-ladder.test.ts is the only test — all mocks are vi.fn, no network). Public surface via index.ts:

Status honestly: the code has advanced past the plans that describe it — plans 015/016 (2026-06-19) call anchor.ts a fake-txId mock and verifyProof a stub; the current code is the post-rewrite fail-closed version (fixtures dated 2026-07-12). What remains missing is any real adapter. The library also lives inside the konstantin.ai app tree and is not yet an importable package (Matt-note ask 1). The ~$1/M rows, <1s tx numbers in its index.ts header are an unsourced doc comment citing a hackmd; treat as aspirational until measured on chain 1042. All verify.konstant.cloud URLs are generated strings with no deployed endpoint behind them.

The unbuilt bridge

The natural integration — a real ChainAnchorAdapter implemented over @valence-eng/credential-sdk.createDataTransaction — has been built by no one. It is the single highest-leverage piece of missing code in this whole map, with one contract friction to resolve: the adapter promise expects blockNumber inline and the SDK returns only txHash (today alicebobs papers over this with a hardcoded 0 — an adapter must not).

5. How a Call rides it

A call is a decision made on the record: what was known, what was chosen, what was predicted at what confidence — and, once scored, what happened and what that taught the system. Signed, so anyone can re-check it. Lifecycle: make the call → score it → book the lesson; the compounding asset is the track record; the exported ledger is the call sheet. AliceNet is what lets a call sheet survive a company boundary.

The commit → anchor → verify lifecycle

  1. Make the call (sign locally — rung 1). The five-field record is canonicalized, digested, and signed. Today's vehicle is the Ed25519 DecisionCredential; known schema gap: it 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 (extend it or pair an OutcomeCredential; Matt-note ask 5, open). Result: trust_tier: signed_local.
  2. Seal the batch (Merkle commit — rung 2). At each publication cut (e.g., the hourly PMXT frontier), build a Merkle tree over the batch's salted call leaves; store the root in the existing publication receipt with honest vocabulary — trust_tier: merkle_local, chain_anchor_status: not_requested; retain leaves and salts privately.
  3. Anchor the root (rung 3). One adapter.anchor call per batch; the resulting anchor_ref is the tuple {chain_id (1042|10042), tx_hash, block_number} — AliceNet 1.0 needs no bespoke block-id API because it is standard EVM JSON-RPC. Without a rail, refuse: CHAIN_ANCHOR_UNAVAILABLE, tier stays where it was. Never write anchored: true from any path that cannot produce it.
  4. Score it (post-outcome). Happened and taught arrive after resolution as a separate graded record referencing the committed leaf. Sealed-before-outcome is checkable because the anchor timestamp — a clock nobody owns — predates resolution.
  5. Verify (counterparty side). Recompute the disclosed leaf preimage + salt → leaf hash → inclusion proof → root → chain lookup (anchored payload_sha256 must match) → issuer signature check. Today steps beyond signed_local verification are not independently runnable: the chain lookup has no batch kind, the DID has no independent resolver, and no anchor exists to look up.

The trust ladder

unverified → signed_local → merkle_local → chain_anchored. The lib encodes three of these; merkle_local is Precise vocabulary for the batch-committed-but-unanchored tier (the Matt-note first build) and is not yet in lib code. Estate position, audited 2026-08-05: rung 1 exists as code (mostly in konstantin.ai); rung 2 exists in pieces (research-core Merkle with working proofs, Konstant MerkleService, alicebobs roots); rung 3 exists as a live chain plus a dev rail nothing of ours touches; rungs 4–5 of the mechanism (below) are Valence-side reality and stated aspiration respectively.

The precise.call-leaf/v1 sketch (design intent, proposed)

Leaf = sha256 over the canonical form 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)}. Only known/chosen/predicted go in the leaf; per-row salt makes single-leaf disclosure safe against dictionary attack on low-entropy siblings — disclosure-free sealing now, BBS-compatible later (which this synthesis confirms is the platform's own direction). Two open rulings ride on Matt: canonicalization (we proceed with canonical-JSON-v2 plus an algorithm tag; no lane found any cross-repo normative form — alicebobs hashes raw insertion-order JSON.stringify, Konstant signs stableReplayString, the legacy chain used Cap'n Proto, and canonical-JSON-v2 exists only in Precise) and tree shape (the platform spec mandates RFC 9162 with domain separation and forbids the duplicate-last shape both current implementations use — the freeze should weigh adopting RFC 9162 rather than blessing duplicate-last).

6. Role in the capability network

The problem nothing else in the stack solves: Company A's agent uses Company B's capability, and later both sides must prove things about what happened — authority, provenance, contribution — without either opening its books and without a hyperscaler as the trusted middleman. AliceNet is the durability layer that makes those proofs outlive both companies' storage, and the contract layer both can cite. The mechanism is five rungs, each with a current, audited status:

Rung What it does Status (2026-08-05)
1. Credentials Portable authority (who may act, issued as VCs) Code real: Ed25519 in konstantin.ai (production-consumed by v-extract correction ledger + adjudication court); BBS dev-tier on Valence side
2. Merkle sealing Disclosure-free commitment of call batches Pieces real (research-core, MerkleService, alicebobs roots); shape unfrozen, three constructions in conflict
3. Anchoring A clock nobody owns; sealed-before-outcome across company lines Chain live (1042); Valence dev rail works on 10042; nothing in the Precise/Konstant estate anchors anywhere
4. Selective disclosure The proof crosses, the data stays home Live on Valence side (BBS + ZK proofs, dev); salt-based interim design for Precise; absent in konstantin lib
5. Settlement Contribution settlement — the order book Unbuilt aspiration. ALCB is gas, not settlement machinery; design intent only

Boundary discipline (015 §8, and the repo boundary skill): AliceNet is the third-party non-repudiation rung above Boombox's self-notarized seal chain — Precise labels its own seals anchored:false until a real anchor lands, and anchor failure degrades to the lower tier without ever blocking a run. A local port or reference adapter in our tree never establishes that AliceNet has a capability; only the lanes above establish that. The Valence-vs-AliceNet question resolves as one chain, two access tiers: Valence is the hosted identity/credential service operating over AliceNet, not a competing rail — the remaining decision is whether Precise integrates through the Valence service or writes the EVM directly.

7. Vocabulary

Term Meaning
AliceNet legacy The whitepaper's PoS/UTXO sidechain (branch legacy/0.0.11); retired. DataStores, BFT rounds, BLS snapshots belong here
AliceNet 1.0 Current chain: Agglayer CDK Validium, EVM chain 1042 (testnet 10042). Also labeled "2.0" in zkevm-contracts
Validium ZK-proven L2 whose tx data lives with a committee, not on Ethereum
DAC Data Availability Committee — holds AliceNet 1.0 tx data off-chain
ALCA Governance/staking token (MAD migration), ERC-20 on Ethereum
ALCB Utility token; L2 gas. Bought with ETH on L1, bridged one-way down
DataStore Legacy-chain dated KV UTXO with deposit-funded rent; no 1.0 equivalent
Valence Identity/credential layer + hosted service over AliceNet; operates the dev rail
did:valence Platform DID method: u + 43 base64url chars (SHA3-256 of pubkey). Resolvable today only via the hosted service
did:alice:* Konstant naming convention (did:alice:konstant etc.); not a resolvable method
VPID Verifiable-presentation identifier anchored via createDataTransaction
call A decision made on the record: known, chosen, predicted-at-confidence — and once scored, happened and taught. Signed, re-checkable
call sheet The exported ledger of calls
trust tier unverified / signed_local / merkle_local (Precise vocab) / chain_anchored
anchor_ref {chain_id, tx_hash, block_number} — the normative anchor pointer
ChainAnchorAdapter Konstant's one-shot anchor seam; only implementation is a test mock
stableReplayString Konstant's sorted-key JSON canonicalizer (not RFC 8785 JCS)
canonical-JSON-v2 Precise's lexicographic canonical JSON (gateway digests); exists only in Precise
precise.call-leaf/v1 Proposed salted Merkle leaf carrying known/chosen/predicted (design intent)
refuse-to-fake The shared posture: fail closed, never mint a tier the code cannot prove

8. What is NOT true today

The refusal list. None of the following may be claimed in any Precise/Konstant material until the cited condition changes:

  1. No Precise or Konstant code anchors to any chain. anchored:false is hardcoded in the gateway envelope; AnchorService without an adapter returns CHAIN_ANCHOR_UNAVAILABLE; the only ChainAnchorAdapter implementation anywhere is a vitest mock. The valence branch proves a dev-tier rail exists (live service, real txHashes on testnet 10042) — in alicebobs, dev-only, best-effort, block_number 0, service internals unverifiable — and nothing of ours imports it. anchored:true remains unproducible in the estate.
  2. "Sealed" in the Precise estate still means an unsigned sha256 in storage we control — integrity to ourselves, proof to no one else — until credentials and anchoring land at the seams that reserved them.
  3. The ~$1/M-rows and <1s-tx figures are unmeasured. They exist only as a doc comment citing a hackmd; no benchmark, fee schedule, or gas measurement exists in any of the three lanes. Structurally plausible for a Merkle-batched anchor; quote as aspiration only.
  4. No finality/latency guarantee exists in code. No confirmation poller, no block tracking, no published prover cadence. Hourly sealed-before-outcome currently holds only at signed_local/merkle_local tiers.
  5. Merkle inclusion proofs are production-stable nowhere, and the duplicate-last shape both implementations use is explicitly forbidden by the platform's own spec (RFC 9162 mandated). Three incompatible constructions coexist; no shape is frozen.
  6. No counterparty-runnable DID resolver exists — did:valence requires the hosted service + API key; the on-chain DID registry is future tense with no published address; did:alice:* resolves to nothing. Verification of Konstant credentials requires out-of-band possession of the issuer's public key.
  7. No revocation registry is wired anywhere. The Valence spec (provider-DID and access-credential revocation on-chain; user DIDs never revoked) is implemented only as a Mongo status flag; Konstant credentials have no status mechanism at all.
  8. BBS selective disclosure is not a Precise/Konstant capability. It runs on the Valence side (dev tier, with the signal-VC proof_value mislabeling caveat); our stack is Ed25519 and sha256. The eddsa-jcs-2022 label currently overstates JCS conformance.
  9. verify.konstant.cloud does not exist — every verifyUrl is a generated string with no deployed endpoint.
  10. alicenetjs cannot reach the live chain (legacy-only, dormant since 2023); DataStore rent semantics do not exist on AliceNet 1.0.
  11. No cross-repo canonicalization is normative. alicebobs, Konstant, and Precise each hash a different serialization; a normative form must be chosen and imposed, not discovered.
  12. AnchorService.anchorBatch is not a stable cross-party protocol — it is a coherent local seam whose verify side lacks a 'batch' kind and whose adapter contract has no poller, retry, or finality semantics.

The posture that makes this list short next year is the one already in the code: never fake success.

ℹ 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