# 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 %}