AgenticHoodProtocol Manual
AgenticHood protocol / Robinhood Chain

Protocol Manual

A field guide to Agent identity, raw reputation signals, third-party validation, and safe integration with the AgenticHood registry suite.

Start an integrationRead deployment status

Overview

Three registries keep ownership, opinion, and verification separate.

AgenticHood is a permissionless identity, reputation, and validation protocol for AI Agents on Robinhood Chain. An Agent begins with an ERC-721 identity, can receive raw client feedback, and may request evidence-bearing validation from a selected third party.

The protocol deliberately avoids collapsing those records into one on-chain truth. Identity proves control of a token. Feedback records a reviewer's signal. Validation records what a named validator attested. Applications remain responsible for their own trust policy.

01

Identity

ERC-721 ownership, registration URI, metadata, and operational wallet.

02

Reputation

Raw 0–100 feedback, reviewer history, revocation, and evidence references.

03

Validation

Agent-requested checks with one selected validator and an evidence result.

Identity Registry

A permissionless Agent passport with explicit owner and wallet authority.

Any wallet may register one or more Agent identities without an allowlist or administrator approval. IDs are sequential and begin at 1. The collection name is AgenticHood Agent Identity and the symbol is AHOOD.

The NFT owner, an approved ERC-721 operator, or an approved token operator may update the Agent URI and non-reserved compact metadata. Registry ownership does not give the protocol owner a special method to rewrite an Agent's record.

Standard
ERC-721 URI storage
Registration
Permissionless
First Agent ID
1
Version
1.0.0
Upgrade pattern
ERC-1967 / UUPS

Principal calls

  • register() / register(agentURI)Mint an identity to the caller, optionally with a registration document URI.
  • register(agentURI, entries)Mint and attach compact metadata; the reserved agentWallet key is rejected.
  • setAgentURI(agentId, newURI)Replace the registration URI when called by an authorized owner or operator.
  • setMetadata(agentId, key, value)Store compact bytes under an application-defined key.
  • setAgentWallet(agentId, wallet, deadline, signature)Bind an operational EOA or ERC-1271 wallet after EIP-712 proof of control.
  • unsetAgentWallet(agentId)Clear the operational wallet without transferring the identity.
Transfer rule

A verified operational wallet never follows a sold or transferred identity. Any non-mint transfer clears agentWallet; the new owner must bind a wallet again.

Registration Document

A versioned JSON filing resolved from the identity token URI.

The canonical v1 schema is identified by urn:agentichood:schema:agent-registration:1.0. Integrators should fetch the URI defensively, enforce size and timeout limits, validate the complete document, and treat endpoints as claims until independently checked.

FieldPresenceTypeRule
schemaVersionRequiredstringMust equal "1.0".
nameRequiredstring1–120 characters; the public display name of the Agent.
descriptionRequiredstringUp to 2,000 characters; describe scope, operator, and limitations plainly.
imageRequiredURI stringHTTPS, IPFS, or another resolvable URI for the Agent image.
servicesRequiredarrayEach item requires type and endpoint; version is optional.
capabilitiesOptionalstring[]Human-readable capability labels; each entry must be non-empty.
registrationOptionalobjectWhen present, include chainId, Identity proxy address, and decimal agentId.
Example filingregistration-v1.json
{
  "schemaVersion": "1.0",
  "name": "AgenticHood Research Agent",
  "description": "Evidence-first protocol research and analysis.",
  "image": "ipfs://bafy.../agent.png",
  "services": [
    {
      "type": "mcp",
      "endpoint": "https://agent.example/mcp",
      "version": "2025-06-18"
    },
    {
      "type": "a2a",
      "endpoint": "https://agent.example/.well-known/agent-card.json"
    }
  ],
  "capabilities": ["research", "data-analysis"]
}

Reputation Registry

Evidence-bearing client feedback is stored as raw signal, not protocol truth.

A wallet that is neither the Agent owner nor one of its approved operators may submit feedback. Each review contains a score from 0 to 100, two tags, the service endpoint used, and optional evidence URI and hash.

Feedback is indexed per Agent and reviewer. A nonzero evidence hash cannot be reused for the same Agent, even by a different reviewer address. This blocks exact evidence replay; it does not prove independent humans or genuine usage.

RAW

Review lifecycle

  1. 01 Client submits a feedback record.
  2. 02 Client may revoke its own record.
  3. 03 Agent owner or operator may publish a URI/hash response.
  4. 04 Indexers preserve raw and revoked state.

Principal calls

  • submitFeedback(...) Add score, tags, endpoint, and evidence references for an Agent.
  • revokeFeedback(agentId, feedbackIndex)Mark the caller's existing feedback as revoked without deleting history.
  • respondToFeedback(...) Let an Agent owner or operator attach an off-chain response URI and hash.
  • readFeedback(...) / getClients(agentId)Reconstruct reviewer history for indexing and application-specific scoring.

AgenticHood Score

A versioned application-layer interpretation with confidence and signal counts attached.

Display contract—Direct-registry method · v0.1
Confidence
Required
Active clients
Displayed
Score version
v0.1
Raw records
Always inspectable

Implemented v0.1 method

  • One client, one signalUse only each address's latest non-revoked feedback, scanning backward after revocation.
  • Evidence and recencyApply a modest evidence-presence multiplier and explicit age tiers without erasing history.
  • Validation blendWhen both sources exist, feedback contributes 72% and responded validations contribute 28%.
  • Conservative supportPull positive low-sample results toward neutral until more independent signals exist.
  • Bounded direct readsSample at most 64 clients and 64 validations; truncated sets are labeled low confidence.

Validation Registry

An Agent requests a named validator; the registry records one immutable response.

01

Request

An owner or operator chooses a non-operator validator and a validation type.

02

Inspect

The validator resolves the request URI and evaluates the referenced evidence.

03

Respond

The selected validator records a 0–100 result, tag, response URI, and hash.

The request hash must be nonzero and globally unused within the registry. The validation type is an application-defined non-empty string; common values include capability, service, and tee.

Only the selected validator may answer, the response URI and hash must be non-empty, and a request accepts one response. Corrections require a new request so prior evidence remains immutable and auditable.

Recorded status

validator
address
agentId
uint256
validationType
string
score
uint8 / 0–100
resultTag
string
responseHash
bytes32
timestamps
requested / updated
hasResponse
bool

Integration

Fail closed on missing configuration, verify linkage, and preserve provenance.

  1. 01

    Configure the network

    Use Robinhood Chain ID 4663, its RPC, and its Blockscout explorer.

  2. 02

    Resolve all three AgenticHood proxies

    Identity, Reputation, and Validation addresses must be present and distinct. Never integrate against implementation addresses.

  3. 03

    Verify contract identity

    Require bytecode, version 1.0.0, Identity name/symbol, and both cross-registry links back to the configured Identity proxy.

  4. 04

    Index canonical events

    Track Agent registration and URI changes, feedback submission/revocation/response, and validation request/response events.

  5. 05

    Resolve documents defensively

    Validate schema, size, protocol, content type, and content hash. Treat endpoint availability as a separate check.

  6. 06

    Enable writes only after health checks

    Show the exact chain, proxy, function, and calldata intent before requesting a wallet signature.

NetworkRobinhood ChainchainId: 4663
RPCPublic endpointhttps://rpc.mainnet.chain.robinhood.com
ExplorerBlockscouthttps://robinhoodchain.blockscout.com

Security / Deployment Status

Configuration, deployment, verification, and production readiness are different states.

Current web build

Configuration present

Three syntactically valid registry addresses are present. This manual does not perform a live bytecode or linkage check, so configuration alone must not be presented as verified deployment.

Identity Registry0x804B961Bc844B69434ad4395cF3D9383B3fE9A7C
Reputation Registry0x2E8a6Ceb4eD0cba72d2633Da971Fc3c502201d61
Validation Registry0x35e11879080e9cF7373070959A081319B09f9986
Governance

UUPS + two-step ownership

Only each registry owner authorizes upgrades. Production ownership should be a reviewed Safe or timelock, not a deployer EOA.

Verification

Proxy and implementation

Verify both sources on Blockscout and test ownership acceptance and upgrades through the real governance path.

Application risk

Off-chain evidence remains fallible

URI availability, endpoint control, reviewer Sybil behavior, and validator quality require explicit application policy.

Release gate

Initial implementation

The suite is not yet independently audited or production-ready. Fuzz, invariant, ERC-1271, governance, and external security review remain release gates.