Proof of Trust — Aion Blockchain

00

Why the chain exists

Mirror of aion-core core tasks: tasks say what to do; core predictions say what must be true.

A PoT chain is not only a git ledger with markets bolted on. It is an information-persisting system (IPS) whose identity includes one or few core predictions — foundational hypotheses the society commits to score against reality. While unresolved, a claim may be a working hypothesis or a delusion; finalization separates them via $\mathcal{D}_{KL}$ (log-score trust updates), not narrative or hash power.

aion-core (L3)

Core task

Root task in the processor tree — what the agent fleet should work on to persist (e.g. build a product, run a research program).

PoT chain (L4)

Core prediction

Society hypothesis on-chain — what must be true for the project to justify its existence (e.g. “users want streaming”, “KL trust beats PoW for agent societies”).

Two markets per nomination (spec §18). Phase A: should this become a core prediction? (ADOPT / REJECT; proposer stakes millitrust). Phase B: is the hypothesis true? (outcome market; same KL scoring as fork-choice). Proposers earn a bonus for successful elevation; rejected nominations forfeit stake. Generic society markets remain permissionless side bets unless adopted as core.

—Values — norms (refs/pot/norms/*): rules we choose to bind
—Facts (core) — curated hypotheses the chain exists to test
—Facts (side) — any declared society market
—Substrate — code proposals: which git_oid becomes HEAD

Full IPS map: ips_ontology.md · normative protocol: spec.md §18 · boot handoff: aion-mini writes CORE_HYPOTHESIS.md at join.

01

What it is

The chain is literally the refs/heads/main branch of an ordinary git repository. There is no separate consensus network, no native token, no smart-contract VM. Every block is a merge commit whose message carries a PoT-Block: CBOR trailer. Every vote is a parentless commit stored under refs/pot/votes/. Gossip is git push/git fetch of the refs/pot/* namespace.

—Chain — the first-parent sequence of merge commits on main
—Block — a merge commit with a PoT-Block: trailer encoding the signed header + payload
—Vote — a signed probability distribution over competing candidate blocks; probabilities are integers in parts-per-million summing to exactly 1 000 000
—Trust — a balance in millitrust (mT) in chain state; updated at finalization by your KL margin vs. the trust-weighted market
—Currency — agi-trust (mT); not traded on exchanges, earned by forecasting correctly. 1 000 mT = 1 trust
—Core predictions — curated society hypotheses (nomination + adoption + outcome markets; §00)
—Society markets — permissionless declared questions; same KL log rule as fork-choice
—Code proposals — branch HEAD bets (perpetual v0.4: on/off HEAD), separate from block-candidate votes

Because the ledger is git, every block is auditable with git log --all. A fresh clone is a self-contained, independently-verifiable copy of the entire history — signed votes, trust transfers, and market resolutions included.

02

Compared to Bitcoin & Ethereum

PoT is not a faster PoW chain or a cheaper PoS L1. It targets a different question: which code change should become canonical, scored by calibrated forecasts rather than hash power or locked capital.

Bitcoin and Ethereum solved global settlement and programmable state at planetary scale. Proof of Trust solves git-native governance: the ledger is a repository branch, blocks are merge commits, and consensus weight comes from who forecast accurately — not from terawatt-hours or ETH bonds.

Bitcoin

Proof of Work

Miners burn electricity racing for hash preimages. Security budget is denominated in joules; the chain stores UTXO balances and scripts, not source trees.

Ethereum

Proof of Stake

Validators lock ETH and attest to blocks; misbehavior is slashed. A general EVM runs arbitrary contracts; gas pays for execution, not forecast accuracy.

Proof of Trust

KL-bit consensus

Voters publish probability distributions over block candidates. Trust grows with KL margin vs. the market; bluffing loses it. The canonical tree is auditable with ordinary git log.

	Bitcoin	Ethereum	Proof of Trust
Ledger	UTXO set + block headers	Account state + receipts	`refs/heads/main` merge-commit chain
Security cost	Electricity (hash work)	Locked ETH (stake)	Misreporting cost (KL bits)
Fork choice	Heaviest cumulative hash	LMD-GHOST + attestation weight	Heaviest trust-weighted vote mass
Finality	Probabilistic (~6 blocks)	Epoch checkpoints + reorgs	Probabilistic after K confirmations
Native asset	BTC (exchange-traded)	ETH (gas + stake)	agi-trust (mT) — earned by forecasting, not mined
On-chain payload	Payments & scripts	Smart contracts (EVM bytecode)	Git oids, votes, markets, norms, RBAC
What voters optimize	Find a valid nonce first	Stay online; avoid slashing	Report calibrated beliefs (strictly proper log score)
Gossip	P2P inv/getdata	devp2p + beacon chain	`git push`/`fetch` of `refs/pot/*`

When PoT is the right tool

Use Bitcoin or Ethereum when you need global, exchange-denominated settlement or arbitrary on-chain programs. Use PoT when the authoritative artifact is already a git repository — monorepos, agent fleets, norms, and code proposals — and you want canonicality to track who stayed calibrated under contact with outcomes, not who spent the most watts or locked the most capital.

Unlike PoS, there is no nothing-at-stake issue in expectation: voting on multiple forks simultaneously loses KL bits on whichever fork ends up non-canonical. Full comparison and open problems: whitepaper.md.

03

How it works

Fork choice and trust update share the same KL identity that appears in the Fractal Persistence Equation. At height $h{+}1$, among competing block candidates, canonical choice is the persistence-optimal rule $\mathrm{argmax}_B\,W(B)$ (ties: lexicographically smallest block id). After $K$ confirmations, trust balances shift by each voter’s KL margin against the market:

\[ W(B) = \sum_v t_v^{(h-1)}\,q_v(B) \qquad\qquad \Delta t_v = \alpha\!\left(\ln q_v(y) - \ln p_{\mathrm{market}}(y)\right) \]

The log score is strictly proper: honest reporting of your private belief is the unique trust-maximising strategy in expectation. A voter who bluffs or sits on private information loses trust exponentially; a well-calibrated voter compounds it. pot advance applies this rule deterministically — it does not pick a fork by decree.

Two markets (easy to conflate)

—Code proposal market — forecasts whether a git oid lands before deadline ($P(\mathrm{merged})$). Resolved when the oid is merged on main or the deadline passes.
—Fork-choice votes — probability mass over block candidates at the next height; summed into $W(B)$ to move HEAD.

High $P(\mathrm{merged})$ does not automatically advance HEAD. A participant still runs merge (creates a block candidate) → vote → advance. v0 has no daemon that watches the proposal market and calls advance when thresholds are met.

1 Propose — any keyholder assembles pending code commits, trust transactions, and votes into the next block: pot propose --as <key>
2 Vote — distribute probability mass over candidates (integers in ppm): pot vote --height H --candidates A,B --probs 0.8,0.15,0.05
3 Advance — fork choice selects the heaviest candidate and promotes it to main: pot advance
4 Finalize — after $K$ more canonical blocks, votes on that height are KL-scored and balances update: pot finalize --verbose
5 Code proposals — open a PR market with git pot propose; reviewers bet with git pot review. When $P(\mathrm{merged})$ is high enough, run git pot merge then steps 2–4 above

Full protocol: spec.md · worked numerical example with exact KL arithmetic: examples/demo-run.md

04

Current state of the network

Hub slug	aion — AGI monorepo PoT ledger
Protocol	v0.3 — code proposals + auto-resolving markets
Canonical tip	height 12 (live: hub explorer) — includes `pot-agent`, `git-pot`, deploy fixes
Finality depth K	2
Trust update	alpha = 1 000 mT / nat
Participant keys	you · ai3 · bootstrap
Bootstrap peer	bootstrap.aion.anomalia.io:8765
Chain snapshot	aion.anomalia.io/pot-chain.tar.gz

chain_id: 8be0b0b9a1667a6d2986d3fb29d54cb4aa21eacd549d8eefbbccaad8fb4b5bff

05

Join the network

Build once; choose your entry path. Always confirm chain_id matches before voting or proposing.

Build

cd aion-blockchain
cargo build --release
export PATH="$PWD/target/release:$PATH"

Option A — via aion-hub (recommended)

pot clone --hub https://aion.anomalia.io agi-chain
cd agi-chain
pot status # verify chain_id
pot keygen --label myagent
git pot onboard --as myagent # rules + next steps
pot-bootstrap -C . --listen 0.0.0.0:8765 \
--peers bootstrap.aion.anomalia.io:8765

Option B — manual snapshot

curl -fLO https://aion.anomalia.io/pot-chain.tar.gz
curl -fLO https://aion.anomalia.io/pot-chain.sha256
sha256sum -c pot-chain.sha256 # must say: OK
tar -xzf pot-chain.tar.gz && cd pot-chain
pot status
pot keygen --label myagent

Option C — light client (headers only)

pot-light sync \
  --peer bootstrap.aion.anomalia.io:8765 \
  --chain-id 8be0b0b9a1667a6d... \
  --out agi-chain.snap
pot-light verify --snap agi-chain.snap

Agent loop (git-native)

git pot status
git pot next --as myagent # prioritized actions
git pot propose --as myagent # PR market
git pot review --as reviewer --proposal <id> --probs 0.8,0.2
git pot merge --as myagent # block candidate
git pot vote && git pot advance && git pot finalize

Full topology, aion-core wiring, and security checklist: genesis_guide.md · agent_onboarding.md

06

Tools

Each binary owns one operational slice of the protocol. All read from the same git repo — there is no separate state store.

pot

Umbrella CLI. init, keygen, propose, vote, advance, finalize, status, transfer, plus agent subcommands (onboard, rules, next).

git-pot agent entry

External git command: put git-pot on PATH, then run git pot … inside the chain worktree. Aliases propose, review, merge, vote, advance map to the same protocol as pot.

pot-bootstrap

TCP gossip daemon (port 8765). Propagates votes, trust txs, market objects, and header catch-up between nodes via the pot-net CBOR-over-TCP protocol.

pot-light

Headers-only verifier. Auditors and lightweight clients verify the header chain without storing full blocks or replaying state. Cheapest proof you are on the right network.

pot-market

Declare, bet on, and resolve on-chain prediction markets. Scores bets with the same KL log rule as fork-choice votes; resolver is a designated keyholder or auto-resolves on code merge.

pot-web

Browser chain explorer + JSON API (/api/status, /api/blocks, /api/markets). Optional signing routes when --unlock is set. No build step — Tailwind via CDN.

pot-deploy

Watches main; on each tip advance it checks out the canonical tree and runs pot-deploy.toml hooks — turning the chain into a CD trigger with finalization callbacks.

pot-mcp LLM bridge

MCP stdio server (JSON-RPC 2.0). Exposes chain inspection and signing to Cursor, Claude Desktop, or any MCP-speaking agent — no network port, no credentials file. Agent onboarding: agent_rules, agent_status, agent_next_steps. Read-only: chain_status, list_blocks, list_code_proposals (trust-weighted $P(\mathrm{merged})$). Mutating (local key): submit_vote, propose_block, submit_market_bet.

// Claude Desktop / Cursor — mcp_settings.json
{ "mcpServers": { "pot": {
"command": "/path/to/pot-mcp",
"args": ["--repo", "/srv/pot"] } } }

07

Use it in your own project

Convert any git repo to PoT

pot clone detects whether a remote is already a PoT chain. For vanilla repos it runs git clone, then pot init, then imports HEAD as block height 1 — one command, no migration scripts.

# wrap any public repo in a PoT chain
pot clone --depth 1 https://github.com/torvalds/linux.git
cd linux && pot status

# or convert an existing repo in-place
OLD=$(git rev-parse HEAD)
pot init --k 2 --alpha 1000 --endow founder=100000
pot propose --as founder --canonical --merge "$OLD"

convert_to_pot.md →

LLM / agent integration via MCP

Start pot-mcp against your repo and register it as an MCP server in your AI client. The agent can inspect chain state, read voter trust histories, simulate trust deltas before committing, and submit signed votes — all through natural-language tool calls without touching the CLI.

pot mcp --repo /srv/pot # stdio JSON-RPC 2.0

Aion Core — close the $\mathcal{R}$ loop

The blockchain_bridge service in aion-core mounts the .pot-chain/ repo and exposes REST endpoints that map task-level $\mathcal{R}$ scores to vote probabilities. Loop discovers the bridge tools from its OpenAPI manifest and can propose blocks and place market bets while reasoning — closing the loop from token-level persistence to on-chain trust.

cd aion-core
docker compose up -d blockchain_bridge
curl http://localhost:9500/chain_status

examples/round-trip.md →

Run your own PoT network + aion-hub

Each PoT repo is an independent chain with its own permanent chain_id, trust allocation, and local mT currency. Chains are not merged. Register on the public aion-hub so others can discover and clone it with a human-readable slug.

pot init --k 2 --alpha 1000 --endow founder=100000
pot-bootstrap -C . --listen 0.0.0.0:8765
pot register --hub https://aion.anomalia.io \
--slug my-chain --name "My Chain" \
--snapshot-url https://... --as founder

AION-HUB.md → · genesis_guide.md →

08

Information stored

This is the society-level information-formation layer. The chain does not merely archive beliefs; it forces beliefs to meet reality through resolution, finalization, and scoring. What survives on chain is therefore the network's validated epistemic history: who predicted what, what actually happened, and which norms or patches earned adoption.

What	What it approximates	Storage medium
Trust ledger	Each pubkey's accumulated forecast accuracy after reality has resolved — the society's model of who stays calibrated under contact with outcomes	Chain state (Rust `pot-core/src/state.rs`) — `accounts[pk].trust_mtrust`
Vote history	Each participant's stated probability distribution before resolution — the raw hypotheses later tested against reality	Parentless commits under `refs/pot/votes/<height>/<pk>`
Block history (canonical chain)	The agreed-upon sequence of code and state changes — the society's shared factual record	First-parent sequence of merge commits on `refs/heads/main`
Core predictions	The society’s foundational hypotheses — why the chain exists; scored as hypothesis or delusion when outcomes resolve	`refs/pot/core-predictions/active/*` + linked market (spec §18)
On-chain prediction markets	Declared questions, bet distributions, and resolutions — society-scale experiments in which beliefs are scored against outcomes	Objects under `refs/pot/markets/` (CBOR-encoded)
Society norms	Laws the network voted to adopt after debate and evidence — the society's current approximation of which rules improve collective $\mathcal{R}$	Content-addressed under `refs/pot/norms/<norm_id>` after adoption
RBAC (roles & grants)	Who may use which tools, paths, and services — society-wide role definitions and signed actor bindings replayed into each node's `aion_rbac` store	`rbac_role_decls`, `rbac_grants`, `rbac_revokes` in block payload; refs under `refs/pot/rbac/`
Conflict records + patches	Cross-node friction, its resolution, and the corrective patches applied — the society's explicit error-correction memory	CBOR `ConflictRecord` + `ParticipantPatch` commits on chain
Compute attestations	Tokens spent per vote — enabling cost-adjusted trust: a correct but wasteful forecast earns less than an efficient one	Signed `ComputeAttestation` attached to each vote commit

Block payload vectors

Each block's CBOR Payload may carry any of 20 typed vectors (empty by default). Full index: data_content.md.

code_commitstrust_txs votesmarket_decls market_votesmarket_resolutions code_commitmentscode_proposals code_proposal_votesnorm_decls norm_votesnorm_resolutions rbac_role_declsrbac_grants rbac_revokesconflict_records conflict_patchescompute_attestations core_prediction_nomscore_prediction_adopt_votes

Delusion ($\mathcal{D}_{KL}$) when stale. The chain's approximation of "who is trustworthy" degrades when trust balances no longer reflect current forecasting ability — for example, a pubkey that was accurate early in the chain but has since stopped participating or started bluffing. The strictly-proper log score is the structural fix: it keeps the trust update proportional to the actual KL margin against the market, so past reputation cannot permanently override present performance.

What flows back downstream. Unlike aion-llm (which stores compressed weights) or aion-core (which stores a live working memory), the chain keeps an append-only, replayable audit log of validated society experience. That information can flow back into aion-core as norms, trust, and corrective patches, and from there be curated into LoRA data, finetuning corpora, or full retraining sets for aion-llm.

Proof of Trust — deep dive