Whitepaper v2.1 shipped two structural additions that deserve a longer write-up than a changelog entry. First, a v3 mainnet phase at month 24+ on the roadmap. Second, a custom consensus weighting at v3 called Proof of Useful Attestation (PoUA), which ties a validator's influence on the chain to the work the chain actually exists to do: valid attestations.

This post is in two parts. Part one is for anyone reading the receipt-layer pitch and wondering what changed. Part two is for engineers who want to see the mechanism, the bound, and the open problems. Skip whichever part is not for you.

Part 1. For non-technical readers

The one-line update

The roadmap now has a fifth phase. Months 24+, mainnet, with a specialised consensus weighting called PoUA active from genesis. The existing four phases (v0 devnet, v0.5 Iris and relayer, v1 identity and disputes, v2 proof-carrying schemas) are unchanged. The Themisra, Mneme, and Iris user experience is unchanged. What's new is the chain's security model at the moment it goes mainnet.

What "consensus" means, in three paragraphs

Every blockchain needs a way to decide which transactions are real and which order they happened in. Different chains do this differently. Bitcoin asks "who burned the most electricity?" Ethereum and most modern chains ask "who has the most stake on the line?" Whoever wins that question proposes the next block, and everyone else votes on whether the block is valid.

The economic logic of stake-weighted voting is straightforward. If you own more of the chain's token, you have more to lose by approving fraudulent transactions. So you have an aligned incentive to vote honestly. Your "weight" in the vote scales with your stake.

This is fine when the chain is a general-purpose computer (like Ethereum) where many different applications run on top. The chain's security has nothing to do with what runs on it; it's just the cost of capital. But for a chain whose only job is one thing, this leaves something on the table.

The simple analogy

Think of stake-only voting as: whoever owns the most chips at the poker table gets the loudest voice in deciding whether the cards were dealt correctly. That works, but it ignores whether you've actually been playing the game well.

PoUA adds a second axis: whoever owns chips AND has played valid hands consistently gets the loudest voice. On Ligate, "playing valid hands" means processing valid attestations: the actual work the chain exists to do.

If you have huge stake but haven't been doing the chain's job, your voice is reduced. If you've been doing the job perfectly but have no stake, you still need stake to participate. You need both.

Why this matters for the receipt-layer thesis

Ligate is a chain whose only job is attestations. A receipt for an AI interaction. A receipt for a regulated agent action. A receipt for a creator's prompt. The whole point is that the chain produces trustworthy receipts.

If the chain's security has nothing to do with how well it's producing trustworthy receipts, that's a category error. PoUA fixes the category error. Validator weight is tied to validator work, not to capital alone.

The deeper claim, which lives in part 2: this is not just elegant. It's measurably more expensive to attack. An adversary needs to acquire both capital AND reputation, and reputation cannot be bought on a market because it's non-transferable. The cost-to-attack premium over a comparable pure-stake chain is on the order of 4 to 10×, depending on parameters.

What is NOT changing

This is worth stating clearly because it's the part that most readers should remember.

Themisra, Mneme, Iris UX is unchanged. Submitting an attestation, verifying a receipt, signing with Mneme: nothing in that flow changes for users.
v0 through v2 still runs as standard Proof of Stake. PoUA does not exist on devnet. It activates at v3 mainnet.
No hard fork. Activation is a single governance transaction at the end of a warmup period. Reputation is computed in shadow mode during bootstrap, then turned on. No chain split.
The token economics are unchanged. $LGT distribution, fee structure, and value accrual are exactly as published in whitepaper v2.

Why a research repo, not just a whitepaper section

The whitepaper has a one-page summary in §3.8. The full design specification, the formal threat model, the cost-to-grind bound under compound capital-and-grinding adversaries, and the integration plan with Sovereign SDK live in a separate, public, working repository: github.com/ligate-io/ligate-research.

Two reasons for the split. First, a research result that's only as trustworthy as the team that wrote it isn't very trustworthy. By keeping the math in a public, separately-tracked repository, anyone (academic, competitor, suspicious investor, future protocol auditor) can review and contest it independently of the protocol team. Second, the work is genuinely ongoing. The bound is non-trivial under compound adversaries; the simulation harness is being built; the parameters at activation are still being tuned. A whitepaper section implies "we're done." A research repo implies "we're doing it in public."

That's the non-technical summary. The rest of this post is the technical version, with diagrams.

Part 2. For technical readers

The mechanism, formally

In standard stake-weighted BFT, validator v has voting weight w_v = s_v where s_v is the bonded stake. PoUA replaces this with

w_v = s_v × r_v

where r_v ∈ [0, 1] is a non-transferable reputation score. r_v accrues from processing valid attestations into committed blocks and decays on detected misbehaviour (equivocation, invalid block proposal, signing fraud confirmed by a successful dispute).

The mechanism inherits the safety and liveness properties of the underlying BFT primitive. Specifically, if the original PoS instance guaranteed safety with f < n/3 Byzantine validators by stake, the PoUA instance guarantees safety with f < n/3 Byzantine validators by s × r weight. Nothing about agreement or termination changes; only the function that maps validator identity to vote weight does.

A validator's reputation cannot be transferred to another validator. You cannot buy reputation on a market, you cannot stake-delegate reputation, you cannot inherit it from a previous validator. It must be earned, in real time, by the specific public key proposing blocks.

Why multiplicative, not additive

The formal choice of multiplicative s × r over additive s + r is doing more work than it might appear.

Under additive weighting (w_v = s_v + r_v), a wealthy adversary can saturate the stake axis and ignore reputation entirely. The cost to attack is min(stake_threshold, reputation_threshold), and an attacker with deep capital just buys past the stake side.

Under multiplicative weighting (w_v = s_v × r_v), the cost function is a hyperbolic surface. To meet a vote-weight threshold T, an adversary needs s × r ≥ T. If reputation is bounded above by 1.0, then stake must be at least T. But meaningful weight requires both: an adversary with s = T and r = 0.001 has effective weight 0.001 × T, well below threshold. To attack, they must acquire reputation as well as capital, and reputation is non-transferable, so they must earn it on-chain over time, exposing themselves to detection.

The asymmetry produces a multiplicative cost-to-attack premium of roughly 4 to 10× over the equivalent pure-stake chain, depending on the active reputation distribution at the time of attack. The specific bound (and its sensitivity to parameters) is in the research repo's working paper.

Distinction from §5.4 stake-backed attestor economics

The whitepaper's tokenomics section §5.4 describes a separate mechanism: stake bonded against an AttestorSet that signs payloads under a registered schema, with slashing on successful fraud proofs against an attestation. PoUA and §5.4 are easy to conflate. They are not the same thing.

PoUA governs the validator layer: who proposes blocks, whose votes count toward consensus. It's the chain's security against liveness and safety attacks at the consensus level.

§5.4 governs the attestor layer: who signs payloads against a particular schema, with bonded capital that gets slashed if they sign fraudulently. It's the chain's security against attestor-set-specific signing fraud at the application level.

A validator can be honest while a particular attestor set is malicious, or vice versa. The two layers fail independently and defend independently. PoUA secures who proposes blocks; §5.4 secures who signs payloads. Both feed the same chain, and both are necessary, but neither subsumes the other.

Reputation accrual and decay

Reputation is computed from on-chain observable events. Concretely:

Each block where validator v was the proposer and the block contained at least one valid attestation: r_v += δ_proposer.
Each block where validator v voted on a block that was subsequently committed: r_v += δ_voter.
A successful equivocation proof against v: r_v -= λ_equiv.
A successful fraud proof against an attestation v proposed: r_v -= λ_fraud.
Time-decay (cap on stale reputation): r_v *= γ per epoch.

The constants δ_proposer, δ_voter, λ_equiv, λ_fraud, γ are governance-tunable, with starting values chosen so that:

A new validator with full stake and zero reputation reaches r_v ≥ 0.7 in roughly 30 days of honest operation.
A single equivocation event drops r_v by 0.4 to 0.6.
Recovery from a misbehaviour event takes longer than the initial build-up, which makes the implicit punishment proportional to "lost time at full influence" rather than a flat slash.

The values are tunable in the simulation harness in the research repo. The activation values for mainnet will be finalised after external review and devnet operational data.

Why staged: PoS through v2, PoUA at v3

The natural question: if PoUA is better, why not activate it at v0?

Two reasons.

Activating early would be theatre. PoUA's security premium scales with active reputation distribution. At v0 with a permissioned sequencer and a small validator set, there is no real distribution to weight against. The premium would be negligible and would introduce complexity for no security benefit. Stake-weighted PoS is adequate for the bootstrap period.

Mainnet timing aligns with real conditions. v3 (months 24+) arrives when validator participation, attestation volume, and operational maturity have all developed against the same chain. By that point: external review of the mechanism is done, the simulation harness has been validated against real data, and the activation constants have been calibrated against operational experience. Activating PoUA into a thin chain would produce a thin guarantee.

Why activation is governance, not a hard fork

A hard fork would be the wrong tool. PoUA does not change block format, transaction format, state format, or wire encoding. Validators continue producing the same blocks they were before. The only thing that changes is the function that maps validator identity to vote weight at the consensus layer.

This is well within the scope of a single governance transaction. The chain switches from w_v = s_v to w_v = s_v × r_v at the end of an announced warmup period (during which r_v is computed in shadow mode). No chain split, no reorganisation, no client upgrade required at the wire-protocol level.

What we are NOT claiming

Three things this post deliberately does not assert.

The 4-10× bound is asymptotic. It assumes a mature reputation distribution. At activation, with reputation just out of warmup, the realised premium will be lower. This is acknowledged in the research paper's section on bootstrap stake.

Cost-to-grind is bounded but not zero. A sufficiently patient attacker who is willing to accumulate reputation honestly over months can eventually reach attacking weight. The bound covers the cost of this attack but does not eliminate it. The actual claim is that the cost is provably higher than the equivalent pure-stake attack by the multiplicative factor above, not that the cost is infinite.

Reputation is observable, not perfect. The events that accrue or decay reputation are themselves on-chain observable. A novel attack that produces malicious behaviour without leaving an on-chain signature would not be caught by reputation. PoUA defends against known on-chain misbehaviour categories, not against the unbounded set of all possible attacks. This is true of every consensus mechanism but worth saying out loud.

How to engage

The mechanism is open and contestable.

Read the working paper. It lives at github.com/ligate-io/ligate-research. Cost-to-grind bound, formal threat model, integration plan, parameter sensitivity analysis.
Open issues. Bring counter-examples, alternative formulations, parameter critiques, or attack scenarios. The research repo accepts GitHub issues from anyone.
Run the simulation harness when it ships. The harness is being written as the bound is finalised. We'll publish announcements when it's runnable.
Propose changes via governance. Once active, PoUA constants (δ, λ, γ values, the multiplicative form itself) can be amended by token-holder governance.

PoUA is not the last word on consensus weighting for an attestation chain. It's the first specialisation we found that's defensible against the obvious attacks and analysable against compound ones. We expect to learn things in operation that change parameters, and we expect external review to find issues. That's why the math is public, the simulation will be public, and the parameters are governance-controlled.

Closing

Ship the primitive. Prove it with Themisra. Distribute it with Mneme. Monetise it with Iris. Secure it with Proof of Useful Attestation.

The roadmap, as of v2.1, is whitepaper PDF here. The mechanism's full design lives in ligate-research. The chain that runs the bootstrap PoS until activation lives in ligate-chain.

Proof of Useful Attestation: securing a chain with the work it actually does.