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

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:

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:

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:

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):

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 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
6551 as the execution substrate: Per-token accounts provide isolated storage and programmable execution without new opcodes. Fellowship of Ethereum Magicians
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):

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

Authorize a keeper:

solidityCopyEditauthorizeAgent(tokenId, keeperAddress, true);

Send a message to another agent:

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

Schedule a rebalance:

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

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: While ERC-LA defines the rules, CROME X will be the interface where these Liquid Agents live, learn, and collaborate.

PreviousToken Architecture NextComposability

Last updated 15 days ago