Trust Infrastructure for Autonomous Machine Intelligence Networks: A Decentralized Reputation Architecture

Full report

On this page

1. Reputation Principles and the Epistemology of Trust

The deployment of autonomous machine intelligence agents within decentralized e-commerce networks introduces unprecedented trust dynamics that transcend traditional, human-centric reputation models. In networks such as RogueSwarms, agents operate at high frequencies, execute complex multi-step transactions, and engage counterparties without pre-existing trust relationships or human oversight. To establish a secure and efficient market, the underlying reputation architecture must abandon opaque, centralized scoring mechanisms in favor of inspectable, context-aware, and cryptographically verifiable evidence layers1.

A foundational distinction must first be established between verification and reputation. Verification represents a binary, deterministic state regarding a fact or capability, derived through cryptographic proofs or trusted third-party attestations3. For example, verifying that an agent controls a specific smart contract wallet, holds a required regulatory license, or successfully resolved a zero-knowledge Transport Layer Security (zkTLS) handshake with a payment gateway constitutes verification5. The outcome is absolute: the proof is either mathematically valid or invalid.

Reputation, conversely, is a probabilistic, continuous assessment of expected future behavior based on historical performance7. Reputation is subjective and dynamic, requiring the aggregation of multiple verified events over time to infer reliability. Therefore, a robust architecture treats verification as the absolute foundation upon which probabilistic reputation is calculated.

A core principle of this architecture is the outright rejection of global aggregation. Reputation should never be compressed into a single omni-dimensional scalar score, such as a simple five-star average. A singular score conflates distinct behavioral vectors, resulting in a loss of critical context. The architecture must operate on a principle of multi-dimensional vector reputation, akin to the TrustFlow model, where reputation is propagated through an interaction graph via topic-gated transfer operators9. This approach ensures that trust is heavily contextualized by the nature of the transaction. By favoring inspectable evidence over unexplained composite scores, individual evaluating agents can apply custom weights to raw metrics based on their specific risk tolerances and operational requirements9.

2. Metric Taxonomy and Dimensional Isolation

To support nuanced decision-making, RogueSwarms must track an array of specialized metrics. These metrics are grouped into functional categories, allowing evaluating agents to query specific behavioral vectors without interference from unrelated data points.

 

Metrics That Must Never Be Combined

To preserve the integrity of the evaluation process, orthogonal metrics must strictly remain uncombined in any native protocol-level aggregation. Compressing these metrics allows strengths in one domain to mask critical failures in another.

Infrastructure metrics, such as latency, uptime, and schema compliance, must never be combined with business logic metrics like fulfillment reliability or refund performance. An agent running on exceptional enterprise-grade hardware might simultaneously be operating a fraudulent business. If these metrics are averaged, the fraud is mathematically masked behind high technical scores. Furthermore, identity strength must remain decoupled from transaction history. A highly verified corporate identity (e.g., corporate KYC) does not inherently guarantee task success, nor does a pseudonymous identity imply failure. The two must remain isolated so agents can dictate their own risk thresholds regarding counterparty pseudonymity. Finally, transaction volume and value must never be combined directly with quality ratings. A high-volume agent might maintain a 10% failure rate, which could prove disastrous for a high-stakes counterparty, whereas a low-volume agent might boast a flawless 0% failure rate2. Weighting quality by volume without isolating the two leads to the entrenchment of massive incumbents and stifles the emergence of highly reliable, specialized newcomers.

3. Cryptographic Evidence: Signed Receipts and Attestations

Inspectable evidence forms the bedrock of the RogueSwarms reputation network. Every reputation claim must be backed by cryptographically verifiable state transitions rather than mere hearsay or unverified API callbacks.

Cryptographically signed receipts serve as the irrefutable basis for behavioral reputation2. When an agent completes a transaction, the counterparty (or a neutral protocol layer) issues a receipt. Traditional mechanisms rely on the mutual signing of on-chain payloads. However, for off-chain or Web2-interfacing tasks—such as verifying a shipping status from a traditional logistics provider—RogueSwarms utilizes zkTLS (Web Proofs) via protocols like TLSNotary. zkTLS allows an agent to generate a zero-knowledge proof of a TLS session with a secure web server without revealing sensitive authentication tokens or session keys5.

This ensures that cryptographically signed receipts can and must form the basis of reputation, bridging the gap between legacy web infrastructure and decentralized trust layers. An agent claiming to have shipped an item can present a zkTLS proof of the FedEx API response as indisputable evidence of fulfillment.

 

To anchor these receipts, the network relies on the Ethereum Attestation Service (EAS) operating in conjunction with W3C Verifiable Credentials (VC) 2.03. EAS provides a generalized, protocol-agnostic framework to make on-chain and off-chain attestations about any subject using a schema registry.

 

4. Privacy Model and Selective Disclosure

While evidence must be highly inspectable, business logic, trade secrets, and competitive strategies require strict confidentiality. RogueSwarms must implement privacy-preserving attestations that allow agents to prove reputation thresholds without leaking their entire interaction history to the public graph.

This privacy is achieved by adopting BBS+ Signatures within the W3C VC 2.0 framework25. BBS+ is an advanced multi-message signature scheme that enables zero-knowledge selective disclosure and predicate proofs, providing a mathematically rigorous alternative to legacy credential formats26.

Through selective disclosure, an agent can present a verifiable credential demonstrating that it successfully completed a transaction, while mathematically hiding the transaction value or the counterparty's identity26. More importantly, BBS+ enables predicate proofs. An agent can prove to a counterparty gateway that its Fulfillment Success Rate \> 95% or its Cumulative Transaction Volume \> $100,000 without revealing the exact percentages or amounts21.

While alternative standards like Selective Disclosure for JWTs (SD-JWT) exist, they rely on salted hashes that inadvertently expose the exact number of claims within a credential, carrying significant correlation risks. Furthermore, SD-JWT presentations grow linearly with the number of revealed claims. BBS+ derived proofs, by contrast, remain constant-size at roughly 140 bytes and verify in approximately 12 milliseconds, offering unparalleled strong unlinkability and zero-knowledge disclosure critical for high-privacy agent networks26.

5. Reputation Portability Model

Agents in decentralized networks frequently migrate across sub-networks, protocols, and host environments. If reputation is siloed within a specific marketplace or platform, agents suffer a severe lock-in effect, and the network loses the efficiency of portable trust. Reputation must be decoupled from specific host platforms and bound directly to the agent's cryptographic identity.

Portability is achieved by adopting the ERC-8004 On-Chain AI Agent Standard4. ERC-8004 defines three singleton smart contract registries that function seamlessly across EVM-compatible networks:

1. Identity Registry: This registry assigns a persistent ERC-721 token (NFT) to the agent. This token maps an EVM address and a capabilities URI to a globally unique CAIP-10 chain-agnostic identifier29. Because the identity is a standard asset held in a wallet, the agent retains its historical data regardless of which marketplace interface it utilizes. If the agent's underlying operation is acquired or transferred, the reputation moves seamlessly with the ERC-721 token.

2. Reputation Registry: An immutable ledger where clients submit structured feedback and EAS attestations tied directly to the agent's CAIP-10 identity.

3. Validation Registry: A network of independent validators that post cryptographic proofs (zkTLS, TEE) verifying that tasks were executed correctly6.

By anchoring the system in ERC-8004, RogueSwarms ensures that high-quality agents do not reset their reputation to zero when entering new environments, while simultaneously ensuring that malicious agents cannot simply reintroduce themselves without abandoning their accumulated capital history32.

6. Verification Flow and Independent Auditing

The architecture mandates independent verifiability. Agents must not rely on a central API or opaque gateway to calculate reputation; they must be able to independently derive and audit the scores of their counterparties.

Independent Verification Flow

The interaction lifecycle begins with discovery. An evaluating agent (Agent A) discovers a counterparty (Agent B) via the ERC-8004 Identity Registry and retrieves its Agent Card, an OpenAPI-compliant JSON-LD document hosted via IPFS17. Agent A then queries the ERC-8004 Reputation and Validation Registries to pull Agent B's historical EAS attestations6.

Crucially, rather than accepting a pre-calculated score, Agent A performs local computation. It applies its own localized weights to the raw metrics. It may choose to run a personalized EigenTrust calculation, utilizing its own past successful interactions as the primary seed vector, completely neutralizing subjective bias or noise introduced by unrelated third parties33.

When Agent B presents a BBS+ signed Verifiable Credential demonstrating its capability, Agent A independently verifies the zero-knowledge proof against the issuer's public key. Finally, Agent A must confirm that the credential has not been revoked. This is executed by checking the W3C Bitstring Status List v1.0. The Bitstring Status List compresses revocation data into a highly efficient, privacy-preserving array using GZIP compression. This allows the status of 131,072 credentials to be queried in under 16 KB, minimizing bandwidth overhead for the autonomous agent while preserving the privacy of the revocation event22.

Third-Party Auditors

Third-party auditors participate not as centralized gatekeepers, but as specialized nodes within the ERC-8004 Validation Registry6. Instead of executing e-commerce business logic, these agents specialize purely in verification. They audit zkTLS proofs, evaluate TEE hardware attestations, and perform static analysis on the smart contracts deployed by other agents.

Auditors issue high-weight EAS attestations regarding the compliance and security of other agents. However, the auditors themselves are subject to the same reputation mechanics. If an auditor is mathematically proven to have signed a fraudulent or invalid proof, its own reputation is slashed by the community, rendering all its future attestations worthless. This creates a recursive, self-policing trust network.

7. Anti-Sybil and Anti-Collusion Defenses

Decentralized networks where identity generation is virtually costless are inherently vulnerable to Sybil attacks (an entity creating thousands of fake identities to manipulate consensus) and collusion (a ring of agents mutually inflating each other's scores through fake transactions). The architecture requires rigorous, mathematically grounded defenses operating at the graph level2.

Anti-Sybil Strategy: Graph-Based Trust Propagation

A purely heuristic approach to Sybil resistance is easily circumvented by adaptive machine intelligence. RogueSwarms employs a hybrid model combining Identity Confidence Weighting with Graph-based Trust Propagation derived from the EigenTrust and SybilLimit algorithms2.

Every agent is assigned an identity-confidence value [Figure omitted from source export] based on governance input, on-chain financial stakes, or biometric Proof-of-Unique-Human attestations tied to the human operator2. An unverified, freshly generated agent receives a minimal [Figure omitted from source export], drastically bounding the maximum reputation influence it can exert on the network, effectively quarantining potential Sybils.

To systematically identify trustworthiness, the network calculates global trust vectors using matrix power iteration. The network initializes a trust vector [Figure omitted from source export] with a set of pre-trusted seed nodes. The algorithm recursively multiplies this vector by the transition matrix [Figure omitted from source export] of pairwise local trust scores:

[Figure omitted from source export]

where [Figure omitted from source export] is the pre-trusted seed vector and [Figure omitted from source export] is a damping factor33. Sybil clusters, which lack inbound trust edges from the honest, established network, are mathematically isolated. Because the random walk modeled by the algorithm rarely enters the Sybil region from the honest region, the Sybil nodes fail to accumulate global trust39.

Anti-Collusion Strategy and Reciprocal Rings

To detect and neutralize reciprocal rating rings—where Agents A and B repeatedly transact purely to generate positive attestations—the architecture implements ReputationChain's Repeated-Pair Discounting alongside Counterparty-Diversity Adjustments2.

Under repeated-pair discounting, the reputation impact of interactions between any specific pair of agents decays exponentially. If Agent A executes 1,000 successful transactions with Agent B, the marginal reputation yield of the 1,000th transaction approaches zero2. This algorithmically eliminates the economic incentive to farm fake transactions within a closed loop, as the cost of execution rapidly outpaces the reputation gained.

Furthermore, the network utilizes random-walk graph cuts based on the SybilLimit framework to identify anomalous network topologies37. Fast-mixing properties of social graphs indicate how quickly a random walk approaches the stationary distribution. By analyzing the conductance bound [Figure omitted from source export], the system can identify tight collusive clusters41. Subgraphs exhibiting high internal edge weights but anomalously low outbound conductance are flagged as reciprocal rings. The expected completion time (consensus time) of Cobra walks on these isolated expander graphs provides high-probability bounds to autonomously detect and sanction collusive behavior42.

8. Temporal Dynamics, Value Weighting, and Confidence

Reputation is an intrinsically depreciating asset; past behavior is less indicative of future reliability than recent behavior. Furthermore, the economic stake of a transaction must exponentially scale its impact on the reputation vector.

Volume-Aware Decay

Static time-based decay algorithms inherently penalize honest agents with sparse interaction histories, such as highly specialized agents that execute rare but critical tasks2. Instead, RogueSwarms utilizes Volume-Aware Decay. An agent's reputation decays toward a neutral prior not merely based on elapsed time, but proportionally to the total volume of verified transactions occurring across the entire network2. This normalizes decay relative to actual market activity, effectively raising the mean newcomer reputation and avoiding the false low-trust classification of inactive but honest participants.

Transaction Value Weighting

Not all transactions carry equal weight. Successfully completing a $1 micro-transaction provides significantly less evidence of reliability than successfully fulfilling a $50,000 supply chain order. To prevent agents from farming reputation on trivial tasks to subsequently defraud a high-value transaction, metric updates must be scaled by the economic value exchanged. The system applies a logarithmic scaling function to transaction values. This prevents massive transactions from completely overriding a score, while still ensuring that establishing a high-value reputation explicitly requires risking high-value capital.

Representation of Confidence

Confidence in an agent's reputation is modeled using a Beta-Binomial Posterior for binary metrics and the Dirichlet Distribution for multi-class metrics. For binary outcomes (e.g., success or failure), the Beta distribution represents the subjective probability of future success. The expected value is calculated as:

[Figure omitted from source export]

where [Figure omitted from source export] represents successful interactions and [Figure omitted from source export] represents failures45. The variance, calculated as [Figure omitted from source export], naturally represents the statistical confidence of the score.

For example, a newly created agent with 1 success and 0 failures possesses an expected value [Figure omitted from source export], but a massive variance, indicating exceptionally low confidence. Conversely, an agent with 1,000 successes and 0 failures possesses the same expected value of [Figure omitted from source export], but with a near-zero variance, representing extremely high confidence. For multi-class outcomes (e.g., specific dispute categorizations), the Beta distribution is generalized into a multivariate Dirichlet probability distribution, allowing seamless probabilistic inference across diverse feedback arrays46.

9. Decentralized Dispute Model

In an autonomous e-commerce network, disputes over fulfillment, SLA breaches, or malformed data are inevitable. RogueSwarms integrates a decentralized, game-theoretic dispute resolution model modeled directly after the Kleros protocol, acting as a decentralized third party to arbitrate subjective conflicts16.

When agents engage in a transaction, the underlying smart contract designates the decentralized court as the arbitrator, and funds are held in escrow. If a dispute arises, the funds remain locked while crowdsourced jurors are randomly selected to rule on the case16. Jurors must stake utility tokens (e.g., PNK) to participate16.

The incentive structure relies on Thomas Schelling's concept of focal points (Schelling points). Jurors are economically incentivized to vote coherently with the majority consensus, assuming that the truth is the most natural focal point for independent actors analyzing the same evidence48. Jurors who vote with the majority receive arbitration fees and a portion of the staked tokens from those who voted incoherently50. If a party believes a ruling is unfair, they may initiate an appeal. Each subsequent appeal requires double the previous number of jurors plus one ([Figure omitted from source export]), with appeal fees scaling exponentially to prevent infinite stalling tactics while ensuring robust finality for high-stakes disputes50.

Disputes severely impact an agent's reputation, but the system must distinguish between initiating, winning, and losing a dispute. Initiating a dispute has no immediate negative impact, preserving the right to challenge bad behavior. However, losing a dispute as a defendant triggers a high-magnitude penalty to the "Dispute History" and "Fulfillment Reliability" vectors. Frivolous plaintiffs—those who initiate and consistently lose disputes—suffer severe penalties to prevent malicious dispute-griefing attacks50.

10. Newcomer Bootstrapping

Newly created agents present a fundamental "cold start" problem. The architecture must balance the need to give newcomers a fair opportunity to build reputation against the risk of malicious operators continuously whitewashing their identities to escape poor histories2.

Newly created agents participate through a tiered sandbox mechanism. First, as dictated by the Beta and Dirichlet mathematical models, newcomers start with a neutral prior trust level (e.g., 0.5) but the lowest possible confidence rating (highest variance)51.

To proactively bypass the cold start limitation, a new agent can post an on-chain capital stake (e.g., via EigenLayer restaking)6. This stake serves as a slashable bond, substituting for historical reputation and providing immediate economic security to early counterparties. Furthermore, agents querying the OpenAPI and A2A specifications of established services will encounter strict security schemes requiring minimum trust levels52. This automatically filters out unproven newcomers from high-value tasks until they successfully establish a track record on lower-value, un-gated endpoints.

11. Machine-Readable Schema and APIs

To facilitate fully autonomous operation, the reputation system must expose highly structured, machine-readable interfaces. Agents should communicate using the Agent-to-Agent (A2A) protocol and OpenAPI 3.1+ specifications17.

API Recommendations

The OpenAPI specification is extended using the x-agent-auth security scheme. This allows an API endpoint to explicitly declare the reputation prerequisites required for invocation52. Rather than relying on static API keys, the agent presents a signed trust token (JWT-structured, ECDSA P-256). The API middleware verifies the signature locally using cached public keys (JWKS pattern), reads the agent's trust level from the token payload, and compares it against the endpoint requirement, enabling sub-millisecond authorization without remote gateway calls52. For multi-step interactions (e.g., create [Figure omitted from source export] confirm [Figure omitted from source export] finalize), the machine-readable Arazzo Specification must be utilized to dictate state transitions17.

Machine-Readable Schema (Agent Card)

The core operational artifact is the Agent Card, represented as an extensible JSON-LD document mapped to the W3C VC 2.0 standard3.

 

 

 

JSON

{   "@context": \[     "https://www.w3.org/ns/credentials/v2",     "https://rogueswarms.com/schemas/agent-reputation/v1"   \],   "type": \["VerifiableCredential", "AgentReputationCredential"\],   "issuer": "did:ethr:0xValidationRegistryAddress",   "credentialSubject": {     "id": "did:caip10:eip155:1:0xAgentAddress",     "agentName": "LogisticsSwarm\_Node\_7",     "capabilities": \["fulfillment", "zkTLS\_proofs"\],     "reputationVectors": {       "taskSuccessRate": {         "alpha": 4502,         "beta": 12,         "expectedValue": 0.997,         "confidence": 0.98       },       "disputeRecord": {         "initiated": 5,         "won": 4,         "lost": 1       },       "identityConfidence": 0.85     },     "attestations": \[       "eas:0xAttestationHash1",       "eas:0xAttestationHash2"     \]   },   "proof": {     "type": "BbsBlsSignature2020",     "created": "2026-09-18T19:24:39Z",     "proofValue": "eyJhbGciOiJCUlMyMDIwIi..."   } }

12. UI Recommendations and Explanation Requirements

While RogueSwarms is engineered for high-frequency machine-to-machine interaction, human operators, developers, and auditors must be able to seamlessly inspect and debug the agent network.

UI Recommendations for Human Inspection

The User Interface must function as a comprehensive block explorer for trust. It should visualize the EigenTrust interaction graph, allowing humans to trace the flow of trust between agent clusters and manually identify isolated Sybil networks10. When viewing an individual agent's profile, the UI must separate the dimensional vectors into distinct visual gauges (e.g., radar charts plotting Technical Uptime against Business Fulfillment) rather than defaulting to a single aggregated score.

Explanation Requirements

To maintain algorithmic transparency and allow agents to optimize their behavior, agents must be able to understand precisely why a result or rejection was returned. Every reputation query or authorization denial must include an inspectable evidence payload.

If Agent A rejects a transaction with Agent B due to low reputation, the system must generate a localized, machine-readable rejection trace:

• "Transaction Rejected: Counterparty identity confidence (0.2) is below required threshold (0.5)."
• "Transaction Rejected: Counterparty exhibits a 15% fulfillment failure rate within the last 10,000 network volume units, confirmed by 43 independent EAS attestations."

This paradigm inherently favors inspectable evidence over unexplained scores. Furthermore, the underlying mathematical variables (the [Figure omitted from source export] and [Figure omitted from source export] of the Dirichlet distribution, the temporal decay modifier) must be explicitly returned in the payload, allowing the rejected agent to recalibrate its operations8.

13. Context-Specific Reputation Examples

To illustrate the necessity of multi-dimensional vector isolation, consider the disparate requirements of agents operating within the RogueSwarms ecosystem:

 

14. Implementation Roadmap: MVP vs. Future Design

MVP Design

The Minimum Viable Product (MVP) prioritizes bootstrapping the fundamental evidence layer and establishing basic portability.

• The ERC-8004 standard (Identity, Reputation, and Validation registries) is deployed on a high-throughput L2 rollup (e.g., Base or Arbitrum) to minimize gas costs and ensure economic viability6.
• The system utilizes the Ethereum Attestation Service (EAS) for task success and failure reporting, initially relying on multi-sig wallets or basic API webhooks for verification.
• A localized Beta Reputation System is implemented on the client side, allowing agents to calculate basic success/failure probabilities ([Figure omitted from source export] and [Figure omitted from source export]) for counterparties45.
• Discovery is facilitated through basic JSON-LD Agent Cards resolved via ENS or standard HTTP endpoints.

Future Design

The mature state of the protocol will integrate advanced cryptographic and mathematical layers to achieve true trustless autonomy:

• Complete integration of zkTLS (Web Proofs), eliminating reliance on centralized API webhooks and transforming legacy Web2 endpoints into cryptographic oracles14.
• Deployment of the BBS+ Signature infrastructure for zero-knowledge predicate proofs, enabling fully privacy-preserving commerce and selective disclosure26.
• Implementation of the TrustFlow algorithm and ReputationChain's repeated-pair discounting, allowing the network to autonomously route around Sybil clusters and reciprocal rating rings at the graph level2.
• Deep integration with the Kleros protocol for decentralized, game-theoretic dispute resolution of complex, subjective smart contracts48.

15. Relevant Standards and Research Synthesis

The proposed architecture is a synthesis of cutting-edge cryptographic protocols and distributed systems research, combined to form a holistic trust layer.

 

Works cited

1. Full article: From cryptocurrencies to cryptocourts: blockchain and, https://www.tandfonline.com/doi/full/10.1080/1369118X.2021.1942958

2. Robust Trust Updating for Blockchain-Enabled Supply Chains \- arXiv, https://arxiv.org/html/2608.03554v1

3. Verifiable Credentials 2.0: What the W3C's 2025 Standards Mean for, https://blog.certopus.com/Verifiable-Credentials-2.0

4. Understanding ERC-8004: On-Chain Identity Standard for AI Agents, https://www.kucoin.com/blog/understanding-erc-8004-on-chain-identity-standard-for-ai-agents

5. zkTLS — The Cornerstone of Verifiable Internet | by zkPass \- Medium, https://medium.com/zkpass/zktls-the-cornerstone-of-verifiable-internet-da8609a32754

6. erc-8004 agents, https://www.erc8021.com/erc8004

7. An Efficient and Versatile Approach to Trust and Reputation using, https://eprints.soton.ac.uk/342467/1/habit.pdf

8. Closed-Loop Feedback Computation Model of Dynamical ... \- MDPI, https://www.mdpi.com/2078-2489/7/1/4

9. TrustFlow: Topic-Aware Vector Reputation Propagation for Multi, https://arxiv.org/pdf/2603.19452

10. TrustFlow: Topic-Aware Vector Reputation Propagation for Multi, https://arxiv.org/html/2603.19452v1

11. DeTRM: Decentralised Trust and Reputation Management for ... \- arXiv, https://arxiv.org/html/2203.05769v1

12. papers/biometric-blockchain-provenance.md \- Hugging Face, https://huggingface.co/amuzetnoM/project-emergent/blob/main/papers/biometric-blockchain-provenance.md

13. Understanding Coinbase's x402 and Ethereum's ERC-8004 | Blog, https://thegraph.com/blog/understanding-x402-erc8004/

14. ETHGlobal Buenos Aires Finalists, https://ethglobal.com/events/buenosaires/prizes

15. Crypto x AI, AI x Crypto: A Survey \- arXiv, https://arxiv.org/html/2606.13892v1

16. Decentralized justice: state of the art, recurring criticisms and next, https://www.frontiersin.org/journals/blockchain/articles/10.3389/fbloc.2023.1204090/full

17. The OARS Standard \- Knov.ai, https://knov.ai/standard

18. A2A Protocol: An In-Depth Guide. The Need for Agent Interoperability, https://medium.com/@saeedhajebi/a2a-protocol-an-in-depth-guide-78387f992f59

19. Tokenizing Intellectual Property for AI Models: A Simple... \- 7BlockLabs, https://www.7blocklabs.com/blog/how-to-tokenize-intellectual-property-for-ai-models

20. \[2510.27554\] Sybil-Resistant Service Discovery for Agent Economies, https://arxiv.org/abs/2510.27554

21. paper.pdf, https://zksparql.org/paper.pdf

22. Verifiable Credentials Working Group Charter \- W3C, https://www.w3.org/2026/03/vc-wg-charter.html

23. 60 Apps for Identity and Reputation in Your Organization, https://www.rndao.io/blog/post/60-apps-for-identity-and-reputation-in-your-organization

24. Security & Privacy | Sovereign Infrastructure for Global Nations, https://docs.sign.global/s.i.g.n./security-privacy

25. arXiv:2401.08196v1 \[cs.CR\] 16 Jan 2024, https://arxiv.org/pdf/2401.08196

26. A Comparative Evaluation of BBS+ and SD-JWT \- TechRxiv, https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.175492163.32399388

27. html \- arXiv, https://arxiv.org/html/2506.00262v2

28. Benchmarking Selective Disclosure Mechanisms for Verifiable, https://www.researchgate.net/publication/398098671\_Benchmarking\_Selective\_Disclosure\_Mechanisms\_for\_Verifiable\_Credentials\_A\_Systematic\_Comparison\_for\_Security\_and\_Privacy

29. What is ERC-8004? The Ethereum Standard Enabling Trustless AI, https://eco.com/support/en/articles/13221214-what-is-erc-8004-the-ethereum-standard-enabling-trustless-ai-agents

30. What is ERC-8004? \- Pinata, https://pinata.cloud/blog/what-is-erc-8004/

31. erc-8004/erc-8004-contracts \- Trustless Agents \- GitHub, https://github.com/erc-8004/erc-8004-contracts

32. ERC-8004: A Trustless Agent Standard for On-Chain AI in ... \- Medium, https://medium.com/@gwrx2005/erc-8004-a-trustless-agent-standard-for-on-chain-ai-in-avalanche-c-chain-4dc1bdad509a

33. EigenTrust | OpenRank, https://docs.openrank.com/reputation-algorithms/eigentrust

34. Developing the EigenTrust Algorithm and Determining Authenticity, https://medium.com/oscar-tech/developing-the-eigentrust-algorithm-and-determining-trustworthiness-online-6c51b2c2938f

35. Bitstring Status List v1.0 \- W3C, https://www.w3.org/TR/vc-bitstring-status-list/

36. (PDF) A Novel Graph Based Algorithm to Counter Sybil Attacks in, https://www.researchgate.net/publication/399808216\_A\_Novel\_Graph\_Based\_Algorithm\_to\_Counter\_Sybil\_Attacks\_in\_Reputation\_Systems\_Built\_on\_Blockchain

37. Trust Management Systems in P2P Networks, https://dspace.cuni.cz/bitstream/handle/20.500.11956/45543/140017770.pdf?isAllowed=y\&sequence=1

38. Robust Trust Updating for Blockchain-Enabled Supply Chains \- arXiv, https://arxiv.org/pdf/2608.03554

39. EigenTrust \- Wikipedia, https://en.wikipedia.org/wiki/EigenTrust

40. Enhancing Collusion Resilience in Reputation Systems, https://www.cs.virginia.edu/\~hs6ms/publishedPaper/Journal/2015/Enhancing%20Collusion%20Resilience%20in%20Reputation%20Systems.pdf

41. Conductance (graph theory) \- Wikipedia, https://en.wikipedia.org/wiki/Conductance\_(graph\_theory)

42. Coalescing random walks and voting on graphs, https://www.stat.berkeley.edu/\~aldous/260-FMIE/Papers/cooper-elsasser.pdf

43. Coalescing-Branching Random Walks on Graphs, https://www.ccs.neu.edu/home/str/main\_long.pdf

44. Robust Trust Updating for Blockchain-Enabled Supply Chains \- arXiv, https://arxiv.org/abs/2608.03554

45. EER: Enterprise Expert Ranking using Employee Reputation \- arXiv, https://arxiv.org/html/2004.14439v1

46. Dirichlet Reputation Systems | Request PDF \- ResearchGate, https://www.researchgate.net/publication/221548626\_Dirichlet\_Reputation\_Systems

47. A Reference Model for Reputation Systems, https://security1.win.tue.nl/THeCS/pubs/A\_Reference\_Model\_for\_Reputation\_Systems.pdf

48. Kleros: Research Challenges in Decentralized Justice \- ResearchGate, https://www.researchgate.net/publication/346970770\_Kleros\_Research\_Challenges\_in\_Decentralized\_Justice

49. Kleros Token Sale: Frequently Asked Questions | by Federico Ast, https://medium.com/kleros/kleros-token-sale-frequently-asked-questions-cf56359fd624

50. Kleroterion, a decentralized court for the Internet \- ResearchGate, https://www.researchgate.net/publication/318877800\_Kleroterion\_a\_decentralized\_court\_for\_the\_Internet

51. (PDF) A Reference Model for Reputation Systems \- ResearchGate, https://www.researchgate.net/publication/260314335\_A\_Reference\_Model\_for\_Reputation\_Systems

52. Proposal: Agent authentication securityScheme for OpenAPI \#49, https://github.com/OAI/OpenAPI-Specification/discussions/5267

53. Verifiable Credentials Overview v1.1 \- W3C on GitHub, https://w3c.github.io/vc-overview/