XODE Sentinel — Making Automated Decisions Verifiable
Gene Son ·
Automated decisions are easy to make. Proving exactly what happened afterward is harder. XODE Sentinel creates a cryptographic receipt for every decision, anchors the proof to the chain, and gives users a way to verify the record without simply trusting the operator.
The question Sentinel answers
When an automated system rejects a reward, blocks an account, or applies a policy, users usually have only one option: trust the system's explanation.
Sentinel changes that relationship. Instead of asking users to trust an internal log, it gives them a record that can be independently checked.
OLD MODEL
Trust the operator
“Our system says you exceeded the limit.” The user has no independent way to determine whether the internal record was changed after the decision.
SENTINEL MODEL
Verify the evidence
“Here is your receipt. Verify it yourself.” The user can check the record against a Merkle root anchored to the XODE chain.
Why this matters for Omni
On October 1, 2026, Omni rejected 166 advertising rewards because of cooldowns and 37 because of daily limits.
The users had watched the ads, Google had confirmed the views, and revenue had been generated. The dispute was not simply about whether a decision existed. It was about whether the evidence behind that decision could be trusted.
Sentinel addresses that exact problem by making the historical record tamper-evident.
The evidence should not be controlled exclusively by the party asking you to trust it.
From decision to permanent receipt
Every automated decision starts as structured information: the wallet, outcome, reason, policy and timestamp.
That information is normalized into a deterministic representation and converted into a cryptographic fingerprint.
The fingerprints are then combined into an hourly Merkle tree. The resulting root becomes the compact proof of the records included in that period.
Decision
Wallet · outcome Reason · policy · time
“What happened?”
Proof
Merkle root XODE chain
“Can the record be verified?”
Sentinel converts an automated decision into a verifiable cryptographic receipt
STEP 01
Normalize
The original decision is converted into deterministic data so the same information always produces the same fingerprint.
STEP 02
Fingerprint
The normalized decision is hashed into a compact cryptographic fingerprint without exposing the underlying contents.
STEP 03
Aggregate
Decision fingerprints are combined into an hourly Merkle tree and reduced to a single root.
STEP 04
Anchor
The root is submitted to XODE using System.remark_with_event and becomes anchored to the public chain.
The chain holds the proof, not the private details
Sentinel does not need to publish the contents of every decision. The system records cryptographic fingerprints and anchors their Merkle root.
This creates a balance between verifiability and privacy: the proof can be checked without making every underlying decision publicly readable.
Verification happens independently
A user receives a receipt and a verification script. The script runs locally on the user's computer using standard libraries and public RPC data.
The verifier does not ask the XODE application server whether the receipt is valid.
Instead, it independently reconstructs the proof and checks the public chain.
LOCAL CHECK
Verify the record
The verifier recalculates the decision fingerprint and determines whether it belongs to the expected Merkle root.
CHAIN CHECK
Verify the anchor
The verifier checks public blockchain data to determine whether the same root was actually anchored to XODE.
Change one thing, break the proof
The security property is simple: change the underlying record and its fingerprint changes. Change one fingerprint and the Merkle root changes.
That means changing a rejection into an approval, modifying the reason, timestamp, wallet, policy or evidence causes verification to fail.
During testing, all 10 tested fields were modified individually and all 10 modifications were detected.
Immutability is useful because even a small change becomes visible.
The policy travels with the decision
A decision is not just an outcome. It also depends on the rules that were active when it happened.
Sentinel therefore records a policy hash derived from the actual configuration at that moment.
A daily limit of 60, a cooldown of 180 seconds, or a monthly cap of 200/50 contributes to the policy fingerprint. If those settings change, the resulting policy hash changes.
MANUAL VERSION
Easy to misrepresent
A manually assigned version number can be forgotten, incorrectly updated, or disconnected from the actual configuration used by the system.
POLICY HASH
Bound to the real rules
The policy hash is calculated directly from the configuration that was actually active when the decision occurred.
A receipt does not mean a decision was correct
Sentinel deliberately makes a narrower claim: it proves the integrity of the recorded decision.
It does not automatically prove that the decision was fair, correct, or appropriate.
The policy hash makes the rules auditable, but the validity of those rules remains a separate question.
Integrity
Cryptographic proof
“Was the record changed?”
Policy audit
Separate review
“Were the rules appropriate?”
Record integrity and decision correctness are different questions
Security is separated by design
The account used to submit Sentinel roots does not have reward payout authority.
Its key is dedicated to submissions. If that key were compromised, the expected impact would be limited to malicious or garbage submissions rather than unauthorized reward payouts.
This separation ensures that the ability to anchor evidence does not become the ability to control rewards.
AUTHORITY 01
Submission
The submission account can sign and submit Sentinel records.
AUTHORITY 02
Payout
Reward distribution remains controlled by a separate authority.
SECURITY
Separation of powers
Compromising one authority does not automatically grant the other authority.
What Sentinel does not do
Sentinel does not prevent hacking or prompt injection. Those protections are handled separately through hard guardrails in the in-app AI.
The independent verifier also does not perform full SCALE decoding. It locates the root bytes directly in the block so the verifier can remain lightweight and library-independent.
For stricter verification, the same block can be inspected with substrate-interface or a block explorer.
One architecture, many decisions
Sentinel currently focuses on advertising reward decisions because that is where disputes are most common.
The architecture can be extended by changing the record's kind field, allowing the same accountability layer to cover other automated decisions.
01
Advertising rewards
Record why an advertising reward was approved or rejected and preserve the evidence behind the decision.
02
Farming enforcement
Create verifiable records for automated farming and abuse-detection decisions.
03
Device verification
Preserve device verification results so their history can be independently audited.
04
AI accountability
Record the model and policy context behind AI-generated responses.
Where it stands today
The decision collector is already live in production and is recording new advertising reward decisions as they happen.
The reward logic itself has not been changed.
Normalization, Merkle tree and proof testing has passed 41/41 tests, while the independent verifier has passed 19/19 tests.
The hourly submission timer and public receipt API are pending, and the on-chain submission account is waiting to be funded.
LIVE
Decision collection
The production collector is live, real reward decisions are being recorded, and the core proof pipeline has passed its tests.
PENDING
Chain anchoring
Hourly anchoring, the public receipt API and final on-chain submission remain in the deployment path.
The test that matters most
The most serious failure would not be a simple rejected transaction. It would be a mismatch between the system that creates a receipt and the independent system that verifies it.
The collector and verifier must generate exactly the same normalization bytes. If they do not, previously issued receipts could become impossible to verify.
That is why normalization consistency is being tested directly alongside tamper detection.
Collector
Normalized bytes
Creates the receipt
Verifier
Identical bytes
Reconstructs the receipt
The collector and verifier must agree exactly
The bigger idea
Sentinel is not about making automated systems appear trustworthy. It is about making their important claims independently checkable.
Instead of asking users to believe what the system says happened, XODE can give them a cryptographic record and a way to verify it themselves.
That is the role of Sentinel: an accountability layer between automated decisions and the people who need to trust them.
Don't just tell users what happened. Give them a way to prove it.