Proof of Outcome

Abstract

Artificial-intelligence agents now answer guests, change calendars and send door codes. Most of them act on knowledge nobody has verified: a rule typed once, a memory of an old conversation, a guess. In hospitality a wrong answer costs money, a review or a night's sleep.

Aonios is a platform of agents for hospitality businesses, meaning short-term rental and hotel businesses. Its agents act on a shared, verified body of operating knowledge called the Aonios Library. The library holds templates: the structure of how a job is done. It never holds a business's own data. Names, addresses, times and prices stay in that business's Workspace.

This paper describes proof of outcome, also called verification by outcome: the process by which the library is built, verified and kept true. An entry is verified by outcome when enough weighted evidence, from enough independent channels, shows that it behaves as claimed. The first implementation is fully human. Twenty identity-verified people, from at least three businesses with different owners, each approve the same prepared template filled in with their own business's information. The stages that follow add machine evidence, channel by channel, and a reputation rule that weighs each contributor. Every verification is recorded in a signed, append-only log, and every edition of the library is registered by its fingerprint.

The paper states its limits. No computation can know whether a guest was happy. Outcome signals are an attested feed, and the process is only as good as that feed. The paper sets the design beside public prior art and lists what remains open.

1. The problem

Agents acting on unverified knowledge

An agent is only as good as what it believes to be true. Most agents today build their beliefs as they go. They are told something once and store it. They read an old conversation and infer a rule. When they find no rule, they write one.

Three failures follow. The agent invents: it states a price, a policy or a promise that nobody set. The agent goes stale: it keeps applying a rule after the business changed its mind. The agent misapplies: it carries one property's habit to another, where it is wrong. Each failure looks the same from outside. The answer is fluent, confident and false.

A fourth failure sits behind the three. When the answer turns out wrong, nobody can say which knowledge the agent was running on, who approved it, or on what evidence. Without that record the same mistake can return.

Shared knowledge without shared data

Hospitality businesses solve the same problems. A guest wants to leave late. A key goes missing. Someone is locked out at night. The shape of a good answer is the same in every business. Only the values differ: the time, the fee, the address, the person to call.

A shared library would let every business start from the best-known path. The obstacle is data. No business wants its prices, door codes or guests' details in a library that other businesses use. Deleting names from a business's own text does not solve it. A redacted sentence still carries the shape of the business that wrote it.

So there are two questions. How does operating knowledge earn trust? And how can it be shared without sharing data? Aonios answers the second with the template: structure is shared, values stay private. It answers the first with proof of outcome: trust is earned by evidence, and the evidence is recorded.

2. The Aonios model

The layers

Aonios has three layers. The names used below are those of the founder's own company's instance. A client's instance carries its own names. The roles are the product.

The agents. There are three roles.

• The guest support agent (Alexandros in the running example) handles guest communications, cleaning, maintenance, incident triage and task assignment. It is the bridge to the on-site team.
• The back office agent (Marika) handles listings, the booking channels, the calendar, pricing and property onboarding.
• The voice agent (Katina) handles every phone call. It is released at the end of October. As standard it phones only about urgent matters, emergencies first, and the owner can change that in the Workspace.

Each agent raises copilot cards: proposals to build, change or extend the library.

The Workspace. This is the business's own layer. It holds the owner's settings and the business's data, the conflicts section and the emergency steps. It also holds three things with their own jobs.

• The business playbook holds the business's own rules and values, applied to the verified templates it uses. It lives only in the Workspace.
• The Manager is a control centre with an assistant. The owner sets staff roles, delegations, access requests, permissions and the hierarchy of access. The platform enforces them. The Manager holds check-in form data, such as identity documents and personal details, and door codes. The assistant explains, notifies, prompts for missing information and presents suggested values. It never grants access itself.
• The Keymaster is an add-on to the Manager. It holds credit cards, banking information, payment information and passwords in an encrypted vault with its own permissions. Secrets never enter the library or a copilot card.

The library layer. The librarian (Mildred) receives every copilot card. The Aonios Library holds the universal templates, published as Books, in editions. Each edition is registered by its fingerprint in an internal signed, append-only log. Aonios authors write and verify templates, review reported conflicts and monitor the agents. To monitor the agents, authors have full access, because agents can make mistakes.

How an agent decides

Agent actions are governed by the Workspace. The order is always the same.

1. The owner's Workspace settings come first, and the owner always wins. If the owner overrides recommended fixed data in a template, the change goes ahead as an accepted conflict.
2. Otherwise the agent follows the Aonios Library template for that category, filled with the business's Workspace values.
3. If necessary information is missing, the Manager prompts the business to fill it in before the agent continues. It also asks whether the business can take a couple of minutes on related questions.
4. If the agent is not sure, it raises a copilot card first, before acting.

There is one automatic override: an emergency. A lockout, fire, flood, crime or power loss overrides the door-code release setting once the guest confirms it. For a fire, the local emergency number goes out at once, before confirmation.

Example: the setting wins. A library template for late check-out requests says: check the calendar for an arrival the same day; if there is none, offer the {late check-out time} and {late check-out fee} set in the Workspace; confirm in writing; notify the cleaning team. The owner of a fictional villa has set "late check-out offered: no". A guest asks to leave later for an evening flight. The calendar is clear, but the owner's setting wins. The agent declines politely.

3. The library: templates, customisations, variations, exceptions

Everything an agent knows is sorted into four kinds. The sorting decides where the knowledge lives and who verifies it.

The test

One test sorts any change. The librarian applies it and labels the change. The verifiers confirm the label when they approve.

A template, as stored

The template below is "Guest arrival instructions". It holds steps, options and field names. It holds no business’s own values.

The message, as stored in the template:

Hello {guest first name}, we look forward to welcoming you to {property name} on {check-in date}. Check-in is from {check-in time}. Address: {property address}. {directions note}. Parking: {parking details}. Getting in: {entry instructions}. {door code line}. If you need anything on arrival, please contact {arrival contact name} on {arrival contact phone}. Could you let us know roughly what time you expect to arrive?

How changes to this template sort, using fictional businesses:

• A villa picks "private space" at step 4 and fills in its own parking details. That is a customisation.
• An owner picks "only once the check-in form is complete" at step 6. That is a customisation. It is an offered option, so there is no conflict.
• An owner adds "only after the security deposit is paid" at step 6. That is a variation. The librarian builds a card with no business data: "release the code once a required payment is confirmed". Once verified, it becomes a fourth option at step 6 for every business.
• An owner removes step 8. That is an exception. The warning reads: "your on-site team will not know when guests are arriving".
• An owner wants the door code typed into the message text instead of released from the Manager. That is an exception. The warning reads: "the code will be stored in the message history and visible to anyone with access to the conversation".

The librarian builds templates. She does not redact.

When a card arrives, the librarian does not delete names from it. She builds a best-practice template from the card's category and the action it describes. The template never carries business data in the first place.

Example. A card from a fictional villa company says: "for the blue house next to the harbour, leave the key with the woman at the bakery." The librarian files it under key handover and builds a template for the action: "when keys are handed over at a location other than the property: confirm the {handover point} and {handover contact} set in the Workspace, send the guest directions and the contact's availability, and confirm collection." The house, the harbour and the bakery stay in that business's Workspace.

The librarian also pushes the library's categories to the Workspace and suggests a category for each card. The owner or an authorised user can change it. Changing it re-checks who may approve the card, because approval is authorised category by category. She checks for conflicts and duplicates, labels variations and exceptions, onboards new businesses and assists the authors. The librarian does not verify.

Because a template carries none of a business's data, the business is not asked before its card becomes a shared template.

4. Proof of outcome: the loop from card to edition

The idea

An entry is verified by outcome when enough weighted evidence, from enough independent channels, shows that it behaves as claimed.

Two kinds of evidence carry most of the weight. Convergence is the same rule verified at independent businesses. Outcome evidence is use without a correction, a complaint, a refund or an override. They are two channels of one evidence score. A universal proposal that already has convergence needs less outcome evidence. Strong outcome evidence makes a heavier convergence vote.

The claim is modest on purpose. Proof of outcome does not say an entry is true in the abstract. It says the entry has been tried, by enough independent parties, with results that can be read back.

The loop

One flow serves both: each business playbook and the universal Aonios Library. Only the verifiers and the thresholds differ.

1. A copilot card is raised by the agent that met the knowledge. The card carries the old and new text, the source, the effects and the reason.
2. The librarian builds the template, checks for conflicts and duplicates, and routes the card to the business playbook or to the universal queue.
3. The evidence window opens. The evidence channels run in parallel, in nightly sweeps.
4. Reputation weighs each piece of evidence by its contributor.
5. The score is tested against the threshold.
6. The challenge window. Anyone authorised may challenge with a reason, and the entry goes back to a person. The length of the window is not fixed.
7. The edition registry. The entry's fingerprint, the evidence summary, the score and the signatures are chained into the signed log. The Book's edition is recomputed and registered by its fingerprint. Businesses activate by edition fingerprint.
8. Monitoring after activation. On a regression the business returns to the previous registered edition and a new card is raised.

Who decides

The librarian gathers and records evidence. She does not verify. An entry's status changes only when a verification rule is met or an authorised person decides. A rule can decide without an author.

In the business playbook, the owner or a user authorised in the Manager verifies. In the universal library, an Aonios author verifies, or the twenty-approver rule does. There are no tiers. No entry gets a different level of review because of what it is about. Every entry follows the same path.

The loop is the process. What changes from stage to stage is who supplies the evidence. In the first implementation, described next, every piece of evidence is a person's approval. The stages that follow add machine evidence to the same steps.

5. The first implementation: the twenty-approver rule and its reverse

Stage one is fully human. It is how a universal template is verified when an Aonios author does not verify it directly.

The twenty-approver rule. A template or variation is verified into the universal Aonios Library when:

1. twenty different people, each identity-verified as a real person,
2. from at least three businesses with different owners,
3. each authorised for that category by their own business's Manager,
4. have each approved, unchanged, the prepared template filled in with their own business's information.

The prepared template is the basis of a copilot card raised where a library entry was missing. Each approver sees it with their own business's values in place and approves it as it stands.

If someone changes the prepared template before approving, that approval does not count towards the twenty. The count does not reset. The change is offered as a variation.

An Aonios author can verify a template directly, and can undo any verification at any time. When an author undoes one, every business using the template receives a copilot card explaining what changed.

Why it counts as proof of outcome

Read against the loop, the rule is the simplest possible evidence score. Each approval is one piece of evidence: a named person, authorised for that kind of work, confirming that the template filled with real values is right for their business. Every approver counts once. The threshold is twenty. The requirement for three businesses with different owners is convergence in its first applied form.

Each condition closes a gap. Identity verification stops invented approvers. Different owners stop one owner approving their own idea twenty times. Category authorisation means the approver knows the work. "Unchanged" means all twenty approved the same thing.

Example. The template "Guest arrival instructions" is prepared for three fictional businesses: a hotel and two villa companies. Each sees it filled in with its own check-in time, address and arrival contact. Twelve front-desk staff at the hotel, all authorised for the arrival category, approve it unchanged. So do five people at the first villa company and three at the second. That is twenty verified people from three businesses with different owners. The template is verified into the Aonios Library. Twenty approvals from the hotel alone would not count. Neither would three businesses with the same owner.

The rule in reverse

The same rule works for conflicts. When twenty verified people from three businesses accept the same exception, the step concerned becomes optional in the template. Switching it on or off becomes a customisation. If twenty such people each remove "ask for the expected arrival time", that step becomes optional for every business. An author can undo this.

This is how the library learns that a recommended step was less universal than it looked. The evidence is of the same kind: independent people, in independent businesses, making the same choice.

The incentive

Each business has a usage allowance. Everything connected to a copilot card that is verified into the library stays out of that allowance: the thread that raised the card, the card itself, every round in the Workspace, the follow-through with no time limit, and related cards. The work that improves the library costs the business nothing.

6. The evidence channels: what machine learning adds, stage by stage

Stage one asks people for every piece of evidence. Each stage that follows adds a channel in which machine learning does what a person did. The channels are set out below in the order they touch an entry, from before its first use to after its activation.

What machine learning never does

It never changes what an entry says. It only decides whether there is enough evidence to move the entry's status. Every automatic decision is recorded with its evidence, so a person can read why.

The sweeps

The channels run in nightly sweeps. The librarian runs them. She gathers the evidence and records it. The decision is not hers. An entry's status moves when a rule's threshold is met or an author decides, exactly as in stage one.

Aonios is considering building each sweep as a reproducible job: fixed inputs, and a fingerprint of the result written to the signed log, so that anyone with access can run the job again and get the same answer.

7. Reputation

Reputation is theory today. It is set out here because the loop needs a way to weigh contributors once machine channels supply evidence. It does not change the twenty-approver rule, in which every identity-verified person counts once.

Every contributor has one score: each business, each delegated role, each author and each agent instance. A new contributor starts neutral, neither trusted nor suspected. After each resolved contribution the score moves: up if the contribution was upheld, down if it was reversed. It falls faster than it rises, because trust is lost more quickly than it is earned. Without new contributions it drifts back towards neutral. Reputation is maintained, not banked.

The score scales the weight of that contributor's evidence, within fixed bounds. A strong record makes evidence count for more. A poor record makes it count for less. Neither can make it count for everything or for nothing.

Four limits keep the score honest.

• Businesses under one ownership count once.
• A contributor never counts towards its own proposal.
• A challenge moves both parties' scores, so challenging is never free.
• Scores are private to each contributor.

For convergence, the theory asks for a quorum of independent businesses whose combined weight clears a threshold. The values are open.

8. The edition registry and proof

Verification is only useful if it can be shown afterwards. The edition registry is where that happens. It does three jobs.

1. It fixes what was verified, and on what evidence. The entry's fingerprint, the evidence summary, the score and the signatures are chained to the record before. Later, nobody can argue about what the evidence was when the decision was made.
2. It makes activation exact. Each Book edition has a fingerprint computed over its verified entries. A business activates an edition by that fingerprint. Its agents load exactly that edition, and the log says so.
3. It makes rollback a registry operation. Nothing is edited in place. Returning to a previous edition is itself a signed record.

A fingerprint, known technically as a cryptographic hash, is a short code computed from a piece of content. Change one character of the content and the code changes. Two parties holding the same fingerprint hold the same content.

The log records more than verifications. Every door code release, accepted conflict, verification and undo is recorded in it.

Proof is the internal signed, append-only log only. There is no public blockchain anchoring and no cryptocurrency token for now.

9. Governance

Accepted conflicts

When a business makes an exception, the owner wins. Four things happen.

1. The Workspace shows a warning of what could happen.
2. The owner, or a user the Manager authorises, clicks to accept the consequences.
3. The exception is entered in the Workspace's conflicts section.
4. An Aonios author is told, and checks whether the verified rule still stands.

New template versions

A new template version reaches a business as a copilot card: accept, modify, or keep the current version. The card shows exactly what changes and keeps the business's customisations. Approval is bound to that exact version. Before the card is offered, the platform checks the permissions, connected systems and agent abilities the version needs. The agent keeps running on the last accepted version. A business can roll back to its previous accepted version.

Suggested values and missing information

Suggested values come only from verified library defaults. The agent never invents one. The business accepts, modifies or rejects each. A rejection becomes one tracked question, with reminders, in the Workspace. The action that needs the value waits. Unrelated work continues.

Emergencies

Lockout, fire, flood, crime and power loss override the door-code release setting once the guest confirms the emergency. The automatic help then starts.

On a lockout the Manager releases the door code when the message comes through any channel that staff or an agent created for that guest before check-in, from check-in day to check-out day only. From any other channel no code is released.

If an alerted person does not answer, the voice agent moves to the next person in the Workspace's alert order. The owner can adjust the emergency protocol. Doing so creates a conflict, logged like any other.

The Manager and the Keymaster

In the Manager the owner hands categories to roles. A delegated role verifies for its own business only. Its one part in the universal library is as an approver under the twenty-approver rule.

Sensitive data is not protected by a review step. It is protected by never being in the library. Templates hold field names. The Workspace, the Manager and the Keymaster hold the values.

10. Limits and prior art

The honest limit

A computation can prove who computed what, on which inputs, when, and what it cost them to lie. It cannot know whether a guest was happy or whether a refund was issued. Those facts enter the system as an attested feed: signals signed by Aonios's own systems and by the property management system. This is known as the oracle problem. No design removes it. A design can only state where its facts come from.

In hospitality the signals are unusually clean. A correction, a complaint, a refund and an override are each a recorded event. That is why proof of outcome works here first.

Prior art

On our reading of the public sources, nobody has solved real-world outcome verification in general. Each project reduces the problem to one of three shapes: deterministic re-execution, an economic bond-and-challenge game with a jury, or an attested feed. Numbers in square brackets refer to the sources at the end.

The Polymarket case (published reports, March 2025). A Polymarket market asked whether the United States and Ukraine would reach a minerals agreement. More than seven million United States dollars had been traded on it. On 25 March 2025 it resolved "yes", although no agreement had been confirmed. Reports attributed the result to one large holder who cast about five million tokens through three accounts, about a quarter of the vote. Others disputed that account and said the usual large voters decided it. Polymarket said the market had resolved against its users' expectations and its own clarification, and that it would not issue refunds. [3] [4] [5] On either account, the outcome was decided by weight of tokens and not by the facts.

Reading the table. Nothing in it verifies that a procedure served a guest well. What has been solved is making the computation of a verdict reproducible and expensive to fake, and making the jury for a dispute economic. Both are useful. Neither replaces the outcome signals, the librarian's template building or the people who approve. The lesson Aonios takes from the Polymarket case is that approvers must not be purchasable. The twenty-approver rule counts identity-verified people, one each, from businesses with different owners. It does not count tokens.

Projects that already reward by outcome

Some projects go further than verifying a computation. They score work against what happened afterwards. These are the closest relatives of proof of outcome.

What these share with Aonios is the principle: reward and trust follow a result that can be read back. What they share with each other is an outcome that is already a figure, or already on a chain. On our reading, the part they leave open is the part Aonios addresses: putting an operating rule into a common format, and turning its use into signals clean enough to count.

Where a blockchain could fit

The following are concepts and not plans. The settled position is the internal signed log only, with no public anchoring and no cryptocurrency token for now.

• Proof of verification work. The sweeps as useful work, computed redundantly by several nodes that must agree.
• Bond and challenge. An assertion that an entry is verified, backed by a bond and open to challenge.
• Zero-knowledge proofs of the sweep. Proof that a check ran on given inputs, without revealing them.
• A compute market. Participants contribute processing power for the sweeps.
• Staking on outcomes. Contributors stake on a rule holding without reversal.
• Reputation as attestations. Scores recorded as signed statements that can move between platforms.
• The edition registry on a chain. Each edition's fingerprint anchored where any outsider can check it.

Each would strengthen integrity, independence or credit. None would manufacture truth. The outcome signals would still be an attested feed.

11. Beyond hospitality

The loop does not depend on what the knowledge is about. It runs anywhere a body of rules is used repeatedly and the result can be observed. Four things must exist.

• A common entry format, so that the same rule can be recognised across organisations.
• An attested outcome feed for each domain, because what counts as "used without correction" differs from one field to the next.
• Portable reputation.
• An edition registry, so that anyone can show which knowledge was in force, and when.

Aonios's own design has a version of each: the template, the outcome signals, the reputation rule and the edition registry. Aonios's stated vision is a standard that any business, in any country, in any industry, can adopt. The library is where that standard is written down.

The further a domain is from hospitality, the harder its outcome signal is to attest. A general verify-by-outcome protocol would be a second company, not a feature.

12. Open questions

Must any kind of entry always be decided by a person? This is not decided. The position this paper argues is that proof of outcome, with the rules around it, removes the need for a standing human gate on any class of entry. The reasons are already in the design. Evidence must come from independent channels. Machine learning never changes what an entry says. Every automatic decision is recorded with its evidence. The challenge window returns any entry to a person. An author can undo any verification. The owner always wins in their own Workspace, and an exception is logged as an accepted conflict. The Manager and the Keymaster keep sensitive data out of the library altogether. Monitoring rolls back a regression.

Further safeguards could apply without creating tiers, because each would apply to every entry or follow from the evidence itself. A shadow run could be compulsory before any automatic verification takes effect. A newly verified edition could be activated in a few businesses first and in the rest afterwards. An author could be notified of every automatic verification without being made a gate. Reversal prediction would ask for more evidence wherever entries of that kind have been reversed before.

The reputation values. The shape of the rule is set out in section 7. Its values are open.

The thresholds. How much evidence, from which channels, moves an entry's status in the stages after stage one.

The length of the challenge window. The window is part of the loop. Its length is not fixed.

Invited reviewers. Whether selected people at client businesses may one day be invited to review universal proposals directly, beside Aonios authors. This is a possible later stage and is not decided.

Reproducible sweeps. Whether every sweep is built as a reproducible job recorded by fingerprint in the signed log. This is under consideration.

Public anchoring. Whether, and when, any part of the registry is anchored outside Aonios. Not for now.

Other domains. How an outcome feed is attested in fields where the signals are less clean than in hospitality.

13. Glossary

Accepted conflict

An exception the owner has chosen to keep, after a warning and a click to accept the consequences. It is logged in the Workspace's conflicts section and reported to an Aonios author.

Aonios author

A person at Aonios who writes and verifies templates, reviews reported conflicts and monitors the agents, with full access for that purpose.

Aonios Library

The universal, verified body of templates. It holds structure and never a business's data.

Attested feed

Facts about the world that enter a system signed by a known source, such as a property management system.

Book

A published collection of verified entries in the Aonios Library. Books are issued in editions.

Booking channel

A website or service through which guests book, such as an online travel agency.

Business customisation

A choice or value a business sets within what a template offers. It lives in the Workspace only.

Challenge window

The period after the evidence passes in which anyone authorised may challenge an entry with a reason, sending it back to a person.

Convergence

The same rule verified at independent businesses.

Copilot card

A proposal, raised by an agent, to build, change or extend the library. It carries the old and new text, the source, the effects and the reason.

Edition

One fixed state of a Book, identified by its fingerprint.

Edition registry

The part of the signed log that records each edition, the evidence behind it, each activation and each rollback.

Evidence score

The weighted sum of evidence for an entry across all channels.

Exception

A business change that removes a template step or contradicts recommended fixed data.

Fingerprint

A short code computed from a piece of content, known technically as a cryptographic hash. Any change to the content changes the code.

Keymaster

The add-on to the Manager that holds credit cards, banking information, payment information and passwords in an encrypted vault.

Librarian

The role that receives every copilot card, builds templates with no business data, checks conflicts and duplicates, labels changes and runs the sweeps. The librarian does not verify. Mildred in the running example.

Manager

The control centre in the Workspace where the owner sets roles, delegations, permissions and the hierarchy of access. It holds check-in form data and door codes.

Business playbook

One document for each business, living only in its Workspace: its own rules and values, applied to the verified templates it uses.

Oracle problem

The problem that no computation can observe the outside world by itself. It must trust a source for facts about it.

Outcome evidence

Use of an entry without a correction, a complaint, a refund or an override.

Proof of outcome

Also called verification by outcome. Enough weighted evidence, from enough independent channels, that an entry behaves as claimed.

Property management system

The software a hospitality business uses to run reservations, calendars and guest records.

Recommended fixed data

The part of a template step that Aonios recommends a business leaves as it is, such as releasing a door code from the Manager.

Reputation

A score for each contributor that scales the weight of its evidence. Theory today.

Signed log

Aonios's internal, append-only record. Each record is signed and chained to the one before.

Sweep

A nightly run of the evidence channels.

Twenty-approver rule

The first implementation of proof of outcome: twenty identity-verified people, from at least three businesses with different owners, each authorised for the category, each approving the same prepared template unchanged.

Variation

A new step or option that a template does not offer and that contradicts nothing in it.

Verified template

The structure of a job: category, action, steps, options, field names and recommended fixed data.

Workspace

The business's own layer: its data, its business playbook, the Manager and the Keymaster.

Sources

All sources were read on 11 October 2026.

1. UMA documentation, "How does UMA's oracle work?" docs.uma.xyz/protocol-overview/how-does-umas-oracle-work
2. UMA documentation, frequently asked questions. docs.uma.xyz/faqs
3. Cointelegraph, "Polymarket faces scrutiny over $7M Ukraine mineral deal bet", 26 March 2025. cointelegraph.com
4. The Defiant, "Polymarket's $7M Ukraine Mineral Deal Debacle Traced to Oracle Whale", March 2025. thedefiant.io
5. CryptoSlate, "Polymarket faces backlash over resolving disputed $7 million Trump-Ukraine market", March 2025. cryptoslate.com
6. Kluwer Arbitration Blog, "Arbitration Tech Toolbox: The Rawlsian 'Veil of Ignorance' and Blockchain Arbitration". legalblogs.wolterskluwer.com
7. Independent analysis of the Reality.eth oracle. hackmd.io/@izkp/S15MGqNn9
8. Kleros, cross-chain arbitration proxy for Reality.eth. github.com/kleros/cross-chain-realitio-proxy
9. Chainlink documentation, "Decentralized Data Model". docs.chain.link
10. Bittensor documentation, "The Weight Copying Problem". docs.learnbittensor.org
11. Bittensor, "Weight Copying in Bittensor". blog.bittensor.com
12. Arun and others, "Verde: Verification via Refereed Delegation for Machine Learning Programs", 2025. arxiv.org/abs/2502.19405
13. Gensyn, "Verde: a verification system for machine learning over untrusted nodes". gensyn.ai/articles/verde
14. Teutsch and Reitwießner, "A scalable verification solution for blockchains", 2017. arxiv.org/abs/1908.04756
15. Variant, "Investing in Modulus: Zero-Knowledge Machine Learning for Decentralized Protocols". variant.fund
16. An independent overview of Modulus Labs, which summarises the project's paper on the cost of proving. darshang.substack.com
17. Decrypt, "Bringing Reputation On-Chain: Can Ethos Network Boost Trust and Credibility in Crypto?" decrypt.co
18. Allora documentation, "Technical Architecture". docs.allora.network
19. Numerai documentation, "Staking". docs.numer.ai
20. Ethereum Improvement Proposals, standard 8004, "Trustless Agents", draft, created 13 August 2025. eips.ethereum.org
21. Goenka, Pathak and Asthana, "TessPay: Verify-then-Pay Infrastructure for Trusted Agentic Commerce", January 2026. arxiv.org/abs/2602.00213
22. Protocol Labs, "Hypercerts: a new primitive for public goods funding". pl.xyz/blog/hypercert-new-primitive