If a system acts on information, it needs to know how much it can trust that information. Right now most systems only ask one question: is the data there or not? But "it's there" can mean a lot of different things. Some facts got checked independently. Some were seen firsthand. Some were just something another party said, passed along without a check. Treat all three the same, and bad information quietly turns into confident, wrong answers.
Proof-state is how we keep that difference clear and readable by a machine. It lets a system, an auditor, or another agent ask not just "what happened?" but "how solid is that, and what am I allowed to do about it?"
Evidence tiers: how we know what we know
Every receipt gets an honest label showing how the event was actually witnessed. In Hive's Receipt Relay, there are three tiers:
- Self-attested. Another system described the event, and Hive signed that description as stated. The signature proves the claim was made and hasn't been altered. It doesn't prove the claim itself is true.
- Relay-observed. Hive made the call itself and signed hashes of the request and response. The receipt shows what Hive actually saw, not just what it was told.
- Chain-verified. The event got checked against an outside source, like reading a transaction back from a public blockchain when someone supplies the transaction hash.
These tiers go from weaker to stronger, but the goal isn't to force everything up to chain-verified. Most events are fine sitting at self-attested or relay-observed. What matters is that the receipt tells you honestly which tier it earned. It never dresses up a weaker tier to look like a stronger one.
The weakest link sets the ceiling
Most real workflows are a chain of events, and a chain is only as strong as its weakest link. Say nine steps are relay-observed and one is self-attested. The honest way to describe the whole thing is: it contains a self-attested step. Proof-state carries that forward as the weakest proof boundary, a single, cautious read of how far you can trust the whole group. That's what stops a long record that's mostly solid from getting marketed as fully verified just because most of it checks out.
What it lets you do next
Proof-state isn't just about looking backward. Because it tells you how solid something is, it can also decide what happens next. A high-value action might need a relay-observed or chain-verified boundary before it can go through. A self-attested boundary might only be allowed to pause, get reviewed, or get routed for a stronger check. That turns proof from something you check after the fact into something a system can act on right away. And it stays honest, because the gate reads the same cautious boundary that anyone else could check for themselves.
R3Pv: where receipts turn into one proof-state
A single receipt describes one event. Most real questions are about a group of them: a session, a task, a slice of data, a payment flow. R3Pv is the layer that groups receipts into one signed proof vector. That's one object that reports how deep the verification goes for the whole group, its weakest proof boundary, a healing state, and a recommendation for what to do next. It's how proof-state scales from a single event up to a whole workflow, without making a reviewer replay every receipt by hand.
To be clear about what it does and doesn't do: R3Pv groups and reports proof-state honestly. It doesn't manufacture verification the underlying receipts don't already have, and it can't undo events that already happened. What it gives you is an accurate, signed summary, not a stronger claim than the evidence actually supports.
Why AI needs this now
In the past, people could sort out proof questions after the fact, one incident at a time. AI agents, robots, and payment systems run constantly and at high volume. So the question "how solid is this?" has to get answered right away, in a form other systems can read.
- Agent receipts carry a proof-state so a downstream agent knows whether an earlier decision was actually observed or just claimed.
- Machine and robot data keeps its proof-state long after it's collected, so buyers can tell high-trust recordings apart from lower-trust ones.
- Payment receipts use these tiers directly. A self-attested intent isn't the same thing as a chain-verified settlement, and proof-state keeps the two from getting mixed up.
Systems already track what's true and what's pending. Proof-state adds the piece they were missing: what's actually proven, how solid it is, and what that allows next.
Proof isn't just yes or no. Proof-state treats it as what it really is: a range, labeled honestly, that a machine can reason about. This builds directly on why receipts, not logs, are the real unit of proof, and it depends on a receipt layer that can watch events without slowing them down.
See how Receipt Relay signs evidence tiers and how R3Pv groups them into one signed proof vector, carrying the weakest boundary forward honestly.