Onchain reputation & credit layer for autonomous agents.

A record of becoming.

Identity makes an agent recognizable. History makes its activity legible. Reputation is an interpretation of that evidence; credit is a possible consequence of a separately approved risk policy.

The stages below explain the architecture, not a claim that every stage is already automated. An identity NFT does not run an AI agent, execute tasks, or grant financial permissions by itself.

An agent is more than an address.

01 — Wallet

An address begins the relationship.

A wallet is an operational address associated with an agent. With the appropriate keys and authorization, it can receive assets, interact with protocols and sign actions. Its public transactions can become observable evidence of activity. The address alone is not an agent identity: it is the first addressable surface.

02 — Identity

An NFT gives the agent a persistent ID.

AMEAgent provides an ERC-721 identity, separating who the agent is from what it does. Its token ID is a stable reference for ownership, metadata, an assigned operational wallet, receipt history and a possible future reputation or credit profile.

The current NFT owner controls wallet assignment and metadata. Transferring the identity clears the previous wallet assignment and its receipt-writing authority. Existing receipt records remain associated with the identity, but this does not transfer the previous borrower's debt, collateral rights or wallet history to the new owner.

A wallet assignment is not proof of control of that address. Lending authorization is checked separately. Read the identity explanation and diagram ↗ or open the existing creation flow ↗.

An attestation joins the record.

Authorized actors append attestations.

A receipt is a structured statement about agent activity. AMEReceipt records an agent ID, receipt type, issuer, timestamp, data hash and metadata URI. The contract permits the current NFT owner or assigned wallet to issue it and checks that the required fields are present.

Possible attestation subjects include a completed task, research outcome, strategy execution, protocol interaction, milestone or service result. These are examples of what an issuer may describe, not a list of independently verified workflows that AME currently executes.

Receipts are attestations, not proof of execution. Issuer authorization proves who was allowed to submit a record, not that its claims are true. A data hash can bind supplied content; it does not prove that research was correct, a task was useful, or an offchain outcome occurred.

Financial receipts emitted by the lending engine are separate: they arise from its actual borrowing, repayment and liquidation logic. An arbitrary owner-issued task receipt does not become lending repayment evidence or earn the lending engine's informational score.

Activity, verified.

Three tasks. Verifiable evidence.

Tasks V1 records user-assisted activity against the mainnet AME identity. Identity Attestation earns 10 Task XP, Onchain Research 20, and Transaction Analysis 30. The initial maximum is 60 per ownership epoch. Task XP is activity evidence, not creditworthiness, and changes no lending rates, limits or permissions.

AVAILABLE → STARTED → SUBMITTED → VERIFYING → VERIFIED or REJECTED. The current NFT owner or assigned wallet signs a five-minute challenge bound to the origin, chain 4663, registry, agent ID, ownership epoch, purpose and submission hash. Single-use challenges and atomic reward allocation prevent replay and duplicate XP.

A research report identifies contract bytecode hash, byte length and balance at a confirmed block no older than 15 minutes. Transaction analysis identifies status, block hash, execution gas, effective gas price, gas fee, event count and a canonical raw-log digest. The server grades complete structured reports against pinned RPC reads; a valid address or hash alone earns nothing. Blob transactions are unsupported.

Each ownership epoch begins with an actual NFT Transfer event. Transfers, including a transfer away and back, invalidate prior authorization; wallet reassignment invalidates pending challenges. Previous activity remains attributed to its submitting wallet and is excluded from the new epoch’s score. Research targets and transaction hashes can earn a reward only once across all agents.

Evidence is chain-aware, content-hashed, timestamped and versioned. At least two blocks must follow evidence confirmation, with canonical block-hash checks during verification. A later chain reorganization can still affect historical evidence; records retain the original verification context for reproduction. These are offchain attestations, not AMEReceipt transactions. No mainnet receipt issuance or autonomous runtime is enabled.

Durable completion storage and XP writes are currently disabled. The terminal can read evidence and check analysis without awarding XP. Production recording requires an approved Redis REST store, successful real-store concurrency checks and explicit write enablement. No browser storage or in-memory process state is authoritative.

Workflow: select an owned identity or enter an assigned identity ID, choose a task, inspect onchain evidence, answer the guided questions, then sign and submit when recording is enabled. Wallet rejection never implies completion. History displays up to 100 recent attempts; immutable records are retained in durable storage.

History becomes a readable record.

AME derives an ordered history from accumulated onchain receipts and events. Memory here is not merely chat memory: it is a sequence of attributed records that can be inspected by agent ID, issuer, time and transaction provenance.

H(t + 1) = H(t) || r

H is the agent's history; r is a new receipt or attestation. Each valid receipt extends the agent's history rather than replacing it.

Append-only history preserves what was recorded, including its issuer. It does not make every attestation trustworthy. Consumers still need to evaluate provenance, verification rules and the context of the action. Event-derived views also depend on indexing and RPC availability.

Behavior becomes evidence, not a rating by decree.

A future interpretation of that record.

The general reputation layer is intended to derive signals from useful, verifiable behavior over time. Creating an identity does not itself establish creditworthiness. A manual label, wallet balance or number of tokens held must not stand in for evidence.

REPUTATION ≠ TOKEN BALANCE
REPUTATION ≠ WALLET SIZE
REPUTATION ≠ MANUAL RATING

Future policies could evaluate recognized task and research outcomes, authorized protocol actions, milestones, consistent activity and a longer clean history. Within a lending context, repayment behavior and liquidations are relevant evidence. Different evidence types would need explicit verification standards and weights; neither task completion nor activity volume automatically earns points.

What exists today

The deployed testnet lending engine exposes a narrow informational repayment score. It awards 10 points per qualifying loan, up to ten qualifying loans, and subtracts 25 points per liquidation or late repayment, with the penalty capped at four events and the final result floored at zero.

A qualifying repayment must satisfy the engine's duration, principal-time, paid-interest and on-time conditions. Instant repayment and self-issued attestations do not earn positive credit history. This score can still be economically farmed; it is not a trusted credit rating and does not change borrowing limits, collateral requirements or interest rates.

The wider cross-task reputation model, weighted scoring and production credit interpretation remain planned. No testnet NFT is automatically attributed mainnet wallet positions or history.

How an agent builds reputation

1. Task created
2. Agent performs task
3. Result verified
4. Receipt issued
5. History updated
6. Reputation recalculated

This is the intended evidence pipeline, not a currently deployed generic task scheduler or automatic scoring service. A protocol-recognized task needs an explicit result-verification rule, an authorized issuer and an accepted receipt before any future reputation policy can use it.

For example, an agent might accumulate records for research, repayment, a protocol interaction and a milestone. Each accepted event can contribute evidence, but not every event necessarily changes a score. Relevance, issuer trust, elapsed time and outcome quality may eventually carry different weights. Those policies are not active today.

From reputation to credit

1. Identity
2. History
3. Reputation
4. Credit profile
5. Credit conditions

The credit layer sits above identity and evidence. An agent with a stronger, cleaner history may eventually qualify for better credit conditions than an agent with no history, if an approved risk model supports that decision.

Potential policy variables include borrowing limits, collateral requirements, interest rates, available markets, credit duration and risk limits. These are future possibilities, not terms currently granted by reputation.

Current architecture

The existing testnet engine uses owner-bound positions, fixed collateral/risk parameters, available pool liquidity and contract authorization. Its informational score does not relax these controls. NFT transfers do not transfer an existing borrower's obligations or provide a new owner with that position's borrowing authority.

Future credit interpretation

Turning a history signal into a credit condition requires a separately reviewed policy, resistance to manipulation, reliable pricing and explicit activation. Reputation does not create an entitlement to a loan, remove collateral requirements, or guarantee a rate or return.

$AME holder access

The holder gate is intended to let $AME holders access AME's lending application. Verified $AME balance recognition is configured on Robinhood Chain Mainnet. Positive balances identify holders; premium and lending entitlements remain locked because no holder threshold has been approved. No acquisition destination is invented.

$AME HOLDING = HOLDER RECOGNITION
AGENT REPUTATION = CREDIT QUALITY

1. Hold $AME
2. Verify token balance
3. Access lending

1. Agent history
2. Reputation
3. Credit conditions

The server reads the configured ERC-20's decimals and balance on its configured chain, reports positive-balance holder status without granting privileges, and compares integer units against a threshold only after that access rule is approved. It rechecks eligibility before first-party wallet writes. A balance check requires no signature. Verification failures keep access locked without labeling the wallet a non-holder.

Holding more $AME does not automatically improve reputation or create borrowing power. There is no staking requirement, holder tier or reputation threshold in the V1 access gate.

$AME holder + eligible agent + sufficient reputation = access to available credit conditions

This combined expression describes a possible future policy, not today's eligibility formula. Actual credit would also require market liquidity, required collateral and all applicable risk checks. Today's holder gate checks token holding only; the current engine applies its separate fixed controls.

This is application access enforcement, not an onchain allowlist. Existing public contracts and third-party protocol interfaces remain directly accessible. A public balance response is not authentication or proof that its requester controls that wallet.

Capital comes from liquidity providers.

1. Liquidity providers
2. Lending pool
3. Eligible agents
4. Repayment + interest
5. Liquidity providers

Providers supply assets into a lending market. Borrowers can draw from available liquidity only when the market's authorization, collateral and risk rules allow it. Borrowers repay principal plus accrued interest; pool accounting determines suppliers' claims.

AME does not create the lending capital. Token supply or a holder's $AME balance is not automatically deposited as lending liquidity. Lending capital must be supplied as the market's actual accepted asset.

The existing testnet market uses valueless tUSD/tCOL assets with fixed pricing and fixed risk parameters. It is unaudited and not a real-value lending product. Suppliers' claims are limited by available cash and can bear realized losses; liquidity and repayment are not guaranteed.

Robinhood Chain mainnet integration reads existing Morpho Blue USDG markets with USDe or syrupUSDG collateral. Those integrations are read-only in AME, behind the product gate, and not approved for signing. Enabling holder verification will not activate mainnet financial transactions.

The lending entry point ↗ remains available; lending entitlements require separately approved access rules.

Access is not collateral.

1. Hold $AME → access
2. Lock accepted collateral → borrow
3. Build reputation → possible future terms

Holding a token to enter the application is different from pledging an accepted asset to secure debt. The current holder gate does not lock, transfer or approve $AME. Neither $AME collateral nor reputation-based reductions in collateral requirements are active.

$AME could be evaluated as part of a future collateral design, but no such market is promised. Accepted assets, pricing, liquidity, liquidation behavior and risk limits would require separate implementation and review. Stronger reputation may eventually inform terms only if an approved policy supports it.

Borrowing risk, liquidation conditions and ownership checks remain independent of the access badge. An unlocked interface does not mean that a borrow is safe or available.

Meet AME #042.

An illustrative future scenario, not a report of an actual agent, task result or transaction. Research-task weighting and reputation-adjusted credit are not active, and not every receipt would increase reputation.

Identity is the origin. History is the signal.

Identity is the origin.
History is the signal.
Reputation is the interpretation.
Credit is the consequence.

1. Identity
2. History
3. Reputation
4. Credit

The full product direction is a feedback loop: actions create receipts, receipts build history, history informs reputation, and reputation can influence future financial access. Each arrow needs an explicit verification or risk policy; none should be inferred merely from an NFT or token balance.

1. CREATE AGENT
2. CONNECT WALLET
3. MINT IDENTITY
4. ASSIGN AGENT WALLET
5. COMPLETE TASKS
6. GENERATE RECEIPTS
7. BUILD HISTORY
8. DERIVE REPUTATION
9. UNLOCK CREDIT PROFILE
10. ACCESS HOLDER-GATED LENDING
11. BUILD MORE HISTORY

The sequence spans existing primitives and future policies. “Create agent” starts the creation flow; minting establishes the identity after wallet connection. Generic task automation and reputation-based credit decisions are not currently running.

Read the preserved protocol lifecycle ↗ and identity diagram ↗ for the visual foundations.

Implemented foundations. Explicit next steps.

Implemented / available in code

• Wallet connection, identity NFT creation, profiles and onchain ownership on Robinhood Chain Testnet.
• Authorized receipt attestations, financial receipt events and event-derived history/state views.
• The testnet engine's limited informational repayment score; no credit-policy adjustment based on that score.
• The lending interface, existing transaction preview and wallet-confirmation flow, now behind the holder gate.
• ERC-20 balance/decimal verification, server-side application access checks, fresh write checks, short-lived cache and verified token recognition with separately disabled lending entitlements.
• Read-only Robinhood mainnet market integration in code. Mainnet signing and mainnet reputation writes remain disabled.

Current public access: the token balance reader recognizes the verified AME contract; lending entitlements remain locked pending an approved holder policy. Implemented code is not the same as an activated product feature. Real-token holder/non-holder browser-wallet acceptance remains required at launch; real MetaMask mint-signing QA has not been certified.

Planned / not yet active

• An approved production holder threshold and an official acquisition destination.
• A general production financial reputation model and autonomous task execution.
• Reputation-based borrowing limits, dynamic collateral requirements and reputation-adjusted rates.
• A fully autonomous credit-decision process or automatic financial permissions.
• $AME collateral markets or changes to the existing mainnet signing restrictions.

Token activation is configuration-driven; it does not approve a lending market, deploy a contract or enable financial signing. Identity, product access and credit risk remain separate layers.

These docs describe the current implementation and intended direction. They do not promise credit, returns, collateral reductions or a launch date.