Autonomous AI agents access IXS Vaults through IXS Agent Rail, the access infrastructure that connects agent frameworks and smart-contract wallets to the regulated Vault product set. Integration covers wallet setup, operator verification, SDK integration, Vault contract authorization, first deposit, and programmatic position monitoring. Agents transact in the same regulated Vaults available to institutional counterparties — not a separate sandbox or reduced-compliance environment.
The agent needs a wallet that can hold stablecoins, interact with ERC-4626 Vault contracts, and execute transactions programmatically without manual signing at each step.
Three wallet architectures are compatible with IXS Agent Rail.
ERC-4337 smart accounts are the recommended default. These accounts support programmable transaction logic, gas sponsorship, batched operations, and session keys that allow the agent to execute within defined parameters without requiring the operator's signature on every transaction. The agent framework controls the session key; the operator controls the master key.
Safe (formerly Gnosis Safe) multisig wallets work for agent operators that want multi-party approval on high-value transactions while allowing the agent to execute routine operations (deposits, redemptions, position queries) through a module or delegate. This is common for enterprise deployments where the agent operates under a policy set by a human-controlled governance layer.
Purpose-built agent wallets provided by agent infrastructure platforms (such as Coinbase AgentKit, Lit Protocol agent wallets, or similar) are also compatible, provided they support standard EVM contract interactions and can be whitelisted through the IXS onboarding process.
The wallet must be funded with the stablecoins the agent will deposit (USDC, USDT, or other supported stablecoins) and sufficient native tokens (ETH on Ethereum, or the chain's native gas token) for transaction fees — unless gas sponsorship is configured through the smart account or a paymaster.
IXS verifies the operator, not the agent. The entity that deploys, controls, and is responsible for the agent's actions must complete a verification process before the agent's wallet addresses are whitelisted for Vault interaction.
This is a deliberate design decision. An autonomous agent cannot be a legal counterparty — it has no legal identity, no jurisdiction, and no liability. The operator can. By verifying at the operator level, IXS maintains a regulated compliance perimeter while allowing the agent to operate autonomously within that perimeter.
The operator verification process is similar to institutional KYC: entity formation documents, beneficial ownership disclosure, authorized representative identification, and source-of-funds declaration. If the operator is already verified as an institutional counterparty (through the standard institutional onboarding path), agent wallet addresses can be added to the existing account without repeating the full KYC process.
Upon completion, the operator registers the agent's wallet addresses. These addresses are whitelisted at the smart-contract level — the Vault will accept deposits from and process redemptions to these addresses only. The operator can register multiple agent wallets under a single operator account, with per-wallet policy controls.
Operator verification typically takes five to ten business days. For operators already onboarded through the institutional path, agent wallet registration takes one to two business days.
The IXS Agent SDK provides the interface between the agent framework and the Vault contracts. Rather than building direct smart-contract interactions from scratch, the agent integrates the SDK and calls standardized functions for deposit, redemption, position query, and yield reporting.
The SDK exposes the following core functions: deposit(vaultAddress, stablecoin, amount) to subscribe to a Vault, redeem(vaultAddress, shares) to withdraw from a Vault, balanceOf(vaultAddress, walletAddress) to query current position, yieldAccrued(vaultAddress, walletAddress) to check pending yield, and vaultInfo(vaultAddress) to retrieve Vault parameters (underlying asset, current NAV, yield range, redemption terms).
The SDK is framework-agnostic. It works with any agent framework that can execute JavaScript or Python function calls — including AutoGPT, LangChain, CrewAI, custom agent architectures, and multi-agent orchestration systems. The integration is a standard library import, not a protocol-level dependency.
For agents that prefer direct smart-contract interaction without the SDK wrapper, the Vault contracts follow the ERC-4626 standard. Any agent that can call deposit(), redeem(), balanceOf(), and totalAssets() on an ERC-4626 contract can interact with IXS Vaults directly. The SDK adds convenience (error handling, multi-chain routing, stablecoin selection) but is not required.
Full SDK documentation, code examples, and integration guides are available at api-v2.ixs.finance/docs.
Before the agent executes its first transaction, the operator must add the target Vault contract addresses to the agent's policy — the allowlist that defines which contracts the agent is permitted to interact with.
This step is critical for security. An agent with unrestricted contract interaction capability can be exploited through prompt injection, policy manipulation, or adversarial onchain conditions. By restricting the agent to a defined set of Vault contracts, the operator limits the blast radius of any agent malfunction or attack.
The authorization process depends on the wallet architecture. For ERC-4337 smart accounts, the Vault addresses are added to the session key's allowed-targets list. For Safe wallets, the Vault addresses are added to the module's allowlist or the delegate's permitted contracts. For purpose-built agent wallets, the platform's policy engine is configured with the Vault addresses.
IXS publishes the canonical Vault contract addresses in the SDK documentation and through a registry endpoint. Operators should verify contract addresses against this registry before adding them to the agent's policy — do not trust addresses received through other channels.
After authorization, the agent can call the SDK functions (or direct contract calls) for the authorized Vaults only. Any attempt to interact with a non-authorized contract will be rejected by the wallet's policy engine before the transaction reaches the blockchain.
The first deposit is both a functional transaction and an end-to-end integration test. It confirms that the agent's wallet is whitelisted, the SDK is correctly integrated, the Vault contract is authorized, and the transaction signing flow works as expected.
The recommended first deposit is a small test amount — enough to verify the full cycle without exposing significant capital. The process is: the agent calls deposit(vaultAddress, USDC, testAmount), the SDK routes the transaction through the agent's wallet, the wallet signs the transaction according to its policy (session key, module, or delegate), the transaction hits the Vault contract, the contract verifies the wallet's whitelist status, accepts the deposit, and mints Vault tokens to the agent's wallet.
If the deposit succeeds, the agent's wallet holds Vault tokens representing its share of the underlying assets. The agent can immediately query its position via balanceOf() and confirm the deposit amount matches expectations.
If the deposit fails, common causes include: wallet address not whitelisted (operator verification incomplete or wallet not registered), insufficient stablecoin balance or gas, Vault contract not authorized in wallet policy, or stablecoin approval not granted to the Vault contract (the agent must call approve() on the stablecoin contract before the first deposit).
After the test deposit succeeds, the agent is fully operational and can execute at production scale.
Once deployed, the agent monitors its Vault positions, yield accrual, and underlying asset performance through the same SDK functions used for deposit and redemption.
The standard monitoring loop for a treasury-management agent includes: periodic balanceOf() calls to confirm current position across all active Vaults, yieldAccrued() calls to track pending yield before distribution, vaultInfo() calls to check for changes in Vault parameters (NAV updates, yield range adjustments, redemption term changes), and decision logic that evaluates whether to hold, redeem, or rebalance across Vaults based on the agent's policy and the operator's objectives.
For agents that operate across multiple Vaults or multiple chains, the SDK provides batch query functions that return position data across all active Vaults in a single call, reducing the number of RPC requests and simplifying the agent's decision loop.
All position data is also verifiable onchain. The Vault token balance is a standard ERC-20 balance query. The Vault's total assets and share price are public view functions on the contract. An agent — or its operator — can independently verify any position reported by the SDK against the onchain state.
Yield distribution follows the schedule defined by each Vault product. When yield is distributed, the agent's Vault token balance increases proportionally (for accumulating Vaults) or stablecoins are sent directly to the agent's wallet (for distributing Vaults). The agent does not need to claim yield manually — distribution is automatic.