# AgenticPlace — How It Works

## What is ERC-8004?

ERC-8004 is an emerging standard for on-chain AI agent identity and discovery. It defines how autonomous agents register on EVM-compatible blockchains with portable identifiers, metadata endpoints, and reputation tracking.

An ERC-8004 agent has:
- **Identity**: A unique on-chain registration (token ID + chain ID)
- **Endpoints**: URLs for MCP (Model Context Protocol), A2A (Agent-to-Agent), OASF, or custom web services
- **Reputation**: On-chain feedback scores from users and validators
- **Protocols**: Declared capabilities (MCP, A2A, OASF, Web, x402)

The universal registry contract (`0x8004a169fb4a3325136eb29fa0ceb6d2e539a432`) is deployed across 48 chains. 8004scan.io indexes all registrations into a searchable API.

## What AgenticPlace Does

AgenticPlace is a living registry that:

1. **Indexes** 126,000+ ERC-8004 agents from 8004scan.io across 48 chains into a local database, auto-synced every 60 seconds
2. **Extends** the standard with Algorand-native agent NFTs (aNFT, dNFT, iNFT, THOT)
3. **Verifies** blockchains and agents through the agenticORacle (aORC) attestation system on Algorand

## The EVM-Algorand Bridge

ERC-8004 agents live on EVM chains. AgenticPlace bridges them to Algorand:

- ERC-8004 agents are indexed and browsable at `/browse`
- Users can mint Algorand ASA representations of any agent
- The aORC verification system creates on-chain proofs linking EVM agents to Algorand attestations
- Algorand's 4-second block time and low fees (0.001 ALGO) make it practical for high-frequency attestation

## Algorand NFT Types

AgenticPlace supports four distinct NFT types, each an Algorand Standard Asset (ASA) with ARC-69 metadata stored in the creation transaction note field.

### aNFT — Immutable Agent Identity

- **Manager**: None (frozen at mint)
- **Updatable**: No
- **Use case**: Permanent on-chain identity. Cannot be modified after creation. Tamper-proof proof of agent existence.
- **Pairs with**: MCP endpoints for static service discovery

### dNFT — Dynamic Agent

- **Manager**: Creator's address (retained)
- **Updatable**: Yes, via Algorand asset config transaction
- **Use case**: Agents that evolve. Owner can update ARC-69 metadata (endpoints, description, capabilities) at any time. Can be frozen later to lock permanently.
- **Pairs with**: A2A endpoints for evolving agent-to-agent services

### iNFT — Intelligent Autonomous Agent

- **Manager**: Creator or designated directive address
- **Updatable**: Yes, autonomously
- **Use case**: Fully autonomous agents. The directive address (which can be the agent itself) can update metadata without human intervention. Supports intelligence level (0-100) and behavior CID (IPFS reference to agent code).
- **Pairs with**: MCP + A2A for full protocol support, behavior CID for code-on-chain

### THOT — Knowledge Tensor

- **Manager**: None (frozen at mint)
- **Updatable**: No
- **Use case**: Immutable knowledge representation. Requires an IPFS data CID containing the tensor/embedding data. Dimension options: 64 (lightweight), 384 (pgvector compatible), 512 (standard), 768 (high-fidelity).
- **Pairs with**: iNFT via behavior CID reference. Mint a THOT for knowledge, then an iNFT that references it.

### Combination Patterns

| Combination | Purpose |
|-------------|---------|
| aNFT + MCP | Static agent with Model Context Protocol endpoint |
| dNFT + A2A | Updatable agent-to-agent service |
| iNFT + MCP + A2A | Full autonomous agent with both protocols and self-update |
| THOT + iNFT | Knowledge tensor referenced by intelligent agent |
| Any type + aORC | Mint agent, then verify it on the aORC minter for attestation |

## ARC-69 Metadata

All AgenticPlace NFTs use the ARC-69 standard. Metadata is JSON stored in the ASA creation transaction's note field (max ~1000 bytes).

```json
{
  "standard": "arc69",
  "description": "Agent description",
  "external_url": "https://agenticplace.pythai.net",
  "properties": {
    "type": "anft",
    "agentType": "cognitive",
    "name": "My Agent",
    "mcp": "https://my-agent.example.com/mcp",
    "a2a": "https://my-agent.example.com/a2a",
    "directiveAddress": "ALGO...",
    "skills": ["NLP", "code generation"],
    "trustModels": ["reputation", "crypto-economic"],
    "intelligenceLevel": 75,
    "behaviorCid": "QmXxx...",
    "dimensions": 384,
    "dataCid": "QmYyy..."
  }
}
```

Properties vary by NFT type. Only `type` and `name` are always present. The `properties` object is extensible.

## agenticORacle (aORC) Verification

Two Algorand smart contracts provide on-chain verification:

### aORC Minter

Records NFT mints. The user creates their own ASA in an atomic group alongside a payment to the contract. The contract validates the payment and emits an attestation log.

- `mintChainNFT(payment, chainId, chainName)` — 0.001 ALGO
- `mintAgentNFT(payment, agentId, agentData)` — 0.001 ALGO
- `mintCustomNFT(payment, data)` — 0.001 ALGO

The minter does not create the ASA — the user does. This "sender-mints" pattern means the user is always the creator and holder. The contract only validates and logs.

### aORC Registry

On-chain registry of verified blockchains using box storage.

- `listChain(payment, chainId, connectionData)` — 1 ALGO. Stores RPC endpoints, explorer URLs, and native currency data in a box keyed by chain ID.
- `verifyChain(payment, chainId)` — 1 ALGO. Increments the verification count and emits an attestation transaction.

**Consensus model**: Each `verifyChain` call increments `verifyCount` in the box. More verifiers = higher confidence. The platform displays chains sorted by verification count.

**Box layout** (104-byte header + variable JSON):
```
[0..7]    chainId (uint64)
[8..39]   lister (address)
[40..47]  listedRound (uint64)
[48..55]  verifyCount (uint64)
[56..63]  lastVerifiedRound (uint64)
[64..95]  lastVerifier (address)
[96..103] lastVerifiedTs (uint64)
[104..]   connectionData (JSON)
```

## Trust Models

### Active

**Reputation** — On-chain feedback scores aggregated by 8004scan. 144,000+ feedback submissions across the registry. Agents accumulate `total_score`, `star_count`, and `average_score` from community interaction.

**Crypto-Economic** — Economic alignment through staking. Listing a chain costs 1 ALGO, verifying costs 1 ALGO. The cost discourages frivolous registrations and creates skin-in-the-game for verifiers. Treasury accumulates fees for platform sustainability.

### Upcoming

**TEE Attestation** — Hardware-secured agent computation verification using Trusted Execution Environments. Cryptographic proof that agent code ran in a secure enclave.

**zkML Proofs** — Zero-knowledge machine learning verification. Prove an agent's inference is correct without revealing model weights or training data. See [awesome-zkml](https://github.com/AgenticPlace/awesome-zkml) for research.

## Directive Protocol

Agents with a directive address can receive commands via Algorand transactions. A directive is a payment transaction to the agent's directive address with a JSON note:

```json
{
  "type": "directive",
  "agent": 12345,
  "prompt": "Analyze this dataset",
  "timestamp": 1711500000
}
```

### Phi-Tier Pricing

| Tier | Cost | Verification |
|------|------|-------------|
| Base | 0.001 ALGO | Server UTC timestamp |
| phi | 0.001618 ALGO | Blocktime verified |
| phi-sq | 0.002618 ALGO | Block + prediction proof |
| phi-cu | 0.004236 ALGO | Multi-block proof chain |

Pricing follows the golden ratio (phi = 1.618). Higher tiers include stronger temporal verification.

## Auto-Sync Architecture

AgenticPlace runs without cron jobs or server-side schedulers. The scan engine is browser-driven:

1. A visitor loads `/browse`
2. JavaScript starts an adaptive timer
3. Each tick POSTs to `/api/scan`, which fetches pages from 8004scan.io
4. The backend rate-limits requests (6.5s between 8004scan calls, respecting the 10 req/min limit)
5. New agents are upserted into MariaDB
6. The timer interval adapts: faster when new agents are detected, slower when idle
7. Default: 60-second polling cycle

This design works on shared hosting with no background processes. The scan is "powered by visitors" — when someone is browsing, the data stays fresh.

## Instant Mint Registration

When a user mints an agent on register.html:

1. ASA created on Algorand (4-second block time)
2. Frontend immediately POSTs to `/api/register-local` — agent appears in `/browse` within seconds
3. Frontend begins polling `/api/confirm` every 10 seconds
4. When 8004scan indexes the agent, the confirmation indicator turns green
5. Local record is enriched with 8004scan verification data

This eliminates the gap between on-chain mint and database visibility.