# ERC-LA: Liquid Agent Standard

***

## Overview

CROME addresses the next evolution of DeFi by introducing a new class of digital assets: **Tokenized Liquid Agents**. Built on **ERC-LA**, the Liquid Agent Standard (LAS), these are advanced, tradable blockchain-based entities capable of:

* **Independently executing programmed logic**
* **Managing multi-asset portfolios**
* **Interacting dynamically across decentralized networks**

This architecture positions CROME at the core of **Intelligent Finance (IntelFi),** a new paradigm where financial agents are not only programmable, but also composable, interoperable, and autonomously adaptive.

***

### **Motivation**

ERC-20, ERC-721, and ERC-6551 solved liquidity, uniqueness, and token-as-account. But developers still lack a **single primitive** that is:

* **Transferable as value**,
* **Addressable as an identity**, and
* **Capable of autonomous operations** (storage, logic, scheduling, inter-agent messaging).

DeFi strategies today often rely on off-chain triggers or centralized automation layers. ERC-LA fills this gap by enabling on-chain agents to hold state, execute strategies, and interact with other protocols directly, ultimately eliminating single points of failure and allowing ecosystems to treat tokens as **operational agents**, not static records.

***

### **Core Design**

**ERC-LA agents are:**

* **Tokenized**: Represented as an NFT (ERC-721) for unique identity, with ERC-6551 integration for token-bound accounts.
* **Composable**: Each ERC-LA agent can hold, deploy, or interact with other agents, contracts, or assets.
* **Programmable**: Encapsulate execution logic, parameter sets, and permissions.
* **Portable**: Can be transferred, sold, or delegated between addresses without losing operational state.

**Core Metadata:**

* Agent Type (e.g., Portfolio Manager, Arbitrage Bot, Compliance Monitor)
* Execution Parameters (encoded strategies, thresholds, triggers)
* Security Profile (multi-sig requirements, whitelisted protocols)
* Composability Rules (which other ERC-LA agents it can integrate with)

***

### **Specification**

The keywords “MUST”, “SHOULD”, etc., follow RFC 2119/RFC 8174.

#### 1) Trifecta Composition

An ERC-LA compliant implementation MUST expose:

* **ERC-20** interface for fungible transfers and allowances.
* **ERC-721** interface for identity & metadata of agent instances.
* **ERC-6551** integration so each agent token ID resolves to a token-bound account (TBA) for storage/logic. [docs.crome.pro](https://docs.crome.pro/)

#### 2) Token-Bound Account Lifecycle

Implementations MUST provide a way to **create or resolve** the TBA for a given `(tokenContract, tokenId)` and SHOULD use a registry compatible with ERC-6551:

```solidity
solidityCopyEditfunction createAccount(
  address implementation,
  bytes32 salt,
  uint256 chainId,
  address tokenContract,
  uint256 tokenId
) external returns (address account);
```

If the account exists, it MUST return the existing address (idempotent).

#### 3) Agent Authorization

Owners (or approved operators) SHOULD be able to authorize external automation or off-chain services to act for a given agent:

```solidity
solidityCopyEditevent AgentAuthorized(uint256 indexed tokenId, address agent, bool authorized);

function authorizeAgent(
  uint256 tokenId,
  address agent,
  bool authorized
) external;
```

#### 4) Inter-Agent Messaging (Optional but Recommended)

Agents MAY send compact messages to other agents to coordinate:

```solidity
solidityCopyEditevent AgentMessageSent(uint256 indexed fromTokenId, uint256 indexed toTokenId, bytes32 message);

function sendAgentMessage(
  uint256 fromTokenId,
  uint256 toTokenId,
  bytes32 message
) external;
```

#### 5) Action Scheduling (Optional but Recommended)

Agents MAY schedule actions to their TBA (one-time or recurring):

```solidity
solidityCopyEditevent ActionScheduled(uint256 indexed tokenId, uint256 actionId, uint256 executeAt, uint256 interval);
event ActionExecuted(uint256 indexed tokenId, uint256 actionId, bool success);

function scheduleAction(
  uint256 tokenId,
  address to,
  uint256 value,
  bytes calldata data,
  uint8 operation,        // e.g., CALL / DELEGATECALL
  uint256 executionTime,  // unix time
  uint256 interval        // 0 for one-shot
) external returns (uint256 actionId);
```

#### 6) ERC-721 <-> ERC-20 Cohesion

Implementations SHOULD define a consistent mapping between fungible balances and the issuance/revocation of agent identities (e.g., mint an NFT agent when holdings cross a threshold, or use deterministic IDs per holder). Backward-compatibility with vanilla ERC-20/721 tooling MUST be preserved (transfers must not break). [Fellowship of Ethereum Magicians](https://ethereum-magicians.org/t/erc-xxxx-dimensional-token-standard-dts/21185)[docs.crome.pro](https://docs.crome.pro/)

#### 7) Metadata & BaseURI

Implementations SHOULD surface a base URI for agent metadata, allowing UIs to render stateful agent dashboards.

#### 8) DEX & Fee Hooks (Implementation-Specific)

Implementations MAY include optional fee routing and DEX integration hooks (e.g., Uniswap V2/V3) for on-chain operations funded by agents. (Out of scope for the core standard; considered a profile for implementers.)

***

### Rationale

* **Unify value, identity, and agency**: Trifecta solves fragmented developer ergonomics and opens richer UX (tokens that “do things”). [docs.crome.pro](https://docs.crome.pro/)
* **6551 as the execution substrate**: Per-token accounts provide isolated storage and programmable execution without new opcodes. [Fellowship of Ethereum Magicians](https://ethereum-magicians.org/t/erc-xxxx-dimensional-token-standard-dts/21185)
* **Composable behaviours**: Standard events & minimal interfaces (auth, message, schedule) let agents interoperate across protocols, similar to how ERC-4626 standardized vaults, small surface, large ecosystem effect.

***

### Examples / Pseudocode

**Create/resolve TBA** (owner-gated):

```solidity
solidityCopyEditaddress acct = createAccount(implementation, salt, block.chainid, address(this), tokenId);
```

**Authorize a keeper**:

```solidity
solidityCopyEditauthorizeAgent(tokenId, keeperAddress, true);
```

**Send a message to another agent**:

```solidity
solidityCopyEditsendAgentMessage(tokenIdA, tokenIdB, keccak256("PING"));
```

**Schedule a rebalance**:

```solidity
solidityCopyEditscheduleAction(tokenId, vault, 0, abi.encodeWithSelector(Vault.rebalance.selector), 0, block.timestamp + 1 hours, 24 hours);
```

(Interfaces reflect the current CROME `ERCAIv3` draft for agent auth, messaging, and scheduling.)

***

### **Applications Within CROME**

ERC-LA agents will serve as the operational backbone for IntelFi use cases, including:

* Decentralized Portfolio Managers
* Composable Arbitrage Networks
* Compliance & KYC Automation Agents
* On-Chain Governance Executors
* Inter-Protocol Strategy Orchestration

***

### Backward Compatibility

ERC-LA MUST remain discoverable by standard ERC-20/721 tooling (transfers, approvals, metadata). 6551-based accounts MUST NOT break ownership semantics: wallets and marketplaces should still recognize transfers as if they were standard tokens. [Fellowship of Ethereum Magicians](https://ethereum-magicians.org/t/erc-xxxx-dimensional-token-standard-dts/21185)

***

### Security Considerations

* **Agent privilege escalation**: Keep tight auth (only owner/approved may authorize agents).
* **Scheduled call surfaces**: Validate `operation`, `to`, and `data`; emit events for off-chain monitors.
* **Reentrancy & cross-agent loops**: Guard scheduling and messaging paths (e.g., ReentrancyGuard).
* **DEX hooks**: Treat swap paths and fee routers as untrusted, use allowlists and rate limits.
* **Upgradability**: If agent logic is upgradeable, publish policies and timelocks for changes.

***

### Reference Implementation (CROME)

CROME’s `ERCAIv3` demonstrates an ERC-LA agent with:

* **Trifecta**: ERC-20 + ERC-721 + ERC-6551 registry/account plumbing.
* **Agent ops**: `authorizeAgent`, `sendAgentMessage`, and `scheduleAction` events/handlers.
* **DEX integration profile**: optional fee routing & AMM hooks for on-chain operations.

Conceptually aligned with the “multi-dimensional token + 6551” pattern discussed by the community, but standardized around **agent behaviors** (auth, messaging, scheduling) rather than only structure.

***

ERC-LA is not just a technical standard, it is the **execution layer for programmable, on-chain intelligence**. By standardizing Liquid Agents, CROME enables a financial environment where assets are active participants in the network economy, not just passive stores of value.

{% hint style="info" %}
**Hint:** While ERC-LA defines the rules, *CROME X* will be the interface where these Liquid Agents live, learn, and collaborate.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.crome.pro/technical-overview/erc-la-liquid-agent-standard.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.