# FRC-55: AI Agent Standard for the FractalAI Blockchain **Version 1.0 -- February 2026** **FractalAI Foundation** --- ## Table of Contents 1. [Abstract](#1-abstract) 2. [Introduction](#2-introduction) 3. [Background](#3-background) 4. [FRC-55 Architecture](#4-frc-55-architecture) 5. [Model Context Protocol (MCP) Integration](#5-model-context-protocol-mcp-integration) 6. [Retrieval-Augmented Generation (RAG)](#6-retrieval-augmented-generation-rag) 7. [Robotic Process Automation (RPA)](#7-robotic-process-automation-rpa) 8. [Agent Swarms](#8-agent-swarms) 9. [Agent Economy](#9-agent-economy) 10. [Smart Tokens (FRC-55T)](#10-smart-tokens-frc-55t) 11. [Smart NFTs (FRC-55N)](#11-smart-nfts-frc-55n) 12. [Cross-Chain Bridge](#12-cross-chain-bridge) 13. [Security Model](#13-security-model) 14. [Comparison with Existing Platforms](#14-comparison-with-existing-platforms) 15. [Tokenomics Integration](#15-tokenomics-integration) 16. [Future Work](#16-future-work) 17. [Conclusion](#17-conclusion) 18. [References](#18-references) --- ## 1. Abstract We present **FRC-55**, the AI Agent Standard for the FractalAI blockchain -- a comprehensive on-chain protocol for registering, executing, composing, and monetizing autonomous AI agents. FRC-55 is the first blockchain-native agent standard that unifies three foundational AI infrastructure patterns into a single composable framework: - **Model Context Protocol (MCP)** -- enabling agents to connect to external tools, databases, APIs, and blockchain state through a standardized server/tool interface - **Retrieval-Augmented Generation (RAG)** -- providing agents with verifiable, on-chain-anchored knowledge bases backed by decentralized storage and semantic search - **Robotic Process Automation (RPA)** -- allowing agents to define, trigger, and execute multi-step workflows in response to on-chain events, schedules, and market conditions FRC-55 extends into two companion standards for AI-enhanced digital assets: - **FRC-55T (Smart Tokens)** -- fungible tokens with embedded AI agents that autonomously manage supply, governance, treasury, oracles, and rewards - **FRC-55N (Smart NFTs)** -- non-fungible tokens that evolve over time, gain experience through owner interactions, level up, generate content, and converse via built-in AI personalities All three standards operate natively on the FractalAI blockchain, leveraging its post-quantum cryptography (CRYSTALS-Dilithium signatures, CRYSTALS-Kyber encryption), Proof of Fractal Work (PoFW) consensus, WASM-based FractalVM with native AI opcodes, and golden ratio (phi = 1.618033988749895) mathematics throughout tokenomics and system design. A cross-chain bridge protocol enables FRC-55 agents, FRC-55T tokens, and FRC-55N NFTs to operate across Ethereum, BNB Chain, Polygon, Arbitrum, Optimism, Avalanche, Solana, and Base, secured by an N-of-M multisig validator set with post-quantum signatures. This whitepaper specifies the complete FRC-55 ecosystem: agent lifecycle management, swarm orchestration, economic primitives (pricing, staking, slashing, reputation), smart asset behaviors, cross-chain interoperability, and the security model that governs the entire system. --- ## 2. Introduction ### 2.1 The Case for Blockchain-Native AI Agents The convergence of large language models (LLMs), autonomous agents, and blockchain technology represents one of the most significant architectural shifts in distributed computing. AI agents are rapidly evolving from simple chatbots into autonomous systems capable of reasoning, planning, using tools, managing funds, and collaborating with other agents. Yet the infrastructure for deploying, discovering, composing, and paying for these agents remains fragmented and centralized. Current AI agent platforms suffer from several fundamental limitations: **Centralization Risk.** Most AI agent frameworks (LangChain, AutoGen, CrewAI) run on centralized cloud infrastructure. A single provider outage, policy change, or censorship decision can disable entire agent ecosystems. Users have no sovereignty over agent execution or data. **Lack of Composability.** Agents built on different platforms cannot discover, communicate with, or pay each other without custom integration. There is no universal standard for agent-to-agent interaction, leading to siloed ecosystems and duplicated effort. **No Native Payment Rails.** AI agents need to pay for compute, data, and other agents' services. Existing payment systems require human intermediation (credit cards, bank transfers) or operate on blockchains that lack native AI primitives. Micropayments for per-call or per-token pricing are impractical on most L1 chains due to high gas costs. **Trust and Verification.** When an AI agent claims to have used a specific model, consulted a specific knowledge base, or produced output with a certain confidence level, there is no way to verify these claims on-chain. Agent reputation is either absent or managed by centralized platforms with opaque scoring algorithms. **Quantum Vulnerability.** Every existing blockchain-based AI agent platform uses ECDSA signatures. As quantum computing advances, all agent registrations, payments, and interactions secured by ECDSA become vulnerable to Shor's algorithm. The "harvest now, decrypt later" threat means that agent interactions recorded today may be compromised in the future. ### 2.2 Our Contribution FRC-55 addresses these limitations by providing a blockchain-native AI agent standard with the following properties: 1. **On-chain agent registry** with deterministic IDs, versioning, and full lifecycle management (create, update, pause, resume, destroy) 2. **Unified MCP/RAG/RPA integration** allowing agents to declare their tools, knowledge bases, and workflows as on-chain state that other agents and users can discover and verify 3. **Native payment primitives** supporting per-call pricing, per-token pricing, subscription models, and revenue sharing -- all denominated in FRAC with sub-cent transaction costs 4. **Composability through swarms** enabling multi-agent orchestration with five routing strategies (round-robin, load-balanced, specialized, consensus, pipeline) 5. **Verifiable reputation** through an on-chain rating system (0-1000 scale) where ratings are permanently recorded and averaged transparently 6. **Post-quantum security from genesis** using CRYSTALS-Dilithium for all signatures and CRYSTALS-Kyber for all encryption, ensuring agent registrations and interactions remain secure against quantum attacks 7. **Smart asset extensions** (FRC-55T and FRC-55N) that embed AI agents directly into tokens and NFTs, creating a new class of intelligent digital assets 8. **Cross-chain interoperability** allowing agents and assets to operate across eight major blockchains through a multisig-validated bridge protocol ### 2.3 Design Philosophy FRC-55 follows three core design principles: **The Golden Ratio Principle.** Consistent with the broader FractalAI architecture, the golden ratio (phi = 1.618033988749895) appears throughout FRC-55: in staking reward multipliers, reputation score weighting, swarm load balancing thresholds, and token behavior triggers. This is not decorative -- phi represents the mathematically optimal balance between growth and stability, and its properties as the "most irrational number" (by Hurwitz's Theorem) ensure resonance-free scheduling of agent workflows and trigger evaluations. **On-Chain State, Off-Chain Compute.** Agent registration, configuration, payments, reputation, and audit trails live on-chain. Actual model inference happens off-chain (on the agent operator's infrastructure or via FractalVM WASM execution). This separation ensures that the blockchain remains performant while still providing verifiability through signed responses, model hashes, and confidence scores. **Progressive Decentralization.** FRC-55 supports a spectrum from fully centralized agents (single owner, API-based model) to fully decentralized agents (open-source model, distributed execution, community governance). The standard does not mandate a specific deployment model but provides primitives that enable any point on this spectrum. ### 2.4 Document Organization Section 3 provides background on MCP, RAG, RPA, and existing blockchain AI platforms. Section 4 details the core FRC-55 agent architecture. Sections 5-7 describe the MCP, RAG, and RPA subsystems. Section 8 covers agent swarms. Section 9 specifies the agent economy. Sections 10-11 describe smart tokens and smart NFTs. Section 12 covers the cross-chain bridge. Section 13 analyzes security. Section 14 compares FRC-55 with existing platforms. Section 15 discusses FRAC tokenomics integration. Section 16 outlines future work. --- ## 3. Background ### 3.1 Model Context Protocol (MCP) The Model Context Protocol (MCP), introduced by Anthropic in late 2024, is an open standard for connecting AI models to external data sources and tools. MCP defines a client-server architecture where: - **MCP Servers** expose capabilities (tools, resources, prompts) through a standardized JSON-RPC interface - **MCP Clients** (typically AI models or agent frameworks) discover and invoke these capabilities - **Tools** are typed functions with input/output schemas that the model can call - **Resources** are data sources (files, databases, APIs) that provide context MCP has been rapidly adopted by major AI platforms (Claude, VS Code, Cursor, Windsurf) as the de facto standard for tool use. However, MCP was designed for single-machine or single-user scenarios. It lacks: - A discovery mechanism (how do you find available MCP servers?) - Payment rails (how does a server charge for tool use?) - Reputation (how do you know if a server is reliable?) - Decentralized hosting (servers run on centralized infrastructure) FRC-55 extends MCP to the blockchain context by registering MCP server configurations on-chain, enabling discovery, payment, and reputation tracking for every tool invocation. ### 3.2 Retrieval-Augmented Generation (RAG) Retrieval-Augmented Generation (RAG) augments language model responses with relevant information retrieved from external knowledge bases. The standard RAG pipeline consists of: 1. **Ingestion** -- Documents are chunked, embedded (converted to vector representations), and stored in a vector database 2. **Retrieval** -- User queries are embedded and used to find semantically similar chunks via approximate nearest neighbor (ANN) search 3. **Generation** -- Retrieved chunks are injected into the model's context window alongside the user query, grounding the response in factual data RAG is critical for AI agents because it allows them to access domain-specific knowledge without fine-tuning the underlying model. However, existing RAG systems are centralized: - Knowledge bases are stored on private servers or proprietary vector databases - There is no way to verify that an agent actually consulted a specific knowledge base - Knowledge base updates are opaque to users - There is no provenance chain from source data to embeddings to retrieved chunks FRC-55 addresses these limitations by anchoring knowledge base metadata on-chain (data hashes, URIs, embedding model identifiers, chunk counts) while storing the actual vector data on decentralized storage networks (IPFS, Arweave) or on-chain for small datasets. ### 3.3 Robotic Process Automation (RPA) Robotic Process Automation (RPA) refers to software that automates repetitive, rule-based tasks by mimicking human interactions with digital systems. Traditional RPA tools (UiPath, Automation Anywhere, Blue Prism) operate in enterprise environments, automating tasks like data entry, report generation, and system integration. AI-enhanced RPA (sometimes called "intelligent automation" or "hyperautomation") combines traditional RPA with AI capabilities: - **Cognitive Document Processing** -- using vision models to extract data from unstructured documents - **Natural Language Understanding** -- interpreting free-text instructions and converting them to structured workflows - **Decision Making** -- using ML models to make judgment calls within automated workflows - **Adaptive Execution** -- adjusting workflow parameters based on observed outcomes FRC-55 brings RPA to the blockchain by defining on-chain workflow specifications with typed steps, conditional branching, error handling, and event-driven triggers. Agents can define workflows that respond to on-chain events (new blocks, transactions, price changes), execute multi-step processes (API calls, token transfers, contract interactions), and produce verifiable results. ### 3.4 Existing Blockchain AI Agent Platforms Several projects have attempted to bring AI agents to blockchain, each with different approaches and trade-offs: **Autonolas (OLAS).** A platform for creating and running autonomous agent services on Ethereum. Autonolas uses a multi-agent framework where agents are composed of multiple components (skills, connections, protocols). Agents are registered on-chain via an NFT-based registry. The platform focuses on off-chain agent services that periodically checkpoint to Ethereum. Limitations: relies on Ethereum L1 (high gas costs), no native MCP integration, no built-in RAG, uses ECDSA (quantum-vulnerable). **Fetch.ai (FET).** A blockchain platform with a multi-agent framework called the "AI Engine." Fetch.ai provides an agent-based economy where agents discover each other through a decentralized search protocol. The platform has its own L1 chain (Cosmos SDK-based) with a custom consensus mechanism. Limitations: limited smart contract expressiveness, no MCP standard compliance, no post-quantum cryptography, relatively centralized validator set. **SingularityNET (AGIX).** A decentralized marketplace for AI services, originally focused on connecting AI model providers with consumers. SingularityNET runs on Ethereum and Cardano, with services registered on-chain and execution happening off-chain. The platform provides an SDK for wrapping AI models as services. Limitations: marketplace-only model (no agent autonomy), high gas costs on Ethereum, no native RPA or workflow capabilities, no post-quantum security. **Virtuals Protocol (VIRTUAL).** A platform for creating and tokenizing AI agents as digital assets on Base (Ethereum L2). Virtuals focuses on AI agents as entertainment and social media entities, with a bonding curve-based token launchpad for agent tokens. Limitations: entertainment focus limits enterprise applicability, built on Base (inherits Ethereum's security model and quantum vulnerability), no MCP/RAG/RPA integration, limited cross-chain capabilities. **ai16z / ElizaOS.** An open-source AI agent framework that gained prominence in the Solana ecosystem. ElizaOS provides a TypeScript-based framework for building AI agents that can interact with social media, DeFi protocols, and other on-chain systems. Limitations: framework only (no on-chain registry or standard), Solana-specific, no post-quantum cryptography, no formal agent economy. None of these platforms provides the unified MCP + RAG + RPA integration, post-quantum security, native L1 support, smart asset extensions, and cross-chain bridge that FRC-55 delivers. --- ## 4. FRC-55 Architecture ### 4.1 System Overview ``` +=========================================================================+ | FRC-55 AGENT ECOSYSTEM | +=========================================================================+ | | | +------------------------+ +---------------------------+ | | | FRC-55 REGISTRY | | AGENT SWARM MANAGER | | | | | | | | | | - Agent CRUD | | - Swarm creation | | | | - Owner verification | | - Routing strategies | | | | - Status lifecycle | | - Coordinator delegation | | | | - Call routing | | - Member management | | | | - Stats aggregation | | | | | +----------+-------------+ +----------+----------------+ | | | | | | v v | | +----------------------------------------------------------+ | | | FRC-55 AGENT | | | | | | | | +-------------+ +-------------+ +---------------+ | | | | | MCP | | RAG | | RPA | | | | | | | | | | | | | | | | - Servers | | - Knowledge | | - Workflows | | | | | | - Tools | | Bases | | - Triggers | | | | | | - Caps | | - Embeddings| | - Steps | | | | | | - Auth | | - Chunks | | - Conditions | | | | | +-------------+ +-------------+ +---------------+ | | | | | | | | +-------------+ +-------------+ +---------------+ | | | | | MODEL | | ECONOMY | | REPUTATION | | | | | | | | | | | | | | | | - Type | | - Pricing | | - Ratings | | | | | | - Hash | | - Earnings | | - History | | | | | | - URI | | - Staking | | - Score | | | | | | - Schema | | - Slashing | | - Count | | | | | +-------------+ +-------------+ +---------------+ | | | +----------------------------------------------------------+ | | | | | | v v | | +---------------------------+ +---------------------------+ | | | FRC-55T SMART TOKENS | | FRC-55N SMART NFTs | | | | | | | | | | - AI-driven behaviors | | - Dynamic metadata | | | | - Auto supply mgmt | | - XP / Level system | | | | - Governance AI | | - AI personality | | | | - Oracle integration | | - Evolution | | | | - Treasury management | | - Content generation | | | +---------------------------+ +---------------------------+ | | | | | | +-------------+---------------+ | | | | | v | | +----------------------------------------------------------+ | | | CROSS-CHAIN BRIDGE PROTOCOL | | | | | | | | Ethereum | BNB Chain | Polygon | Arbitrum | Optimism | | | | Avalanche | Solana | Base | Custom Chains | | | | | | | | - Token bridging (0.1% fee) | | | | - Agent cross-chain deployment | | | | - Smart NFT bridging | | | | - N-of-M multisig validation | | | +----------------------------------------------------------+ | | | +=========================================================================+ | FractalAI Blockchain (Layer 1) | | PoFW Consensus | Dilithium Signatures | Kyber Encryption | FractalVM | | Verkle Trees | RocksDB | libp2p | Golden Ratio (phi) Mathematics | +=========================================================================+ ``` ### 4.2 Core Agent Structure Every FRC-55 agent is defined by the `FRC55Agent` data structure, which captures the complete state of an autonomous AI agent registered on the FractalAI blockchain: ``` FRC55Agent | +-- Identity | +-- agent_id: Hash256 // Deterministic ID = SHA3(owner + name + timestamp) | +-- owner: Address // Post-quantum address (Dilithium pubkey derived) | +-- name: String // Human-readable agent name | +-- description: String // Agent purpose and capabilities | +-- version: u32 // Monotonically increasing version counter | +-- created_at: u64 // Millisecond UNIX timestamp of creation | +-- updated_at: u64 // Millisecond UNIX timestamp of last modification | +-- status: AgentStatus // Active | Paused | Destroyed | Upgrading | +-- Model | +-- model_type: ModelType // LLM | Classifier | Generator | Embedder | | | // MultiModal | Custom(String) | +-- model_hash: Hash256 // SHA3-256 hash of the model weights | +-- model_uri: String // URI to model (IPFS, Arweave, HTTP) | +-- framework: String // Runtime framework (onnx, tflite, etc.) | +-- input_schema: String // JSON Schema for input validation | +-- output_schema: String // JSON Schema for output validation | +-- max_tokens: u64 // Maximum context length | +-- temperature: u32 // Fixed-point temperature (700 = 0.7) | +-- MCP (up to 20 servers) | +-- mcp_servers: Vec | +-- capabilities: Vec | +-- RAG (up to 50 knowledge bases) | +-- knowledge_bases: Vec | +-- RPA (up to 100 workflows) | +-- workflows: Vec | +-- triggers: Vec | +-- Economy | +-- pricing: PricingConfig | +-- total_earnings: u128 // Accumulated FRAC earnings (wei) | +-- total_calls: u64 // Total number of calls served | +-- Reputation | +-- rating: u64 // Current average rating (0-1000) | +-- total_ratings: u64 // Number of ratings received | +-- rating_sum: u64 // Sum of all ratings (for average computation) | +-- Composability | +-- dependencies: Vec // IDs of agents this agent depends on | +-- subscribers: Vec
// Addresses subscribed to this agent | +-- Security +-- max_gas_per_call: u64 // Gas limit per invocation +-- allowed_callers: Vec
// Whitelist (empty = open access) +-- slashing_history: Vec ``` ### 4.3 Agent Identity Agent IDs are deterministic 256-bit hashes derived from the owner's address, the agent name, and the creation timestamp: ``` agent_id = SHA3-256(owner_address || agent_name || timestamp_le_bytes) ``` This derivation ensures: - **Uniqueness**: The combination of owner, name, and timestamp is unique per agent - **Verifiability**: Anyone can recompute the agent ID given the creation parameters - **Collision resistance**: SHA3-256 provides 128-bit post-quantum collision resistance - **Determinism**: The same inputs always produce the same agent ID ### 4.4 Agent Lifecycle FRC-55 agents follow a well-defined lifecycle with four states: ``` create_agent() | v +-------------+ | | +------> ACTIVE +<------+ | | | | | +------+------+ | | | | | pause() | resume() | | v | | +------+------+ | | | | | | | PAUSED +------+ | | | | +------+------+ | | | | (cannot update while paused, | | but can resume or destroy) | | | v | +------+------+ | | | +-------+ UPGRADING | (version incremented on update) | | +------+------+ | | destroy_agent() v +------+------+ | | | DESTROYED | (terminal state; no further mutations) | | +-------------+ ``` **State Transitions:** | From | To | Method | Authorization | |------|-----|--------|---------------| | -- | Active | `create_agent()` | Any address | | Active | Paused | `pause_agent()` | Owner only | | Paused | Active | `resume_agent()` | Owner only | | Active | Upgrading | `update_agent()` | Owner only | | Upgrading | Active | Automatic (after update completes) | -- | | Active/Paused | Destroyed | `destroy_agent()` | Owner only | | Destroyed | -- | -- | Terminal state | **Key invariants:** - Only the owner (the address that created the agent) can modify its state - Destroyed agents cannot be modified, resumed, or called - Paused agents reject all call requests but can be resumed - Version numbers increment monotonically on every update - The `updated_at` timestamp is refreshed on every state change ### 4.5 Agent Limits The FRC-55 registry enforces the following per-agent and per-owner limits to prevent resource exhaustion: | Resource | Maximum | Rationale | |----------|---------|-----------| | Agents per owner | 50 | Prevents address squatting | | MCP servers per agent | 20 | Bounds tool complexity | | Knowledge bases per agent | 50 | Bounds memory footprint | | Workflows per agent | 100 | Bounds automation complexity | | Swarm members | 20 | Bounds routing overhead | | Behaviors per token (FRC-55T) | 64 | Bounds execution cost | These limits are enforced at the registry level and apply uniformly to all agents regardless of owner balance or reputation. Future governance proposals may adjust these limits through on-chain voting. ### 4.6 Model Configuration Every FRC-55 agent specifies a model configuration that describes the AI model it uses for inference. This configuration is stored on-chain and can be verified by callers. **Supported Model Types:** | Type | Description | Typical Use | |------|-------------|-------------| | `LLM` | Large Language Model | Text generation, reasoning, conversation | | `Classifier` | Classification model | Sentiment analysis, categorization, spam detection | | `Generator` | Generative model | Image generation, code generation, music | | `Embedder` | Embedding model | Vector representation for RAG, similarity search | | `MultiModal` | Multi-modal model | Vision + language, audio + text | | `Custom(String)` | User-defined type | Domain-specific models | **Model Verification:** The `model_hash` field contains the SHA3-256 hash of the model weights file. This allows callers to verify that the agent is using the claimed model by: 1. Downloading the model from `model_uri` 2. Computing SHA3-256 of the downloaded weights 3. Comparing with the on-chain `model_hash` This verification is optional (not enforced by the protocol) but provides a trust anchor for users who want to verify agent behavior. Future versions may integrate zero-knowledge proofs of model inference (zkML) for trustless verification. ### 4.7 Composability and Dependencies FRC-55 agents are designed to be composable. An agent can: - **Depend on other agents**: The `dependencies` field lists agent IDs that this agent calls during its operation. This creates an on-chain dependency graph that users can inspect to understand the full execution path of a query. - **Subscribe to events**: The `subscribers` field lists addresses that receive notifications when the agent's state changes (new knowledge base, workflow update, status change). - **Call other agents**: Through the `CallOtherAgents` capability, an agent can invoke other FRC-55 agents as part of its execution, passing context and receiving structured responses. This composability model enables the construction of complex agent pipelines: ``` User Query | v +------------------+ +--------------------+ +------------------+ | Agent A |---->| Agent B |---->| Agent C | | (Router/Planner) | | (Domain Expert) | | (Output Formatter)| | | | | | | | Capabilities: | | Capabilities: | | Capabilities: | | - CallOtherAgents| | - ReadBlockchain | | - CallExternalAPI| | - ReadBlockchain | | - AccessOracle | | - TransferTokens | +------------------+ +--------------------+ +------------------+ ``` --- ## 5. Model Context Protocol (MCP) Integration ### 5.1 MCP Architecture in FRC-55 FRC-55 extends the Model Context Protocol to the blockchain by defining on-chain MCP server registrations. Each agent can register up to 20 MCP servers, each with its own tools, authentication requirements, and gas cost declarations. ``` FRC-55 Agent | +-- MCP Server 1 (Database) | +-- Tool: sql_query (gas: 500) | +-- Tool: schema_inspect (gas: 200) | +-- Auth: required | +-- MCP Server 2 (Blockchain) | +-- Tool: get_balance (gas: 100) | +-- Tool: get_tx_history (gas: 300) | +-- Auth: not required | +-- MCP Server 3 (API) | +-- Tool: price_feed (gas: 150) | +-- Tool: news_search (gas: 250) | +-- Auth: required | ... (up to 20 servers) ``` ### 5.2 MCP Server Types FRC-55 defines seven built-in MCP server types, plus an extensible custom type: | Server Type | Description | Example Tools | |-------------|-------------|---------------| | `Database` | SQL/NoSQL database access | sql_query, insert, update, schema | | `FileSystem` | File and document access | read_file, list_dir, search | | `API` | External REST/GraphQL APIs | http_get, http_post, graphql | | `Blockchain` | On-chain state queries | get_balance, get_block, call_contract | | `WebBrowser` | Web browsing and scraping | navigate, extract, screenshot | | `CodeExecution` | Sandboxed code execution | run_python, run_javascript, run_rust | | `Custom(String)` | User-defined server type | Any custom implementation | ### 5.3 MCP Tool Specification Each tool within an MCP server is defined by: ``` MCPTool { name: String // Unique tool identifier within the server description: String // Natural language description for the AI model input_schema: String // JSON Schema defining expected input output_schema: String // JSON Schema defining expected output gas_cost: u64 // Gas consumed per invocation } ``` The `gas_cost` field is critical for on-chain accounting. When an agent invokes a tool, the gas cost is deducted from the caller's gas allocation. This prevents unbounded resource consumption and provides a transparent cost model. **Example tool registration:** ```json { "server_id": "db-server-1", "name": "PostgreSQL MCP", "description": "SQL query server for market data", "server_type": "Database", "endpoint": "mcp://localhost:5432", "tools": [ { "name": "sql_query", "description": "Execute a read-only SQL query against the market database", "input_schema": "{\"type\": \"object\", \"properties\": {\"query\": {\"type\": \"string\"}}}", "output_schema": "{\"type\": \"array\", \"items\": {\"type\": \"object\"}}", "gas_cost": 500 } ], "auth_required": true, "enabled": true } ``` ### 5.4 Agent Capabilities FRC-55 defines a capability system that declares what an agent is allowed to do. Capabilities are registered on-chain and can be inspected by callers before invoking an agent. | Capability | Description | Risk Level | |-----------|-------------|------------| | `ReadBlockchain` | Read on-chain state (balances, blocks, transactions) | Low | | `WriteBlockchain` | Submit transactions to the blockchain | Medium | | `CallExternalAPI` | Make HTTP requests to external services | Medium | | `ExecuteCode` | Execute arbitrary code in a sandboxed environment | High | | `ManageFiles` | Read/write files on the agent's storage | Medium | | `CallOtherAgents` | Invoke other FRC-55 agents | Medium | | `TransferTokens` | Transfer FRAC or FRC-20 tokens | High | | `CreateTokens` | Mint new tokens (requires appropriate authority) | High | | `CrossChainBridge` | Initiate cross-chain transfers and deployments | High | | `AccessOracle` | Read data from oracle feeds | Low | Capabilities serve as both a documentation mechanism (telling callers what the agent can do) and a security mechanism (restricting what the agent runtime is allowed to access). The FractalVM enforces capability checks at the opcode level when executing agent WASM modules. ### 5.5 MCP Server Lifecycle MCP servers can be dynamically registered and removed from agents: ``` register_mcp_server(agent_id, owner, server) - Verifies owner authorization - Checks agent is not destroyed - Enforces maximum server limit (20) - Adds server to agent's mcp_servers list - Updates agent timestamp remove_mcp_server(agent_id, owner, server_id) - Verifies owner authorization - Checks agent is not destroyed - Removes server by server_id - Returns error if server_id not found - Updates agent timestamp ``` Servers can be individually enabled or disabled via the `enabled` flag without removing them from the agent's configuration. This allows temporary deactivation during maintenance or upgrades. --- ## 6. Retrieval-Augmented Generation (RAG) ### 6.1 RAG Architecture in FRC-55 FRC-55 provides native RAG support through on-chain knowledge base registrations. Each agent can maintain up to 50 knowledge bases, with metadata stored on-chain and actual vector data stored on decentralized storage networks. ``` +-------------------------------------------------------------------+ | FRC-55 RAG Pipeline | +-------------------------------------------------------------------+ | | | +-------------------+ +--------------------+ | | | Knowledge Sources | | On-Chain Registry | | | | | | | | | | - IPFS documents |---->| - kb_id | | | | - Arweave data | | - data_hash (SHA3) | | | | - On-chain state | | - data_uri | | | | - Oracle feeds | | - embedding_model | | | | - Agent outputs | | - chunk_count | | | +-------------------+ | - last_updated | | | +----------+----------+ | | | | | v | | +-------------------+ +--------------------+ | | | User Query |---->| Embedding + | | | | | | Semantic Search | | | +-------------------+ +----------+---------+ | | | | | v | | +--------------------+ | | | Context Assembly | | | | + Model Inference | | | +----------+---------+ | | | | | v | | +--------------------+ | | | Response with | | | | source attribution | | | +--------------------+ | +-------------------------------------------------------------------+ ``` ### 6.2 Knowledge Base Structure Each knowledge base registered with an FRC-55 agent contains: ``` KnowledgeBase { kb_id: String // Unique identifier within the agent name: String // Human-readable name description: String // What this knowledge base contains source_type: KnowledgeSourceType // Where the data comes from data_hash: Hash256 // SHA3-256 hash of the knowledge data data_uri: String // URI to the actual data embedding_model: String // Model used for vector embeddings chunk_count: u64 // Number of chunks in the knowledge base last_updated: u64 // Timestamp of last data update enabled: bool // Whether this KB is active } ``` ### 6.3 Knowledge Source Types FRC-55 supports six knowledge source types: | Source Type | Description | Verification Method | |-------------|-------------|---------------------| | `IPFS` | Content-addressed storage on IPFS | CID matches data_hash | | `Arweave` | Permanent storage on Arweave | Transaction ID verification | | `OnChain` | Data stored directly in blockchain state | State proof | | `OracleFeed` | Real-time data from oracle networks | Oracle signature verification | | `AgentOutput` | Output produced by other FRC-55 agents | Agent call receipt | | `Custom(String)` | User-defined source type | Application-specific | ### 6.4 On-Chain Data Integrity The `data_hash` field provides a cryptographic anchor for knowledge base integrity. When an agent claims to have consulted a knowledge base, verifiers can: 1. Retrieve the knowledge base configuration from the on-chain registry 2. Download the data from `data_uri` 3. Compute SHA3-256 of the downloaded data 4. Verify that the computed hash matches `data_hash` 5. Confirm that `last_updated` is recent enough for the use case This creates a verifiable provenance chain: ``` Source Data --> SHA3-256 Hash --> On-Chain Registry --> Agent Response | | | | | v | | "Sources: kb-docs" | v (in AgentCallResponse) | data_hash stored v on FractalAI chain Immutable integrity anchor ``` ### 6.5 Knowledge Base Management Knowledge bases can be dynamically added, updated, and removed: ``` add_knowledge_base(agent_id, owner, kb) - Verifies owner authorization - Checks agent is not destroyed - Enforces maximum KB limit (50) - Appends KB to agent's knowledge_bases list update_knowledge(agent_id, owner, kb_id, new_hash, new_uri) - Verifies owner authorization - Finds the KB by kb_id - Updates data_hash and data_uri - Refreshes last_updated timestamp remove_knowledge_base(agent_id, owner, kb_id) - Verifies owner authorization - Removes KB by kb_id - Returns error if kb_id not found ``` The `update_knowledge` method allows agents to refresh their knowledge bases as new data becomes available. The old `data_hash` and `data_uri` are overwritten, but the `last_updated` timestamp records when the change occurred. Future versions may maintain a full history of knowledge base versions for auditability. ### 6.6 RAG in Agent Calls When calling an FRC-55 agent, callers can optionally specify a `rag_query` field in the `AgentCallRequest`. This instructs the agent to perform RAG retrieval as part of processing the request: ``` AgentCallRequest { call_id: Hash256 agent_id: Hash256 caller: Address input: String // Primary input/question payment: u128 // FRAC payment in wei timestamp: u64 mcp_context: Option // Additional MCP context rag_query: Option // RAG retrieval query } ``` The agent's response includes `knowledge_sources`, a list of knowledge base names that were consulted during the response generation. This provides transparency about which knowledge bases influenced the output. --- ## 7. Robotic Process Automation (RPA) ### 7.1 RPA Architecture in FRC-55 FRC-55 provides a complete RPA framework through on-chain workflow definitions and event-driven triggers. Each agent can define up to 100 workflows, each containing a sequence of typed steps with conditional branching, error handling, and timeout controls. ``` +-------------------------------------------------------------------+ | FRC-55 RPA Engine | +-------------------------------------------------------------------+ | | | TRIGGERS | | +------------------+ +------------------+ +------------------+ | | | OnBlockProduced | | OnTransaction | | OnSchedule | | | | (every block) | | (filter by addr) | | (cron expression)| | | +--------+---------+ +--------+---------+ +--------+---------+ | | | | | | | +--------+---------+ +--------+---------+ +--------+---------+ | | | OnEvent | | OnAgentCall | | OnPriceChange | | | | (named events) | | (from agent X) | | (asset, %) | | | +--------+---------+ +--------+---------+ +--------+---------+ | | | | | | | +----------+----------+----------+----------+ | | | | | v | | WORKFLOW | | | +-------------------+-------------------+ | | | | | | | Step 1: Log("Starting workflow") | | | | | | | | | v (on_success) | | | | Step 2: APICall(oracle_endpoint) | | | | | | | | | | v (on_success) v (on_failure) | | | | Step 3: Conditional Step 4: Log | | | | | | | | | | v v | | | | Step 5: Step 6: | | | | Transfer CallAgent | | | | | | | +---------------------------------------+ | | | | CONTROLS | | - max_retries: 3 | | - timeout_ms: 30000 | | - enabled: true/false | +-------------------------------------------------------------------+ ``` ### 7.2 Workflow Structure Each workflow contains: ``` Workflow { workflow_id: String // Unique identifier within the agent name: String // Human-readable name description: String // What this workflow does steps: Vec // Ordered list of execution steps max_retries: u32 // Maximum retry attempts on failure timeout_ms: u64 // Total workflow timeout in milliseconds enabled: bool // Whether this workflow is active } ``` ### 7.3 Workflow Steps Each step in a workflow specifies an action, optional condition, and branching logic: ``` WorkflowStep { step_id: String // Unique step identifier action: WorkflowAction // What to do condition: Option // Condition to evaluate before executing on_success: Option // Step ID to jump to on success on_failure: Option // Step ID to jump to on failure timeout_ms: u64 // Per-step timeout } ``` ### 7.4 Workflow Actions FRC-55 defines eight workflow action types: | Action | Description | Parameters | |--------|-------------|------------| | `CallAgent` | Invoke another FRC-55 agent | agent_id, input | | `Transfer` | Transfer FRAC tokens | to (address), amount (wei) | | `ContractCall` | Call a smart contract method | contract, method, args | | `APICall` | Make an external HTTP request | endpoint, method, body | | `WaitForEvent` | Pause until a specific event occurs | event_type, filter | | `Transform` | Transform data using an expression | input_ref, expression | | `Conditional` | Branch based on a condition | condition, if_true, if_false | | `Log` | Record a log message | message | **Example workflow -- Price Monitor and Alert:** ``` Workflow: "Price Monitor" Steps: 1. Log("Checking FRAC price") on_success -> step 2 timeout: 5000ms 2. APICall("https://api.oracle.fractal", "GET", "") on_success -> step 3 on_failure -> step 4 timeout: 10000ms 3. Conditional(price > threshold, "step_5", "step_1") 4. Log("Oracle unavailable, retrying") on_success -> step 2 5. CallAgent(alert_agent_id, "FRAC price above threshold") max_retries: 3 timeout_ms: 30000 enabled: true ``` ### 7.5 Trigger Types Triggers connect events to workflows. When a trigger fires, it initiates the associated workflow: | Trigger Type | Description | Configuration | |-------------|-------------|---------------| | `OnBlockProduced` | Fires when a new block is added to the chain | None | | `OnTransaction` | Fires when a transaction matches a filter | filter_address (optional) | | `OnSchedule` | Fires on a cron schedule | cron_expression | | `OnEvent` | Fires when a named event is emitted | event_name | | `OnAgentCall` | Fires when this agent is called | from_agent (optional filter) | | `OnPriceChange` | Fires when an asset price changes beyond threshold | asset, threshold_percent | | `Manual` | Fires only when explicitly triggered | None | **Trigger structure:** ``` Trigger { trigger_id: String // Unique trigger identifier trigger_type: TriggerType // One of the seven types above workflow_id: String // ID of the workflow to execute enabled: bool // Whether this trigger is active } ``` ### 7.6 Workflow Execution Model Workflow execution follows these rules: 1. A trigger fires, initiating the associated workflow 2. The workflow engine begins at the first step 3. If a step has a `condition`, it is evaluated. If false, the step is skipped 4. The step's `action` is executed with its configured timeout 5. On success: jump to `on_success` step (or next step if not specified) 6. On failure: jump to `on_failure` step (or retry if within max_retries) 7. The workflow completes when no more steps are reachable or timeout is exceeded All workflow executions are recorded in the agent's state, providing a complete audit trail of automated actions taken by the agent. --- ## 8. Agent Swarms ### 8.1 Swarm Overview FRC-55 supports multi-agent orchestration through the swarm primitive. A swarm is a group of cooperating agents with a designated coordinator agent that receives incoming requests and routes them to the appropriate member agents. ``` User Request | v +-----------+-----------+ | SWARM COORDINATOR | | (FRC-55 Agent) | +-----------+-----------+ | +------------+-------------+ | | | v v v +-------+----+ +----+------+ +----+------+ | MEMBER A | | MEMBER B | | MEMBER C | | (Research) | | (Analysis)| | (Output) | +-------------+ +----------+ +-----------+ ``` ### 8.2 Swarm Structure ``` AgentSwarm { swarm_id: Hash256 // Deterministic ID = SHA3(owner + name + timestamp) name: String // Human-readable swarm name coordinator: Hash256 // Agent ID of the coordinator members: Vec // Agent IDs of all members (up to 20) routing_strategy: RoutingStrategy // How requests are routed created_at: u64 // Creation timestamp owner: Address // Swarm owner } ``` ### 8.3 Routing Strategies FRC-55 defines five routing strategies for swarm request distribution: ``` +-------------------+--------------------------------------------------+ | ROUND ROBIN | Requests distributed to members in sequence | | | | | Request 1 --> A | Simple, fair distribution | | Request 2 --> B | No intelligence about member capabilities | | Request 3 --> C | Best for homogeneous agent pools | | Request 4 --> A | | +-------------------+--------------------------------------------------+ | LOAD BALANCED | Requests sent to least-busy member | | | | | Check load --> | Monitors call counts and response times | | Route to min -->| Prevents overloading individual agents | | | Best for high-throughput applications | +-------------------+--------------------------------------------------+ | SPECIALIZED | Requests routed based on content/type | | | | | "Price?" --> A | Each member handles a specific domain | | "Code?" --> B | Coordinator classifies and routes | | "Legal?" --> C | Best for multi-domain assistants | +-------------------+--------------------------------------------------+ | CONSENSUS | All members process; majority vote on result | | | | | Request --> ALL | Higher reliability through redundancy | | Vote on result | Detects misbehaving or low-quality agents | | Majority wins | Best for high-stakes decisions | +-------------------+--------------------------------------------------+ | PIPELINE | Request flows through members in sequence | | | | | Input --> A | Each member adds to / refines the output | | --> B --> C | Natural for multi-stage processing | | --> Output | Best for research/analysis workflows | +-------------------+--------------------------------------------------+ ``` ### 8.4 Swarm Creation and Validation Creating a swarm requires: 1. All member agents must exist in the registry 2. The coordinator must be one of the members 3. The total number of members cannot exceed 20 4. The swarm ID is derived deterministically from owner + name + timestamp ``` create_swarm(owner, name, coordinator, members, strategy) -> swarm_id - Validates member count <= MAX_SWARM_MEMBERS (20) - Verifies coordinator agent exists - Verifies all member agents exist - Generates deterministic swarm_id - Stores swarm configuration - Returns swarm_id ``` ### 8.5 Swarm Invocation When a swarm is called via `call_swarm()`, the request is routed to the coordinator agent: ``` call_swarm(swarm_id, request) -> AgentCallResponse 1. Look up swarm by swarm_id 2. Retrieve coordinator agent ID 3. Route request to coordinator (call_agent) 4. Coordinator processes and potentially delegates to members 5. Return coordinator's response ``` The coordinator agent is responsible for implementing the routing strategy. It receives the original request and can invoke member agents as needed using the `CallOtherAgents` capability. This design keeps the routing logic flexible -- coordinators can implement custom routing that goes beyond the five built-in strategies. --- ## 9. Agent Economy ### 9.1 Economic Model Overview FRC-55 implements a complete agent economy where FRAC tokens flow between callers, agents, and agent owners. The economic model supports multiple pricing strategies, staking for quality assurance, slashing for misbehavior, and reputation tracking for trust. ``` +-------------------------------------------------------------------+ | FRC-55 AGENT ECONOMY | +-------------------------------------------------------------------+ | | | CALLER | | | | | | 1. Payment (FRAC) | | v | | +-------------------+ | | | Agent Call | | | | - price_per_call | --> Deducted from caller's balance | | | - price_per_token | --> (via StateDB.sub_balance) | | +--------+----------+ | | | | | | 2. Earnings credited | | v | | +-------------------+ | | | Agent Earnings | | | | (accumulated) | --> agent.total_earnings += payment | | +--------+----------+ | | | | | | 3. Claim | | v | | +-------------------+ | | | Owner Balance | | | | (via claim_ | --> StateDB.add_balance(owner, earnings) | | | earnings) | --> agent.total_earnings = 0 | | +-------------------+ | | | | STAKING SLASHING | | +-------------------+ +-------------------+ | | | stake_on_agent | | slash_agent | | | | - Locks FRAC | | - Reduces earnings| | | | - Quality signal | | - Records reason | | | | - sub_balance | | - Records slasher | | | +-------------------+ +-------------------+ | | | | REPUTATION | | +-------------------+ | | | rate_agent | | | | - Score: 0-1000 | | | | - Running average | | | | - Immutable hist. | | | +-------------------+ | +-------------------------------------------------------------------+ ``` ### 9.2 Pricing Configuration Each agent specifies a pricing configuration that determines how callers are charged: ``` PricingConfig { price_per_call: u128 // Fixed price per invocation (FRAC wei) price_per_token: u128 // Price per output token for LLM agents (FRAC wei) subscription_price: u128 // Monthly subscription price (FRAC wei) revenue_share_percent: u32 // % of revenue shared with model creator (0-100) free_calls_per_day: u32 // Number of free calls before payment required } ``` **Pricing models supported:** | Model | Description | Use Case | |-------|-------------|----------| | Per-call | Fixed fee per invocation | Simple agents, classifiers | | Per-token | Fee proportional to output length | LLM agents, generators | | Subscription | Monthly flat fee | High-frequency users | | Freemium | Free tier + paid premium | Agent discovery and adoption | | Revenue share | Creator receives % of all revenue | Open-source model incentives | ### 9.3 Payment Flow When a caller invokes an agent via `call_agent()`, the payment flow is: ``` 1. Caller submits AgentCallRequest with payment amount 2. Registry checks: payment >= agent.pricing.price_per_call 3. If insufficient: return InsufficientPayment error 4. If sufficient: StateDB.sub_balance(caller, price_per_call) 5. Agent earnings credited: agent.total_earnings += price_per_call 6. Agent call count incremented: agent.total_calls += 1 7. Global stats updated: total_calls++, total_revenue += price_per_call 8. Response returned to caller ``` All payments are denominated in FRAC wei (1 FRAC = 10^18 wei), enabling micropayments as small as 1 wei. This is essential for AI agent interactions where individual calls may cost fractions of a cent. ### 9.4 Earnings and Claims Agent earnings accumulate in the agent's on-chain state until the owner claims them: ``` claim_earnings(agent_id, owner) -> claimed_amount 1. Verify caller is agent owner 2. Read agent.total_earnings 3. Set agent.total_earnings = 0 4. StateDB.add_balance(owner, earnings) 5. Return claimed amount ``` This design separates the agent's earning account from the owner's personal balance, providing clear accounting and preventing accidental spending of accumulated earnings. ### 9.5 Staking Users can stake FRAC on agents they trust, signaling quality to other users: ``` stake_on_agent(agent_id, staker, amount) 1. Verify agent exists and is not destroyed 2. StateDB.sub_balance(staker, amount) 3. Record stake (associated with agent) ``` Staking serves multiple purposes: - **Quality signal**: Higher stake indicates greater community confidence - **Skin in the game**: Staked FRAC can be slashed if the agent misbehaves - **Economic alignment**: Stakers are incentivized to stake on high-quality agents - **Discovery**: Users can sort agents by total stake to find trusted agents ### 9.6 Slashing Agents that misbehave (return incorrect results, violate capability restrictions, exceed gas limits) can be slashed: ``` slash_agent(agent_id, reason, amount, slasher) 1. Find agent by ID 2. Record SlashRecord { timestamp, reason, amount, slasher } 3. Reduce agent earnings: agent.total_earnings -= min(amount, earnings) 4. Update agent timestamp ``` Slashing records are permanent and visible to all users. A `SlashRecord` contains: ``` SlashRecord { timestamp: u64 // When the slash occurred reason: String // Why the agent was slashed amount: u128 // FRAC amount slashed (wei) slasher: Address // Who initiated the slash } ``` ### 9.7 Reputation System FRC-55 implements a transparent reputation system based on on-chain ratings: ``` rate_agent(agent_id, rater, rating) -> new_average 1. Validate rating in range [0, 1000] 2. Add rating to sum: agent.rating_sum += rating 3. Increment count: agent.total_ratings += 1 4. Compute average: agent.rating = rating_sum / total_ratings 5. Return new average ``` **Rating scale:** | Score | Quality Level | |-------|--------------| | 900-1000 | Exceptional | | 700-899 | Good | | 500-699 | Adequate | | 300-499 | Below Average | | 0-299 | Poor | The reputation system is designed to be: - **Transparent**: All ratings are on-chain and verifiable - **Tamper-resistant**: Ratings cannot be modified after submission - **Simple**: Arithmetic mean prevents manipulation through extreme scores - **Useful**: Callers can filter agents by minimum rating before invocation ### 9.8 Registry Statistics The FRC-55 registry maintains aggregate statistics for the entire agent ecosystem: ``` RegistryStats { total_agents: u64 // Number of agents ever created total_swarms: u64 // Number of active swarms total_calls: u64 // Total agent invocations across all agents total_revenue: u128 // Total FRAC earned by all agents (wei) } ``` These statistics provide a high-level view of ecosystem health and are queryable via the JSON-RPC API. --- ## 10. Smart Tokens (FRC-55T) ### 10.1 Overview FRC-55T (Smart Tokens) extends the standard FRC-20 fungible token model with embedded AI agent capabilities. A Smart Token is a fully functional fungible token (with balances, transfers, approvals, minting, and burning) that also has an AI agent linked to it. This AI agent can autonomously manage the token's supply, execute governance decisions, rebalance treasury holdings, provide oracle data, and perform any other action within its declared capabilities. ``` +===================================================================+ | FRC-55T SMART TOKEN | +===================================================================+ | | | TOKEN LAYER (FRC-20 compatible) | | +-------------------+ +-------------------+ +---------------+ | | | Balances | | Allowances | | Supply Mgmt | | | | - per-address | | - approve() | | - mint() | | | | - get_balance() | | - transferFrom() | | - burn() | | | | - transfer() | | | | - max_supply | | | +-------------------+ +-------------------+ +---------------+ | | | | AI LAYER (FRC-55 powered) | | +-------------------+ +-------------------+ +---------------+ | | | AI Config | | Auto Actions | | Decisions | | | | - model_hash | | - action_id | | - timestamp | | | | - purpose | | - description | | - type | | | | - max_daily | | - enabled | | - reasoning | | | | - rate limiting | | | | - confidence | | | +-------------------+ +-------------------+ +---------------+ | | | | BEHAVIOR LAYER (programmable, up to 64 behaviors) | | +-------------------+ +-------------------+ +---------------+ | | | Triggers | | Actions | | History | | | | - PriceAbove | | - Mint | | - behavior_id | | | | - PriceBelow | | - Burn | | - timestamp | | | | - SupplyAbove | | - Transfer | | - trigger | | | | - SupplyBelow | | - AdjustFee | | - result | | | | - TimeInterval | | - Pause/Resume | | - success | | | | - HolderCountAbove| | - NotifyHolders | | | | | | - OnTransfer | | - CallAgent | | | | | | - Manual | | | | | | | +-------------------+ +-------------------+ +---------------+ | | | | BRIDGE LAYER | | +-------------------+ | | | Bridged Chains | | | | - chain_type | | | | - contract_addr | | | | - bridged_supply | | | +-------------------+ | +===================================================================+ ``` ### 10.2 Token Properties Each FRC-55T Smart Token has the following base properties: ``` SmartToken { token_id: Hash256 // SHA3(creator + name + symbol) name: String // e.g., "FractalGov" symbol: String // e.g., "FGOV" decimals: u8 // e.g., 18 total_supply: u128 // Current circulating supply max_supply: Option // Hard cap (None = uncapped) creator: Address // Token creator (has mint authority) created_at: u64 // Creation timestamp balances: Map allowances: Map<(Owner, Spender), u128> agent_id: Option // Linked FRC-55 agent ai_config: SmartTokenAI behaviors: Vec // Up to 64 programmable behaviors bridged_chains: Vec paused: bool } ``` ### 10.3 Token Purposes The AI agent embedded in a Smart Token can serve different purposes: | Purpose | Description | Typical Auto-Actions | |---------|-------------|---------------------| | `GovernanceAI` | Auto-execute governance votes | Tally votes, execute proposals, adjust parameters | | `TreasuryAI` | Manage treasury and reserves | Rebalance holdings, optimize yield, diversify | | `OracleAI` | Provide data feeds | Aggregate price data, validate sources, publish | | `RewardAI` | Distribute rewards dynamically | Calculate staking rewards, airdrops, bonuses | | `StableAI` | Price stabilization | Mint/burn to maintain peg, adjust collateral | | `Custom(String)` | User-defined purpose | Any custom automation | ### 10.4 Programmable Behaviors Smart Tokens can define up to 64 programmable behaviors, each consisting of a trigger condition and an action to execute when that condition is met. **Behavior Triggers:** | Trigger | Parameters | Description | |---------|-----------|-------------| | `PriceAbove(u128)` | Threshold price | Fires when token price exceeds threshold | | `PriceBelow(u128)` | Threshold price | Fires when token price drops below threshold | | `SupplyAbove(u128)` | Threshold supply | Fires when total supply exceeds threshold | | `SupplyBelow(u128)` | Threshold supply | Fires when total supply drops below threshold | | `TimeInterval(u64)` | Seconds | Fires periodically every N seconds | | `HolderCountAbove(u64)` | Count | Fires when holder count exceeds threshold | | `OnTransfer` | -- | Fires on every token transfer | | `Manual` | -- | Fires only when explicitly triggered | **Behavior Actions:** | Action | Parameters | Description | |--------|-----------|-------------| | `Mint` | amount, to | Mint new tokens to an address | | `Burn` | amount, from | Burn tokens from an address | | `Transfer` | amount, from, to | Move tokens between addresses | | `AdjustFee` | new_fee_percent | Change the transfer fee percentage | | `Pause` | -- | Pause all token operations | | `Resume` | -- | Resume token operations | | `NotifyHolders` | message | Send a notification to all holders | | `CallAgent` | agent_id, input | Invoke an FRC-55 agent | **Example behavior -- Automatic Supply Adjustment:** ``` TokenBehavior { behavior_id: "auto-stabilize" name: "Price Stabilization" trigger: PriceBelow(1_000_000_000_000_000_000) // Below 1 FRAC action: Burn { amount: 10000, from: "treasury" } enabled: true } ``` ### 10.5 AI Decision History Every AI-driven decision made by a Smart Token is recorded: ``` AIDecision { timestamp: u64 // When the decision was made decision_type: String // e.g., "supply_adjustment", "rebalance" reasoning: String // AI's reasoning for the decision action_taken: String // What action was executed confidence: u32 // Confidence level (0-1000) } ``` This provides a complete audit trail of autonomous actions, enabling holders to understand and verify the AI's behavior over time. ### 10.6 Rate Limiting To prevent runaway AI behavior, Smart Tokens enforce rate limits: ``` SmartTokenAI { max_daily_actions: u32 // Maximum AI actions per day actions_today: u32 // Counter for current day last_action_day: u64 // Day counter (timestamp / 86400) } ``` When `actions_today >= max_daily_actions`, no further AI-initiated actions are permitted until the day counter rolls over. This provides a hard safety limit against AI agents that might otherwise execute an unlimited number of actions. ### 10.7 FRC-20 Compatibility FRC-55T tokens are fully compatible with the FRC-20 standard. They support: - `transfer(token_id, from, to, amount)` -- Direct token transfer - `approve(token_id, owner, spender, amount)` -- Approve spending allowance - `transfer_from(token_id, spender, from, to, amount)` -- Delegated transfer - `mint(token_id, creator, to, amount)` -- Mint new tokens (creator only) - `burn(token_id, owner, amount)` -- Burn tokens (holder can burn own tokens) - `get_balance(token_id, owner)` -- Query balance All operations respect: - Max supply caps (minting reverts if new supply would exceed max) - Pause state (all operations revert when paused) - Balance sufficiency (transfers revert on insufficient balance) - Allowance limits (transferFrom reverts on insufficient allowance) --- ## 11. Smart NFTs (FRC-55N) ### 11.1 Overview FRC-55N (Smart NFTs) extends standard non-fungible tokens with embedded AI agent capabilities. Unlike traditional NFTs that are static digital collectibles, Smart NFTs are dynamic entities that evolve over time, interact with their owners through conversation, gain experience points, level up, generate content, and execute tasks autonomously. ``` +===================================================================+ | FRC-55N SMART NFT | +===================================================================+ | | | IDENTITY | | +-------------------+ +-------------------+ +---------------+ | | | Core | | Ownership | | Collection | | | | - nft_id (Hash256)| | - owner (Address) | | - collection_ | | | | - name | | - creator (Addr) | | id | | | | - description | | - transferable | | - max_supply | | | | - created_at | | | | - minted | | | +-------------------+ +-------------------+ +---------------+ | | | | DYNAMIC METADATA | | +-----------------------------------------------------------+ | | | - image_uri (can change on evolution) | | | | - animation_uri (optional video/3D content) | | | | - external_url (link to more information) | | | | - attributes (key-value pairs, dynamically updated) | | | | - ai_generated (whether content is AI-created) | | | | - generation_prompt (the prompt used for AI generation) | | | | - evolution_level (current evolution stage) | | | | - last_interaction (timestamp of last owner interaction) | | | +-----------------------------------------------------------+ | | | | AI PERSONALITY | | +-----------------------------------------------------------+ | | | - personality (text description of AI behavior) | | | | - capabilities (Chat, GenerateArt, GenerateText, | | | | ExecuteTasks, ManagePortfolio, | | | | Evolve, Breed, CrossChainTravel) | | | | - interaction_count (total conversations/interactions) | | | | - xp (experience points earned) | | | | - level (current level based on XP) | | | | - evolution_thresholds (XP needed for each level) | | | +-----------------------------------------------------------+ | | | | LICENSING | | +-----------------------------------------------------------+ | | | - license_type (FullOwnership, UsageOnly, TimeLimited, | | | | SubscriptionBased, OpenSource) | | | | - commercial_use (bool) | | | | - derivative_works (bool) | | | | - royalty_percent (0-100, on resale) | | | | - expiry (optional timestamp) | | | +-----------------------------------------------------------+ | | | | METADATA HISTORY (full audit trail) | | +-----------------------------------------------------------+ | | | [timestamp, field, old_value, new_value, reason] | | | | [timestamp, field, old_value, new_value, reason] | | | | ... | | | +-----------------------------------------------------------+ | +===================================================================+ ``` ### 11.2 NFT Capabilities Each Smart NFT can possess a subset of eight capabilities: | Capability | Description | |-----------|-------------| | `Chat` | Can converse with the owner in natural language | | `GenerateArt` | Can create new images and visual content | | `GenerateText` | Can produce written content (stories, poems, reports) | | `ExecuteTasks` | Can perform RPA workflows on behalf of the owner | | `ManagePortfolio` | Can manage the owner's token holdings | | `Evolve` | Can change its own metadata and appearance | | `Breed` | Can create child NFTs with inherited traits | | `CrossChainTravel` | Can be bridged to other blockchains | ### 11.3 Experience and Evolution System Smart NFTs gain experience through owner interactions and can evolve to higher levels: ``` EVOLUTION SYSTEM Level 0 (Base) | | Gain XP through interactions (10 XP per interaction) | v (XP >= threshold[0]) Level 1 (Awakened) | | Continue gaining XP | v (XP >= threshold[1]) Level 2 (Evolved) | | Continue gaining XP | v (XP >= threshold[2]) Level 3 (Ascended) | ... ``` **XP Mechanics:** - Each interaction with the NFT's AI grants `BASE_INTERACTION_XP = 10` experience points - Evolution thresholds are defined per-NFT at creation (e.g., [50, 150, 300, 500]) - When XP exceeds the threshold for the current level, the NFT automatically evolves - Evolution increments the level, updates `evolution_level` in metadata, and records the change in `metadata_history` **Example evolution timeline:** ``` Interactions: 0 5 10 15 20 25 30 XP: 0 50 100 150 200 250 300 Level: 0 1 1 2 2 2 3 ^ ^ ^ | | | Evolve to Evolve to Evolve to Level 1 Level 2 Level 3 ``` ### 11.4 Owner Interaction Smart NFTs support direct interaction through the `interact_with_nft()` function: ``` interact_with_nft(nft_id, caller, input) -> NFTInteractionResult 1. Verify caller is the NFT owner 2. Check AI features are enabled 3. Increment interaction_count 4. Grant BASE_INTERACTION_XP (10 XP) 5. Check if XP exceeds evolution threshold - If yes: increment level, update metadata, record history 6. Generate response based on personality and capabilities 7. Return NFTInteractionResult { response: "[personality] Processed: input (interaction #N, level L, XP X)", xp_gained: 10, evolved: true/false, metadata_changed: true/false } ``` **Only the current owner can interact with a Smart NFT's AI.** This ensures that the NFT's personality develops in response to its owner's specific interactions, creating a unique and personal relationship between owner and NFT. ### 11.5 Dynamic Metadata Unlike traditional NFTs where metadata is immutable once minted, FRC-55N metadata can change: ``` NFTMetadata { image_uri: String // Can update on evolution animation_uri: Option // Can update on evolution external_url: Option // Can update attributes: HashMap // Dynamically updated ai_generated: bool // Provenance flag generation_prompt: Option // Original prompt evolution_level: u32 // Updated on evolution last_interaction: u64 // Updated on interaction } ``` All metadata changes are recorded in `metadata_history`: ``` MetadataUpdate { timestamp: u64 // When the change occurred field: String // Which field was changed old_value: String // Previous value new_value: String // New value reason: String // Why the change was made } ``` This provides a complete, auditable history of how the NFT has changed over time. ### 11.6 NFT Licensing FRC-55N includes a built-in licensing framework: | License Type | Description | |-------------|-------------| | `FullOwnership` | Complete intellectual property transfer to the buyer | | `UsageOnly` | Right to display and use, but IP remains with creator | | `TimeLimited` | License expires at a specified timestamp | | `SubscriptionBased` | Recurring payment required to maintain access | | `OpenSource` | Public domain / open for all uses | Additional licensing parameters: - `commercial_use: bool` -- Whether the NFT can be used commercially - `derivative_works: bool` -- Whether derivative works are permitted - `royalty_percent: u32` -- Percentage of resale price paid to creator (0-100) - `expiry: Option` -- Optional timestamp when the license expires ### 11.7 NFT Collections Smart NFTs are organized into collections: ``` NFTCollection { collection_id: Hash256 // SHA3(creator + name) name: String // e.g., "Fractal Phoenixes" description: String // Collection description creator: Address // Collection creator max_supply: Option // Maximum NFTs in collection (None = unlimited) minted: u64 // NFTs minted so far floor_price: u128 // Floor price in FRAC wei nft_ids: Vec // All NFT IDs in this collection created_at: u64 // Creation timestamp } ``` Collections enforce: - Only the creator can mint new NFTs in the collection - Minting respects `max_supply` (returns `CollectionFull` if exceeded) - Each minted NFT is tracked in the collection's `nft_ids` list ### 11.8 Soulbound NFTs FRC-55N supports non-transferable (soulbound) NFTs through the `transferable` flag: ``` SmartNFT { ... transferable: bool // If false, transfer_nft() will revert ... } ``` Soulbound NFTs are useful for: - **Identity badges**: Proving completion of a course, membership in a group - **Achievement NFTs**: Recording accomplishments that should not be tradeable - **Credential NFTs**: Professional certifications tied to a specific address - **Personal AI companions**: NFTs that develop a unique relationship with one owner --- ## 12. Cross-Chain Bridge ### 12.1 Overview The FRC-55 Cross-Chain Bridge Protocol enables FractalAI agents, tokens, and NFTs to operate across multiple blockchain ecosystems. The bridge supports eight chains at launch, with an extensible architecture for adding new chains through governance. ``` +===================================================================+ | CROSS-CHAIN BRIDGE PROTOCOL | +===================================================================+ | | | +---------------------+ | | | FractalAI Chain | | | | (Home Chain) | | | | - FRAC native token | | | | - FRC-55 agents | | | | - FRC-55T tokens | | | | - FRC-55N NFTs | | | +----------+----------+ | | | | | +----------------+-------------------+ | | | | | | | +--------v--------+ +----v---------+ +--------v--------+ | | | Token Bridge | | Agent Bridge | | NFT Bridge | | | | (0.1% fee) | | (proxy | | (full state | | | | FRAC + FRC-20 | | deployment) | | transfer) | | | +--------+--------+ +----+---------+ +--------+--------+ | | | | | | | +-------+--------+--------+----------+ | | | | | | +----------v-----------+ +--v--------------------+ | | | N-of-M Multisig | | Validator Signatures | | | | Validator Security | | - Post-quantum signed | | | | (default: 2-of-3) | | - Duplicate rejected | | | +----------+-----------+ +--+--------------------+ | | | | | | +-----------+-----+------+-----+----+----+-----+-----------+ | | | | | | | | | | v v v v v v | | +------+ +--------+ +---------+ +----------+ +------+ +------+ | | | ETH | | BNB | | Polygon | | Arbitrum | | Base | | SOL | | | | (1) | | (56) | | (137) | | (42161) | |(8453)| | (0) | | | | 12 | | 15 | | 64 | | 12 | | 12 | | 32 | | | | conf | | conf | | conf | | conf | | conf | | conf | | | +------+ +--------+ +---------+ +----------+ +------+ +------+ | | | +===================================================================+ ``` ### 12.2 Supported Chains The bridge launches with six pre-configured chains: | Chain | Chain ID | Confirmations | Supported Assets | |-------|----------|--------------|------------------| | Ethereum Mainnet | 1 | 12 | FRAC, FRC-20, Agents, NFTs | | BNB Smart Chain | 56 | 15 | FRAC, FRC-20 | | Polygon PoS | 137 | 64 | FRAC, FRC-20 | | Arbitrum One | 42161 | 12 | FRAC, FRC-20 | | Base | 8453 | 12 | FRAC, FRC-20 | | Solana | 0 (N/A) | 32 | FRAC | Additional chains can be registered through the `register_chain()` function, and existing chains can be disabled via `disable_chain()`. ### 12.3 Bridge Fee Structure All token bridge transactions incur a flat 0.1% fee: ``` Fee = amount * 1 / 1000 (BRIDGE_FEE_NUMERATOR / BRIDGE_FEE_DENOMINATOR) Net amount = amount - fee ``` **Amount limits:** | Parameter | Value | In FRAC | |-----------|-------|---------| | Minimum bridge amount | 1,000,000,000,000,000,000 wei | 1 FRAC | | Maximum bridge amount | 10,000,000,000,000,000,000,000,000 wei | 10,000,000 FRAC | These limits protect against dust attacks (minimum) and single-point-of-failure risk (maximum). ### 12.4 Token Bridging **Outbound (FractalAI to other chain):** ``` bridge_tokens(sender, dest_chain, recipient, amount) -> tx_id 1. Validate dest_chain is supported and enabled 2. Validate recipient address is non-empty 3. Validate amount is within [MIN_BRIDGE_AMOUNT, MAX_BRIDGE_AMOUNT] 4. Calculate fee = amount * 0.1% 5. Calculate net_amount = amount - fee 6. Create BridgeTransaction { source: FractalAI dest: dest_chain asset: NativeToken amount: net_amount status: Pending } 7. Add to pending queue 8. Update bridge stats 9. Return tx_id ``` **FRC-20 Token bridging follows the same flow** via `bridge_frc20()`, with the addition of a token contract identifier. ### 12.5 Agent Cross-Chain Deployment FRC-55 agents can be deployed as proxies on other chains: ``` deploy_agent_cross_chain(agent_id, owner, dest_chain) -> deployment_id 1. Verify dest_chain is supported and enabled 2. Check agent not already deployed on dest_chain 3. Generate deployment_id = SHA3(agent_id + dest_chain + timestamp) 4. Create CrossChainAgentDeployment { status: Pending dest_contract: "0x_proxy_" } 5. Create bridge transaction carrying serialized deployment data 6. Store deployment record 7. Return deployment_id ``` **Deployment lifecycle:** ``` Pending --> Deployed --> Active --> Suspended --> Removed | v (accepts cross-chain calls) ``` ### 12.6 Cross-Chain Agent Calls Once an agent is deployed on another chain, users on that chain can invoke it: ``` call_agent_cross_chain(CrossChainCall) -> call_id CrossChainCall { call_id: Hash256 source_chain: CrossChainType // Where the call originates dest_chain: CrossChainType // Where the agent lives agent_id: Hash256 // Target agent caller: String // Caller address on source chain input: String // Call input payment: u128 // FRAC payment callback_chain: CrossChainType // Where to deliver the response callback_address: String // Response recipient status: CrossChainCallStatus response: Option // Filled in on completion timestamp: u64 } ``` **Call status lifecycle:** ``` Submitted --> Bridging --> Executing --> Completed \--> Failed(reason) ``` ### 12.7 NFT Bridging Smart NFTs can be bridged to other chains: ``` bridge_smart_nft(nft_id, owner, dest_chain, recipient) -> tx_id 1. Verify dest_chain is supported and enabled 2. Validate recipient address 3. Serialize NFT ID as bridge payload 4. Create bridge transaction with AssetType::SmartNFT 5. Store transaction and add to pending queue 6. Return tx_id ``` On the destination chain, a proxy NFT contract is deployed that mirrors the NFT's state (metadata, AI capabilities, evolution level). Cross-chain interactions are relayed through the bridge protocol. ### 12.8 Validator Security Model Bridge transactions are secured by an N-of-M multisig validator set: ``` Default: 2-of-3 multisig (two validator signatures required out of three) Bridge Transaction Lifecycle: 1. Pending (created, awaiting signatures) 2. ValidatorsSigning (at least one signature, not yet threshold) 3. ReadyToExecute (threshold signatures reached) 4. Executed (finalized on destination chain) 5. Failed(reason) (execution failed, can be retried or refunded) 6. Refunded (funds returned to sender after failure) ``` **Signature validation:** ``` add_validator_signature(tx_id, validator, signature) -> Result 1. Find transaction by tx_id 2. Reject if validator already signed (no duplicates) 3. Append ValidatorSignature { validator, signature, timestamp } 4. If signatures.len() >= required_signatures: Update status to ReadyToExecute 5. Else: Update status to ValidatorsSigning ``` **Execution:** ``` execute_bridge_tx(tx_id) -> Result 1. Find transaction by tx_id 2. Verify sufficient signatures (>= required) 3. Set status to Executed 4. Generate destination transaction hash 5. Remove from pending queue ``` ### 12.9 Bridge Statistics The bridge maintains aggregate statistics: ``` CrossChainBridgeStats { total_bridged_volume: u128 // Total FRAC volume bridged total_bridge_txs: u64 // Total bridge transactions pending_txs: usize // Currently pending transactions supported_chains: usize // Number of supported chains active_agent_deployments: usize // Agents deployed cross-chain total_cross_chain_calls: u64 // Cross-chain agent invocations } ``` --- ## 13. Security Model ### 13.1 Security Overview FRC-55 inherits the post-quantum security properties of the FractalAI blockchain and adds application-level security controls specific to AI agent operations. ``` +===================================================================+ | FRC-55 SECURITY LAYERS | +===================================================================+ | | | LAYER 1: POST-QUANTUM CRYPTOGRAPHY | | +-----------------------------------------------------------+ | | | - CRYSTALS-Dilithium2 for all signatures (1312B/2420B) | | | | - CRYSTALS-Kyber768 for all encryption (1184B/1088B) | | | | - SHA3-256 for all hashing (128-bit PQ security) | | | | - Resistant to Shor's algorithm and Grover's algorithm | | | +-----------------------------------------------------------+ | | | | LAYER 2: OWNERSHIP AND AUTHORIZATION | | +-----------------------------------------------------------+ | | | - Only owner can modify agent state | | | | - Owner verified via Dilithium signature on every TX | | | | - Destroyed agents are immutable (terminal state) | | | | - Version counter prevents replay of old configurations | | | +-----------------------------------------------------------+ | | | | LAYER 3: ACCESS CONTROL | | +-----------------------------------------------------------+ | | | - allowed_callers whitelist (empty = open access) | | | | - Capability restrictions enforced at VM level | | | | - Per-agent gas limits (max_gas_per_call) | | | | - Per-token rate limiting (max_daily_actions) | | | +-----------------------------------------------------------+ | | | | LAYER 4: ECONOMIC SECURITY | | +-----------------------------------------------------------+ | | | - Payment required before execution (no free-riding) | | | | - Staking creates economic alignment | | | | - Slashing penalizes misbehavior | | | | - Reputation provides transparent quality signal | | | +-----------------------------------------------------------+ | | | | LAYER 5: RESOURCE LIMITS | | +-----------------------------------------------------------+ | | | - MAX_AGENTS_PER_OWNER: 50 | | | | - MAX_MCP_SERVERS: 20 per agent | | | | - MAX_KNOWLEDGE_BASES: 50 per agent | | | | - MAX_WORKFLOWS: 100 per agent | | | | - MAX_SWARM_MEMBERS: 20 per swarm | | | | - MAX_BEHAVIORS: 64 per token | | | +-----------------------------------------------------------+ | | | | LAYER 6: BRIDGE SECURITY | | +-----------------------------------------------------------+ | | | - N-of-M multisig validator set (default: 2-of-3) | | | | - Duplicate signature rejection | | | | - Min/max bridge amount bounds | | | | - Per-chain confirmation requirements | | | | - Chain enable/disable controls | | | +-----------------------------------------------------------+ | +===================================================================+ ``` ### 13.2 Agent Access Control FRC-55 provides granular access control for agent invocations: **Caller Whitelisting:** ``` allowed_callers: Vec
If empty: any address can call the agent (open access) If non-empty: only listed addresses can call the agent Enforcement in call_agent(): if !agent.allowed_callers.is_empty() && !agent.allowed_callers.contains(&request.caller) { return Err(Unauthorized); } ``` This allows agents to restrict access to trusted callers, which is essential for: - Private enterprise agents that should only respond to authorized employees - Pipeline agents that should only be called by their coordinator - High-value agents that require pre-approval before invocation **Gas Limits:** Each agent specifies a `max_gas_per_call` that caps the computational resources any single invocation can consume. This prevents: - Denial-of-service through gas-expensive queries - Unbounded execution that could slow the network - Cost overruns from unexpectedly complex inputs ### 13.3 Economic Security Mechanisms **Payment-Before-Execution:** All agent calls require upfront payment. The FRAC payment is deducted from the caller's balance via `StateDB.sub_balance()` before the agent processes the request. If the caller has insufficient balance, the call is rejected. This ensures: - Agents are always compensated for their work - Callers cannot consume agent resources without paying - The network is protected from spam through economic friction **Slashing:** When an agent produces incorrect results, violates its declared capabilities, or otherwise misbehaves, it can be slashed. The slashing mechanism: - Deducts from the agent's accumulated earnings - Records a permanent `SlashRecord` with timestamp, reason, amount, and slasher - Provides a public record of the agent's misbehavior history **Reputation Anchoring:** The on-chain rating system (0-1000 scale) provides a transparent, manipulation-resistant quality signal. Key properties: - Ratings are permanent and cannot be deleted - The average is computed as a simple arithmetic mean - High rating count provides statistical confidence - Low ratings are visible to all potential callers ### 13.4 Bridge Security The cross-chain bridge implements multiple security measures: **Multisig Validation:** Every bridge transaction requires N-of-M validator signatures before execution. The default threshold is 2-of-3, meaning any two validators must sign before the transaction is processed. This prevents: - Single validator compromise from enabling fraudulent bridges - Collusion (requires compromising multiple independent validators) - Unauthorized execution of bridge transactions **Amount Bounds:** ``` MIN_BRIDGE_AMOUNT: 1 FRAC (prevents dust attacks) MAX_BRIDGE_AMOUNT: 10M FRAC (limits exposure per transaction) ``` **Confirmation Requirements:** Each chain has a configurable number of block confirmations required before a bridge transaction is considered final. Higher confirmation counts provide greater finality guarantees: | Chain | Confirmations | Approximate Time | |-------|--------------|------------------| | Ethereum | 12 | ~2.4 minutes | | BNB Chain | 15 | ~45 seconds | | Polygon | 64 | ~2.1 minutes | | Arbitrum | 12 | ~2.4 minutes | | Base | 12 | ~24 seconds | | Solana | 32 | ~12.8 seconds | ### 13.5 Threat Analysis | Threat | Mitigation | |--------|-----------| | Agent impersonation | Dilithium signatures on all agent registrations and responses | | Knowledge base tampering | SHA3-256 data_hash provides integrity verification | | Unauthorized agent modification | Owner-only access control with signature verification | | Runaway AI behavior | Rate limits (max_daily_actions), gas limits, pause capability | | Economic attacks (spam calls) | Payment-before-execution, minimum prices | | Bridge fund theft | N-of-M multisig, amount bounds, confirmation requirements | | Replay attacks | Nonce-based transaction ordering, monotonic version counters | | Sybil attacks on reputation | Future: require minimum stake to rate agents | | Quantum attacks | Dilithium/Kyber at every protocol level (NIST Level 2-3) | --- ## 14. Comparison with Existing Platforms ### 14.1 Feature Comparison Matrix ``` +==============================================================================+ | FRC-55 vs. EXISTING AI AGENT PLATFORMS | +==============================================================================+ | | | Feature | FractalAI | Autonolas | Fetch.ai | Singular-| Virtuals| | | (FRC-55) | (OLAS) | (FET) | ityNET |Protocol | |----------------------+------------+-----------+----------+----------+---------| | Native L1 Blockchain | YES | No (ETH) | YES | No (ETH/ | No | | | | | (Cosmos) | Cardano) | (Base) | |----------------------+------------+-----------+----------+----------+---------| | On-Chain Agent | YES | YES | Partial | YES | YES | | Registry | (FRC-55 | (NFT- | (DID- | (service | (token- | | | Registry) | based) | based) | registry| based) | |----------------------+------------+-----------+----------+----------+---------| | MCP Integration | NATIVE | No | No | No | No | | | (20 svrs/ | | | | | | | agent) | | | | | |----------------------+------------+-----------+----------+----------+---------| | RAG Support | NATIVE | No | No | No | No | | | (50 KBs/ | | | | | | | agent) | | | | | |----------------------+------------+-----------+----------+----------+---------| | RPA Workflows | NATIVE | No | Partial | No | No | | | (100 wfs/ | | (basic | | | | | agent) | | tasks) | | | |----------------------+------------+-----------+----------+----------+---------| | Agent Swarms | YES | Partial | YES | No | No | | | (5 routing | (multi- | (agent | | | | | strategies| agent | econmy) | | | | | 20 max) | services)| | | | |----------------------+------------+-----------+----------+----------+---------| | Smart Tokens | YES | No | No | No | Partial | | (FRC-55T) | (AI-driven | | | | (agent | | | behaviors)| | | | tokens)| |----------------------+------------+-----------+----------+----------+---------| | Smart NFTs | YES | No | No | No | Partial | | (FRC-55N) | (evolving, | | | | (static | | | XP, chat) | | | | NFTs) | |----------------------+------------+-----------+----------+----------+---------| | Cross-Chain Bridge | YES | Partial | No | YES | No | | | (8 chains, | (ETH | | (ETH/ | | | | multisig) | bridges) | | Cardano)| | |----------------------+------------+-----------+----------+----------+---------| | Post-Quantum Crypto | YES | No | No | No | No | | | (Dilithium,| (ECDSA) | (ECDSA) | (ECDSA) | (ECDSA) | | | Kyber) | | | | | |----------------------+------------+-----------+----------+----------+---------| | Native Token | FRAC | OLAS | FET | AGIX | VIRTUAL | | | (1B supply,| (ETH L1) | (Cosmos | (ETH/ | (Base | | | 18 dec) | | native) | Cardano)| L2) | |----------------------+------------+-----------+----------+----------+---------| | Agent Payment Model | Per-call, | Staking | Per- | Per-call | Token | | | per-token, | | message | | bonding | | | subscript.,| | | | curve | | | freemium | | | | | |----------------------+------------+-----------+----------+----------+---------| | Staking / Slashing | YES / YES | YES / No | YES / No | No / No | No / No | |----------------------+------------+-----------+----------+----------+---------| | On-Chain Reputation | YES | Partial | No | YES | Partial | | | (0-1000 | | | (rating | (holder | | | scale) | | | system) | count) | |----------------------+------------+-----------+----------+----------+---------| | AI Execution Model | Off-chain | Off-chain | Off-chain| Off-chain| Off-chain| | | + FractalVM| (services)| (agents) |(services)| (API) | | | (WASM) | | | | | |----------------------+------------+-----------+----------+----------+---------| | Consensus | PoFW | ETH PoS | Tendermnt| ETH PoS | ETH | | | (fractal) | (Casper) | (BFT) | (Casper) | PoS | |----------------------+------------+-----------+----------+----------+---------| | VM | FractalVM | EVM | CosmWasm | EVM / | EVM | | | (WASM + | | | Plutus | | | | AI ops) | | | | | +==============================================================================+ ``` ### 14.2 Key Differentiators **FRC-55 vs. Autonolas (OLAS):** Autonolas provides a robust multi-agent service framework but operates on Ethereum L1 with high gas costs and no native AI infrastructure. FRC-55 runs on a purpose-built L1 with sub-cent transaction costs, native MCP/RAG/RPA support, and post-quantum cryptography. Autonolas agents are NFT-based; FRC-55 agents are first-class protocol primitives with rich on-chain state. **FRC-55 vs. Fetch.ai (FET):** Fetch.ai has its own L1 chain (Cosmos-based) with a multi-agent economy, but lacks MCP standardization, RAG support, and smart asset extensions. FRC-55 provides a more comprehensive agent standard with programmable behaviors, cross-chain deployment, and AI-enhanced tokens and NFTs that Fetch.ai does not offer. **FRC-55 vs. SingularityNET (AGIX):** SingularityNET focuses on a marketplace model where AI services are listed and consumed. FRC-55 goes beyond marketplace to provide full agent autonomy with RPA workflows, event-driven triggers, and swarm coordination. SingularityNET agents are passive services; FRC-55 agents are active participants that can initiate transactions, manage assets, and collaborate autonomously. **FRC-55 vs. Virtuals Protocol (VIRTUAL):** Virtuals focuses on agent tokenization for entertainment and social media use cases. FRC-55 provides a general-purpose agent standard suitable for enterprise, DeFi, governance, and any other domain. FRC-55T Smart Tokens offer AI-driven behaviors far beyond Virtuals' bonding curve token model, and FRC-55N Smart NFTs provide evolution, XP, and licensing that Virtuals' static NFTs lack. ### 14.3 Unique Capabilities The following capabilities are unique to FRC-55 and not available on any existing platform: 1. **Unified MCP + RAG + RPA**: No other blockchain agent standard integrates all three AI infrastructure patterns into a single composable framework 2. **Post-quantum agent security**: FRC-55 is the only agent standard built on post-quantum cryptography, ensuring long-term security against quantum attacks 3. **Smart Tokens with AI behaviors**: Programmable token behaviors (up to 64 per token) driven by AI agents are unique to FRC-55T 4. **Evolving NFTs with XP system**: FRC-55N's experience points, leveling, and evolution system creates a genuinely dynamic NFT experience not available elsewhere 5. **Cross-chain agent deployment**: The ability to deploy an FRC-55 agent as a proxy on eight different chains through a single bridge protocol is unique 6. **Golden ratio integration**: phi-based mathematics throughout the system (reward multipliers, reputation weighting, scheduling) provides mathematically optimal balance properties --- ## 15. Tokenomics Integration ### 15.1 FRAC Token in the Agent Ecosystem The FRAC token serves as the universal medium of exchange within the FRC-55 ecosystem: ``` +===================================================================+ | FRAC FLOW IN FRC-55 ECOSYSTEM | +===================================================================+ | | | USERS / CALLERS | | | | | | Pay for agent calls (price_per_call, price_per_token) | | | Pay for subscriptions (subscription_price) | | | Pay bridge fees (0.1%) | | | Stake on agents (quality signal) | | | Rate agents (reputation) | | | | | v | | FRC-55 AGENTS | | | | | | Accumulate earnings (total_earnings) | | | Pay for tool use (MCP gas costs) | | | Pay for cross-chain calls | | | Revenue share to model creators | | | | | v | | AGENT OWNERS | | | | | | Claim earnings (claim_earnings) | | | Pay for agent creation (gas) | | | Pay for knowledge base updates (gas) | | | Pay for workflow deployments (gas) | | | | | v | | VALIDATORS | | | | | | Earn block rewards (PoFW mining) | | | Earn bridge validation fees | | | Earn transaction gas fees | | | Slashing penalties for misbehavior | | | | | v | | ECOSYSTEM | | | | | | FRC-55T token creation and trading | | | FRC-55N NFT minting and royalties | | | Cross-chain bridge volume | | | Swarm coordination fees | | | +===================================================================+ ``` ### 15.2 FRAC Token Parameters | Parameter | Value | |-----------|-------| | Token name | FRAC | | Total supply | 1,000,000,000 (1 billion) | | Decimals | 18 | | Minimum unit | 1 wei (10^-18 FRAC) | | Consensus | Proof of Fractal Work (PoFW) | | Block time | 3,000 ms (adaptive: 1,146 - 4,854 ms) | | Staking multiplier | phi = 1.618x | | Minimum stake | 10,000 FRAC | ### 15.3 Agent Economy Revenue Flows **Agent Call Revenue:** ``` Caller pays: 1000 FRAC wei per call Agent receives: 1000 FRAC wei (credited to total_earnings) Owner claims: 1000 FRAC wei (transferred to owner balance) Model creator share: 100 FRAC wei (10% revenue_share_percent) Net to owner: 900 FRAC wei ``` **Bridge Revenue:** ``` Bridge amount: 100 FRAC Bridge fee (0.1%): 0.1 FRAC Fee distribution: Validators (bridge operators) Net bridged: 99.9 FRAC ``` **Smart Token Revenue:** ``` Token creation: Gas fees (to validators) Token transfers: Gas fees (to validators) AI actions: Gas fees (to validators) Behavior execution: Gas fees (to validators) ``` **Smart NFT Revenue:** ``` Collection creation: Gas fees (to validators) NFT minting: Gas fees (to validators) NFT transfers: Gas fees + royalty_percent (to creator) AI interactions: Gas fees (to validators) Metadata updates: Gas fees (to validators) ``` ### 15.4 Golden Ratio in Token Distribution Consistent with the FractalAI tokenomics model, the allocation follows golden ratio proportions: | Allocation | Percentage | Amount (FRAC) | |-----------|-----------|---------------| | Mining rewards | 38.2% (1/phi^2) | 382,000,000 | | Ecosystem development | 23.6% | 236,000,000 | | Foundation | 14.6% | 146,000,000 | | Early contributors | 9.0% | 90,000,000 | | Community | 14.6% | 146,000,000 | The ecosystem development allocation is specifically earmarked for: - Agent developer grants and bounties - Knowledge base creation incentives - Cross-chain bridge liquidity - Smart asset ecosystem growth ### 15.5 Deflationary Mechanisms Several mechanisms create deflationary pressure on FRAC within the agent ecosystem: 1. **Gas consumption**: All agent operations consume gas, removing FRAC from circulation 2. **Bridge fees**: 0.1% of all bridged amounts is collected as fees 3. **Slashing**: Slashed amounts are effectively removed from agent earnings 4. **Staking lockup**: Staked FRAC is locked and removed from circulating supply 5. **Smart Token burns**: FRC-55T tokens can define burn behaviors that reduce supply ### 15.6 Inflationary Mechanisms Balancing the deflationary pressure: 1. **Block rewards**: Validators receive FRAC for mining new blocks 2. **Agent earnings claims**: Claimed earnings enter circulation 3. **Smart Token minting**: FRC-55T tokens can define mint behaviors The net effect is designed to achieve a stable, sustainable token economy where FRAC circulates efficiently through the agent ecosystem while maintaining long-term value. --- ## 16. Future Work ### 16.1 Zero-Knowledge Proofs of Inference (zkML) The current FRC-55 implementation relies on signed responses and model hashes for agent verification. Future versions will integrate zero-knowledge machine learning (zkML) to provide trustless verification that an agent actually ran a specific model on a specific input to produce a specific output, without revealing the model weights or the computation. **Planned approach:** - Use zkSNARK circuits optimized for neural network inference - Generate proofs that output Y was produced by model M on input X - Verify proofs on-chain at minimal gas cost - Enable fully trustless agent-to-agent interaction ### 16.2 Decentralized Agent Execution Currently, agent inference happens off-chain on the operator's infrastructure. Future versions will support decentralized execution through: - **FractalVM WASM execution**: Running quantized models directly in the VM - **Distributed inference**: Splitting model execution across multiple nodes - **Verifiable compute markets**: Matching agent execution requests with compute providers - **TEE integration**: Using trusted execution environments for confidential inference ### 16.3 Advanced Swarm Coordination Future swarm improvements: - **Dynamic member addition/removal** without recreating the swarm - **Weighted routing** based on agent reputation and performance - **Hierarchical swarms** (swarms of swarms for complex pipelines) - **Consensus verification** with on-chain proof that majority agreed - **Economic incentives** for swarm participation (automatic revenue splitting) ### 16.4 Enhanced RAG Capabilities - **On-chain vector storage** for small, high-value knowledge bases - **Cross-agent knowledge sharing** with attribution and payment - **Temporal knowledge bases** that track how information changes over time - **Multi-modal knowledge** (images, audio, video, not just text) - **Federated knowledge** aggregated from multiple agents without data sharing ### 16.5 Governance Integration - **DAO-governed agent parameters** (limits, fees, slashing conditions) - **Community curation** of agent directories and categories - **Dispute resolution** for slashing events - **Standard evolution** through FRC improvement proposals ### 16.6 Advanced Smart Asset Capabilities **FRC-55T:** - **AI-driven market making** with autonomous liquidity provision - **Cross-token behaviors** (one token's behavior triggers another's) - **Programmable dividends** based on treasury performance - **Automatic governance execution** from vote tallying to parameter changes **FRC-55N:** - **Breeding mechanics** for creating child NFTs with inherited traits - **Multi-owner interactions** (NFTs that respond to multiple authorized addresses) - **Content generation** (NFTs that produce art, music, or text on demand) - **Physical-digital linkage** (NFTs tied to physical objects via IoT oracles) ### 16.7 Cross-Chain Enhancements - **Light client verification** replacing multisig for higher security - **Atomic cross-chain swaps** for agent-to-agent cross-chain payments - **Cross-chain swarm coordination** (swarms spanning multiple chains) - **Relay chain integration** for chains not directly supported - **IBC protocol support** for Cosmos ecosystem interoperability ### 16.8 Privacy Features - **Confidential agent calls** using Kyber encryption for input/output - **Private knowledge bases** with encrypted vector stores - **Anonymous reputation** using zero-knowledge proofs of rating - **Selective disclosure** of agent capabilities and earnings --- ## 17. Conclusion FRC-55 represents a comprehensive standard for AI agents on the FractalAI blockchain, addressing the fundamental limitations of centralization, fragmentation, and quantum vulnerability that plague existing blockchain AI platforms. By unifying MCP, RAG, and RPA into a single composable framework with native payment rails, transparent reputation, and post-quantum security, FRC-55 provides the infrastructure necessary for a thriving, decentralized AI agent economy. The companion standards -- FRC-55T for Smart Tokens and FRC-55N for Smart NFTs -- extend the agent paradigm into digital assets, creating entirely new categories of intelligent financial instruments and evolving digital collectibles. The cross-chain bridge ensures that FRC-55 agents and assets are not confined to a single chain but can operate across the broader blockchain ecosystem. **Key technical achievements of FRC-55:** 1. **First blockchain-native MCP implementation** -- enabling standardized tool use with on-chain discovery, payment, and reputation 2. **First on-chain RAG framework** -- anchoring knowledge base integrity to blockchain state with verifiable data hashes and decentralized storage 3. **First blockchain RPA engine** -- supporting event-driven, multi-step workflows with conditional branching and typed actions 4. **First post-quantum agent standard** -- using CRYSTALS-Dilithium and Kyber to secure all agent registrations, calls, and payments against quantum attacks 5. **First AI-embedded token standard** -- FRC-55T tokens with up to 64 programmable behaviors driven by autonomous AI agents 6. **First evolving NFT standard** -- FRC-55N NFTs with experience points, leveling, dynamic metadata, and AI personality 7. **First unified cross-chain agent bridge** -- enabling agent deployment and invocation across eight blockchains through a multisig-validated protocol The FractalAI blockchain, with its Proof of Fractal Work consensus, golden ratio mathematics, and WASM-based FractalVM, provides the ideal substrate for this agent ecosystem. The FRAC token flows naturally through the system -- from callers to agents to owners to validators -- creating a self-sustaining economy where AI agents are first-class citizens of the blockchain. As AI agents become increasingly capable and autonomous, the need for decentralized, verifiable, and economically sound infrastructure will only grow. FRC-55 positions the FractalAI ecosystem at the forefront of this convergence, providing the standards, primitives, and security model necessary for the next generation of autonomous AI systems. --- ## 18. References [1] Anthropic, "Model Context Protocol (MCP) Specification," 2024. https://modelcontextprotocol.io [2] P. Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks," NeurIPS 2020. [3] UiPath, "Robotic Process Automation: A Primer," 2023. [4] Autonolas, "Autonolas Protocol Whitepaper," 2023. https://docs.autonolas.network [5] Fetch.ai, "Fetch.ai Technical Whitepaper," 2023. https://fetch.ai/technology [6] SingularityNET, "SingularityNET Protocol Specification," 2023. https://dev.singularitynet.io [7] Virtuals Protocol, "Virtuals Protocol Documentation," 2024. https://docs.virtuals.io [8] NIST, "FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)," 2024. [9] NIST, "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)," 2024. [10] National Academies, "Quantum Computing: Progress and Prospects," 2019. [11] Federal Reserve, "Harvest Now, Decrypt Later: Examining Post-Quantum Cryptography and Data Privacy Risks for Distributed Ledger Networks," 2025. [12] FractalAI Foundation, "Fractal Shard Protocol: A Post-Quantum Blockchain with Fractal-Optimized Scalability," Version 1.0, February 2026. [13] A. Hurwitz, "Uber die angenaherte Darstellung der Irrationalzahlen durch rationale Bruche," Mathematische Annalen, 1891. [14] M. Shishikura, "The Hausdorff dimension of the boundary of the Mandelbrot set and Julia sets," Annals of Mathematics, 1998. [15] A. Gelashvili et al., "Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing," PPoPP 2023. [16] J. Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models," NeurIPS 2022. [17] T. Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools," NeurIPS 2023. [18] Y. Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models," ICLR 2023. [19] S. Park et al., "Generative Agents: Interactive Simulacra of Human Behavior," UIST 2023. [20] Z. Xi et al., "The Rise and Potential of Large Language Model Based Agents: A Survey," arXiv 2309.07864, 2023. --- *Copyright 2026 FractalAI Foundation. All rights reserved.* *This whitepaper describes the FRC-55 AI Agent Standard as implemented in the FractalAI* *blockchain codebase. The standard is subject to evolution through community governance* *and FRC improvement proposals.* *FractalAI Blockchain -- Where Intelligence Meets Immutability*