> For the complete documentation index, see [llms.txt](https://docs.world.inc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.world.inc/ai-agents/world-agent.md). # World Agent ## Manage World through an agent without signing every transaction World Agent allows you to authorize an automated agent to manage your World account within rules you approve. After setup, you can communicate with the agent through Telegram or another supported interface. The agent can approve tokens, deposit assets, trade, lend, borrow, repay obligations, and return assets to your wallet without asking you to sign every routine transaction. You retain ultimate control through your owner wallet. The agent cannot: * Increase its own authority * Change ownership * Change recovery settings * Add another signer * Add a new protocol * Add a withdrawal address * Send assets to an arbitrary wallet * Bypass the policy you approved World Agent does not eliminate financial risk. Trading, leverage, lending, borrowing, smart contracts, oracles, counterparties, liquidity, networks, wallet infrastructure, signer providers, and agent software can fail. You may lose some or all of the assets used by the agent. *** ## How World Agent works World Agent separates asset ownership from day-to-day execution. | Component | Purpose | | --------------- | ------------------------------------------------------------------- | | Owner wallet | Owns the assets and controls agent authorization | | Agent signer | Signs permitted actions without exposing the owner key | | Wallet policy | Restricts contracts, functions, assets, destinations, and spending | | World policy | Restricts portfolio risk, leverage, borrowing, and execution | | Agent runtime | Interprets instructions, monitors the account, and proposes actions | | Telegram | Lets you communicate with the agent from your phone | | World contracts | Execute and enforce onchain actions | The owner wallet remains the highest authority. The agent signer is replaceable and may not: * Change the owner * Change recovery methods * Add another signer * Expand its policy * Withdraw to an unapproved address * Use an unapproved protocol * Bypass World’s onchain policy *** ## What “no routine signatures” means After activation, the agent may perform ordinary actions that are inside the policy without asking the owner to sign each transaction. These actions may include: * Token approvals to approved World contracts * Deposits into World * Spot trading * Perpetual trading * Lending * Borrowing * Repayment * Refinancing * Order placement * Order cancellation * Portfolio rebalancing * Risk reduction * Withdrawal from World back to the predetermined owner wallet * Transaction-fee payment or sponsorship A new owner authorization is still required when the agent’s authority is expanded. Examples of policy expansions include: * Increasing the capital limit * Adding an asset * Adding a market * Adding a protocol * Enabling borrowing * Increasing the borrowing limit * Lowering the margin requirement * Adding a withdrawal destination * Adding another wallet * Replacing the agent signer * Extending an expired policy * Changing ownership * Changing recovery settings Routine execution and expansion of authority are deliberately separate. *** ## Quick start ### 1. Open World on desktop Open the official World application and select: Set up your World agent Use the official World domain. Do not follow an authorization link from an unknown bot, account, message, advertisement, or website. ### 2. Connect your wallet Connect the wallet that should own the World account. When the wallet supports portable delegation: * The wallet address remains the same * Assets remain in the wallet until the agent uses them * No special World-only wallet needs to be funded * No assets move during setup * The owner wallet remains in control When the wallet is not compatible, World will explain the available alternatives before creating any wallet, account, or permission. ### 3. Set the capital limit Choose the maximum value of wallet assets the agent may place under management. This limit is separate from gross market exposure. Borrowing and derivatives can create exposure greater than the amount transferred from the wallet. The World policy therefore includes additional limits covering: * Leverage * Gross exposure * Net exposure * Borrowing * Margin * Execution cost * Daily loss * Turnover ### 4. Connect Telegram Scan the displayed QR code and tap Start in Telegram. The pairing request is temporary and can be used only once. It does not contain a private key or signer credential. ### 5. Review the policy World displays: * The owner wallet * The agent signer * The maximum assets the agent may use * The permitted contracts * The permitted assets * The permitted markets * The withdrawal destination * The most important portfolio limits * Whether borrowing is enabled * Whether the agent may open new positions * The policy duration You may open the exact policy before signing. ### 6. Activate the agent Approve the setup through your owner wallet. This authorization creates the agent’s limited authority. It does not deposit funds or open a position by itself. ### 7. Continue in Telegram After activation is confirmed, World sends a message to the connected Telegram account. You may then close the desktop page and manage the agent from your phone. *** ## Wallet and account architecture ### Owner wallet The owner wallet is the ultimate authority. It controls: * Agent creation * Policy expansion * Policy replacement * Agent revocation * Ownership * Recovery * Additional wallets * Additional protocols * Unrestricted withdrawals The owner key is not provided to: * The agent * Telegram * The language model * The World front end * The agent runtime * The relayer * The signer provider’s application interface The owner wallet is required only for actions that create, replace, expand, or revoke authority. ### Agent signer The agent signer is a separate cryptographic identity secured by: \[SIGNER PROVIDER] The implementation may use: * A delegated user * An additional signer * An MPC signing share * A restricted authorization credential * Another provider-specific signing mechanism The agent signer: * Does not replace the owner wallet * Does not receive the owner private key * Does not need to own the user’s assets * Cannot modify its own policy * Can be paused * Can be revoked * Can be rotated * Is bound to specific wallet permissions * Is bound to specific World permissions The exact signer address appears in: * The setup review * Agent Settings * The exact policy * Onchain authorization records ### Online agent credential Autonomous operation requires an online credential capable of requesting signatures from the signer provider. This credential is not the owner key. It may not be the Ethereum private key. It is still security-sensitive. A compromised runtime credential may be able to request actions within the provider policy. For this reason, World uses multiple policy layers. The production implementation must document: * Which entity operates the agent runtime * Where the credential is stored * How the credential is encrypted * How the credential is rotated * How the credential is revoked * Which provider-side policies apply * Whether the provider can export the signer * Whether the provider can recover the signer * Which audit logs are available * Which personnel may access runtime systems * Which incident-response process applies ### Telegram Telegram is an instruction and notification interface. Telegram does not: * Hold the owner key * Hold the agent’s Ethereum private key * Define the onchain policy * Expand the policy * Become the withdrawal destination * Control ownership * Control recovery Someone who compromises the user’s Telegram account may issue instructions within the existing policy. Users should enable Telegram’s own account-security protections and regularly review active Telegram sessions. *** ## Existing-wallet compatibility World Agent is designed to work through portable wallet-level delegation rather than a World-specific asset wallet. ### EIP-7702-compatible EOAs An EIP-7702-compatible EOA may gain smart-account capabilities while preserving its address. This may allow the wallet to support: * Batched execution * Sponsored gas * Restricted subkeys * Token approval followed by deposit * Ongoing agent permissions * Policy-based execution EIP-7702 alone does not provide a complete safe permission system. The delegated account implementation must securely enforce: * Replay protection * Allowed contracts * Allowed functions * Allowed calldata * Native-token value * Gas limits * Nonces * Expiration * Signer authority * Withdrawal destinations A poorly implemented delegation may expose the EOA to severe loss. World supports only reviewed implementations listed under: \[SUPPORTED WALLETS] ### Smart accounts Supported smart accounts may authorize the agent through: * A wallet module * A wallet-native delegation system * A restricted signer * An account permission system The existing wallet remains the owner. The wallet’s normal ownership, recovery, and multisig rules continue to apply. ### Multisigs When a multisig owns the account, agent activation is a multisig transaction. The organization’s existing threshold must approve the initial mandate. After activation, routine agent actions may operate autonomously within the approved policy. ### Unsupported EOAs An unsupported EOA cannot safely provide ongoing autonomous access without: * An account upgrade * A wallet migration * A connected smart account * A separate portable wallet * Approval-per-action mode World will not claim a no-signature experience for an unsupported wallet. The user may: * Use another supported wallet * Create a portable smart account owned by the existing wallet * Wait until the wallet supports the required delegation * Use approval-per-action mode World will never ask the user to paste a seed phrase or raw private key into the standard World interface. *** ## How agent execution works A normal agent action follows this sequence: 1. The user sends an instruction 2. The agent interprets the requested objective 3. The agent creates a typed World intent 4. Deterministic software constructs the exact transaction or transaction bundle 5. The action is simulated 6. The wallet-provider policy is evaluated 7. World’s policy is evaluated 8. The restricted signer authorizes the action 9. A relayer or transaction sender submits the action 10. World produces a structured receipt The language model should not have unrestricted access to arbitrary transaction signing. The model proposes structured intents. Example: ```json { "intent": "reduce_risk", "wallet": "0xOWNER", "targetAvailableMarginRatio": "0.45", "maximumExecutionCostUsd": "250", "deadline": 1784505600 } ``` The deterministic execution layer decides which exact orders and contract calls satisfy that intent. *** ## Policy layers World Agent uses two complementary policy layers. ### Wallet-level policy The wallet or signer-provider policy restricts what the agent signer may authorize. It may restrict: * Chain ID * Target contracts * Function selectors * Decoded function arguments * Token addresses * Token amounts * Native-token value * Withdrawal destinations * Per-action limits * Time windows * Total capital * Expiration * Required co-approvals * Signer identity * Gas * Relayer * Allowed protocols ### World-level policy The World policy restricts the economic result of the action. It may restrict: * Markets * Assets * Spot trading * Perpetual trading * Lending * Borrowing * Repayment * Refinancing * Gross exposure * Net exposure by asset * Available-margin ratio * Risk consumption * Leverage * Daily realized loss * Drawdown * Turnover * Order size * Bundle size * Slippage * Execution cost * Borrowing principal * Borrowing rate * Loan maturity * Counterparty concentration * Policy duration * Emergency behavior * Risk-increasing actions * Risk-reducing actions When the wallet-level policy and World-level policy differ, the more restrictive result applies. A transaction must pass every applicable policy check. *** ## ATLAS-aware restrictions World’s universal margin system evaluates: * Collateral * Lending * Borrowing * Spot exposure * Perpetual exposure * Hedging * Portfolio-level risk World Agent policies use the projected portfolio state when evaluating an action. The agent may be permitted to trade ETH but still be rejected when the proposed action would: * Reduce available margin below the policy floor * Increase gross exposure above the policy cap * Create excessive net ETH exposure * Borrow above the principal limit * Borrow above the interest-rate limit * Exceed an execution-cost limit * Exceed a daily turnover limit * Use an unapproved market * Use an unapproved asset * Violate a loan-maturity requirement * Increase portfolio risk beyond the approved level A successful pre-execution check is not a guarantee that the account will remain above the threshold. Markets, liquidity, collateral values, funding rates, borrowing conditions, and oracle prices may change after execution. *** ## Default policy The default policy is designed to let the agent manage World without receiving unrestricted wallet authority. The exact live defaults are displayed before authorization. ### Wallet restrictions * Chain: \[SUPPORTED CHAIN IDS] * Approved contracts: \[WORLD CONTRACT ALLOWLIST] * Maximum wallet assets under agent management: User-selected * Withdrawal destinations: Owner wallet only * Arbitrary transfers: Prohibited * Ownership changes: Prohibited * Recovery changes: Prohibited * New signer creation: Prohibited * Policy expansion: Prohibited * New protocol access: Prohibited * Unlimited token approvals: Prohibited by default ### World restrictions * Markets: \[DEFAULT MARKET ALLOWLIST] * Minimum available margin: \[DEFAULT VALUE] * Maximum gross exposure: \[DEFAULT VALUE] * Maximum net exposure per asset: \[DEFAULT VALUES] * Maximum borrowed principal: \[DEFAULT VALUE] * Maximum borrowing rate: \[DEFAULT VALUE] * Maximum order size: \[DEFAULT VALUE] * Maximum bundle size: \[DEFAULT VALUE] * Maximum execution cost: \[DEFAULT VALUE] * Maximum slippage: \[DEFAULT VALUE] * Maximum daily turnover: \[DEFAULT VALUE] * Maximum daily loss: \[DEFAULT VALUE] * Policy duration: \[DEFAULT DURATION] *** ## Risk-reduction override A strict daily-loss or turnover limit may prevent an agent from closing a dangerous position. The recommended policy may therefore include a narrowly defined risk-reduction path. A risk-reduction action may be permitted when it demonstrably improves a specified risk measure, even when it: * Realizes an existing loss * Exceeds ordinary turnover * Closes a position earlier than planned * Repays borrowing at an unfavorable moment * Cancels an otherwise valid strategy The risk-reduction override must not permit: * A new withdrawal address * A new protocol * A new asset * Increased gross risk * Increased net directional risk * Ownership changes * Recovery changes * A capital-limit increase * Arbitrary external calls * Another signer * A policy expansion The exact precedence rules must be published in the policy specification. *** ## Understanding the capital limit The capital limit controls the maximum value of owner-wallet assets the agent may place under management. It is measured using: \[ORACLE OR VALUATION METHOD] The capital limit is not the same as: * Maximum gross exposure * Maximum possible loss * Maximum borrowed principal * Maximum derivatives notional * Maximum liquidation loss For example, an agent allowed to use $10,000 of wallet assets may create more than $10,000 of market exposure when borrowing or derivatives are allowed. The setup screen therefore shows the simple capital limit. The advanced policy contains separate limits for: * Gross exposure * Borrowing * Leverage * Margin * Daily loss * Net exposure * Execution cost Price-feed failures or valuation delays may cause a policy limit to be evaluated incorrectly. The policy cannot guarantee a maximum loss. *** ## Deposits The agent may deposit eligible assets from the connected wallet into World without a new owner signature when: * The asset is allowed * The World deposit contract is allowed * The deposit remains within the capital limit * The amount remains within the per-action limit * The wallet-level policy accepts the token approval * The World policy accepts the resulting portfolio * The signer authorization remains active * The policy has not expired No deposit occurs merely because the agent was activated. The user must instruct the agent or enable a specific automation before funds are deployed. *** ## Token approvals The agent may create token allowances only for approved contracts. World should prefer: * Exact allowances * Time-limited allowances * Permit-based transfers * Batched approval-and-deposit transactions Unlimited approvals should not be used by default. When an underlying token or integration requires an unlimited approval, the interface must identify: * The token * The spender contract * Why the approval is required * How to revoke it * Whether the provider policy independently caps use * Whether the approval survives agent revocation Revoking the agent does not necessarily revoke every previously created ERC-20 allowance. Agent Settings must provide an allowance-review and revocation function. *** ## Withdrawals and returning funds The agent may withdraw from World only to: * The predetermined owner wallet * Another address explicitly approved by the owner The agent may not add a new destination. A Telegram instruction such as: Return all my funds may cause the agent to: 1. Cancel open orders 2. Close positions 3. Repay loans 4. Settle obligations 5. Withdraw available assets 6. Return assets to the owner wallet 7. Revoke unnecessary token allowances where supported Returning all funds may not be immediate or fully possible when: * A loan has not matured * A loan cannot be refinanced * A market is paused * Liquidity is insufficient * An order cannot fill within the execution-cost limit * The account is being liquidated * A protocol is unavailable * The network is unavailable * An oracle has failed * An asset cannot be transferred * An asset has lost value * A smart contract has failed * A counterparty has failed * A position cannot be closed safely The agent must report: * What was returned * What remains * Why it remains * Which obligations remain * Which risks remain *** ## Gas and transaction submission Routine agent actions should not require the user to maintain a separate gas wallet. Depending on the supported implementation, gas may be: * Sponsored by a paymaster * Paid by a relayer * Reimbursed from the owner wallet * Paid in an approved ERC-20 * Deducted from the action * Paid from a capped gas balance The exact gas method and fees must be visible in Agent Settings. Gas sponsorship is an availability feature, not a guarantee. When gas sponsorship is unavailable, an action may be delayed or fail. *** ## Using Telegram ### Supported requests The agent may support instructions such as: * Show me my portfolio * Put $5,000 to work conservatively * Keep my ETH exposure neutral * Stop borrowing * Cancel my open orders * Reduce my risk * Close the basis strategy * Return everything to my wallet * Pause * Explain my current risk * Show me recent actions * Show me what the agent is allowed to do ### Agent responses For every material action, the agent should report: * What it did * Why it did it * Which wallet it used * Which World account it used * Which policy authorized the action * Amounts * Assets * Markets * Estimated cost * Actual cost * Portfolio state before the action * Portfolio state after the action * Transaction hash * Whether any part failed * Whether another action remains pending The agent may notify the user before an action without requiring approval when the action is already inside the policy. ### Telegram cannot expand authority A Telegram message cannot: * Increase the capital limit * Add a protocol * Add a market outside the policy * Add an asset outside the policy * Add a withdrawal address * Replace the owner * Add another signer * Disable owner recovery * Change the wallet implementation * Extend an expired mandate * Lower required safety limits When a user requests one of these changes, the agent must provide a link to a World-controlled authorization page. ### Pause The user may pause the agent from Telegram. Pausing: * Blocks ordinary new agent actions * Does not automatically close positions * Does not automatically repay loans * Does not automatically cancel every open order * Does not revoke the signer * Does not revoke token allowances The user may separately request: * Pause * Pause and cancel orders * Risk reduction only * Return funds ### Resume For protection against a compromised Telegram account, resuming after a security pause should require owner authentication. Telegram alone must not be able to reverse an owner-initiated emergency pause. ### Telegram compromise Anyone who controls the connected Telegram account may instruct the agent within its existing policy. If Telegram may be compromised: 1. Pause the agent 2. Terminate unauthorized Telegram sessions 3. Open World Agent Settings from the official domain 4. Disconnect Telegram 5. Review recent agent actions 6. Rotate or revoke the agent signer if needed 7. Review token allowances 8. Review open orders and positions The World bot will never request: * A seed phrase * A private key * A recovery phrase * A raw API credential * A wallet export * A password * A signer credential *** ## Portability World Agent is intended to be a wallet-level agent identity rather than a World-only asset account. ### Other wallets A user may connect additional wallets to the same agent. Each wallet requires: * Its own owner authorization * Its own policy * Its own capital limit * Its own withdrawal destinations * Its own signer authorization The agent must never assume that authority over one wallet applies to another wallet. Users should assign clear names such as: * Main wallet * Trading wallet * Treasury * Safe * Personal ETH * Company wallet When an instruction could apply to multiple wallets, the agent must state which wallet it will use. ### Other protocols The same agent identity may later receive permission to use another protocol. Each protocol requires a separate policy. World’s policy protects World actions only. It does not automatically protect interactions with: * Aave * Uniswap * Morpho * Safe * Bridges * Other lending protocols * Other exchanges * Other smart contracts Adding another protocol must not broaden the existing World policy. ### Migration The supported signer provider must provide a documented method to: * Export or migrate the owner-controlled wallet where applicable * Rotate the agent signer * Revoke the old signer * Preserve owner access during provider outages * Recover after a lost device * Verify that an old credential is no longer usable * Move to another provider when supported The production implementation must describe its actual portability rather than relying only on labels such as non-custodial or user-controlled. *** ## Customizing the policy Open: Agent Settings → Safety rules The interface shows: * A human-readable policy * A machine-readable policy * The active policy hash * The active signer * The effective wallet * The effective withdrawal destinations The user may customize: * Capital limit * Markets * Assets * Borrowing * Gross exposure * Net exposure * Margin floor * Daily loss * Drawdown * Turnover * Slippage * Execution cost * Loan rates * Loan maturities * Policy duration * Approval requirements * Counterparty rules * Telegram account * Return wallet * Allowed protocols * Allowed contracts * Allowed functions ### Policy expansion A change expands the policy when it gives the agent more authority. Examples: * Increasing a limit * Adding an asset * Adding a market * Enabling borrowing * Increasing borrowed principal * Lowering the margin floor * Adding a protocol * Adding a withdrawal destination * Extending an expired mandate * Allowing more directional exposure * Allowing greater execution cost Policy expansions require owner authorization. ### Policy tightening A change tightens the policy when it reduces authority. Examples: * Reducing the capital limit * Removing a market * Removing an asset * Disabling borrowing * Raising the margin floor * Lowering gross exposure * Lowering daily turnover * Pausing the agent * Switching to risk-reduction-only mode The onchain implementation determines whether a tightening action requires an owner signature. ### Policy version and hash Every active policy has: * A version * An owner wallet * An agent signer * An effective time * An optional expiration * Encoded policy data * A policy hash * A current state * A nonce * A chain ID The human-readable policy shown in World must be generated from the exact encoded policy. Do not sign when the wallet, interface, and policy hash disagree. *** ## Agent states A World Agent may be in one of the following states. ### Draft Setup has started, but no authority exists. ### Pending authorization The proposed policy is waiting for owner authorization. ### Active The agent may perform permitted actions. ### Paused The agent may not initiate ordinary new actions. ### Risk-reduction only The agent may perform only narrowly defined actions that reduce portfolio risk or return assets. ### Expired The agent may no longer act. A new owner authorization is required. ### Revoked The agent signer has no remaining World authority. ### Replacing signer A replacement signer is being authorized. The previous signer should remain paused during replacement. *** ## Pausing, revoking, and rotating ### Pause Use pause when: * Telegram may be compromised * The agent behaves unexpectedly * The user wants to inspect the account * Market conditions are abnormal * A provider incident is reported * A model incident is reported * A wallet incident is reported Pause is intended to be fast and reversible. ### Risk-reduction only This mode allows only actions that satisfy the policy’s definition of risk reduction. It may be preferable to a full pause when: * Positions remain open * Loans remain outstanding * Funding obligations remain * Liquidation risk exists * Assets still need to be returned ### Revoke Revocation permanently removes the signer’s World authority. Revocation does not automatically: * Close positions * Repay loans * Cancel orders * Return assets * Revoke token allowances * Remove authority granted by another protocol * Resolve an ongoing liquidation * Close a loan * Settle every obligation The user should review each of these items after revocation. ### Rotate Rotation creates a new restricted signer and revokes the old signer. The owner must verify: * The new signer address * The new credential * The effective policy * The old signer’s revocation * Outstanding transactions from the old signer * Existing token allowances * Existing protocol permissions *** ## Losing a phone Losing the Telegram phone does not transfer ownership of the World account. The user should: 1. Secure or terminate Telegram sessions 2. Recover the owner wallet on a trusted device 3. Pause the agent 4. Disconnect the old Telegram account 5. Review recent actions 6. Connect a replacement Telegram account 7. Rotate the signer if unauthorized instructions may have been issued 8. Review token allowances 9. Review open orders and positions The owner-wallet recovery process depends on: * The connected wallet * The signer provider * The configured recovery methods Users should configure more than one secure owner recovery method when supported. *** ## Signer-provider outage If \[SIGNER PROVIDER] is unavailable: * The agent may be unable to sign new actions * Existing positions remain onchain * Existing loans remain active * Existing obligations remain active * The agent may fail to protect margin * The agent may fail to repay an obligation * The owner wallet retains ultimate control * The user may need to use the World interface * The user may need to use direct contract access The outage plan must document: * Status page * Recovery process * Alternative signing path * Export or migration process * Emergency revocation * Provider-specific recovery limitations * Incident communication * Expected user actions *** ## World interface outage World is designed to operate onchain. If the official interface is unavailable: * The protocol may continue operating * The Telegram agent may or may not continue, depending on the failed component * The user may use another verified World interface * The user may run the open-source interface locally * A professional user may use the SDK * A professional user may interact directly with contracts * The user should verify contract addresses independently The agent-control and revocation interfaces should have more than one availability path. *** ## Financial and protocol risks World is a complex onchain financial protocol. Agent policies reduce the authority of the agent. They do not remove the risks of using World. ### Trading risk Prices may move against the account. A hedged or delta-neutral strategy may still lose money because of: * Basis changes * Funding changes * Borrowing rates * Slippage * Fees * Incomplete fills * Execution delays * Liquidation costs * Counterparty failure * Asset depegging * Oracle behavior * Correlation breakdown * Market manipulation * Liquidity loss ### Leverage risk Borrowing and derivatives may create exposure larger than the wallet capital committed. Small market changes may produce large changes in account value. ### Liquidation risk An account may become eligible for liquidation when available margin reaches the protocol threshold. Liquidation may unwind the portfolio using available market liquidity. During volatile conditions, liquidation may produce substantial losses. A policy margin floor is not a guarantee against liquidation. The account may cross the threshold between transactions or during sudden market movement. ### Loan and settlement risk Loans, interest, funding, and settlement obligations may require timely payment. Failure by the agent, signer provider, network, oracle, relayer, wallet, runtime, or protocol may cause an obligation to be missed. ### Counterparty risk World financial contracts may have counterparties. A counterparty failure or bankruptcy may produce losses that are not prevented by the policy. ### Liquidity risk The agent may be unable to enter, adjust, or exit a position at an acceptable price. A maximum slippage or execution-cost rule may protect against a poor fill but may also prevent an urgent exit. ### Smart-contract risk The following components may contain vulnerabilities: * World contracts * Wallet contracts * Policy contracts * Delegation contracts * Token contracts * Integrated protocols * Relayer contracts * Paymaster contracts * Smart-account modules Audits reduce but do not eliminate this risk. ### Oracle risk Policies and margin calculations depend on prices. An incorrect, delayed, unavailable, or manipulated oracle may lead to: * Incorrect policy decisions * Incorrect collateral values * Incorrect mark prices * Unexpected liquidations * Unsafe actions * Rejected safe actions * Incorrect capital-limit calculations ### Network risk Transactions may be: * Delayed * Reordered * Censored * Reverted * Executed under changed market conditions Ethereum mainnet, based-rollup infrastructure, relays, proposers, RPC services, data-availability systems, and preconfirmation systems may fail or behave unexpectedly. ### Regulatory and tax risk Automated activity does not remove: * Legal obligations * Regulatory obligations * Reporting obligations * Tax obligations Users should obtain professional advice for their jurisdiction. *** ## Agent-specific risks ### Model error The model may: * Misunderstand an instruction * Omit relevant information * Propose an inappropriate action * Misclassify risk * Misinterpret a market * Produce an incorrect explanation Mitigations include: * Typed intents * Deterministic transaction construction * Simulation * Wallet-level policies * World-level policies * Structured receipts * Owner pause * Owner revocation These mitigations do not guarantee correct behavior. ### Prompt injection An agent may read: * Websites * Messages * Token metadata * Governance proposals * Market descriptions * Social content * External documents These sources may contain instructions intended to manipulate the agent. External content must be treated as untrusted data. Untrusted content must never be able to: * Change the policy * Reveal credentials * Select an arbitrary contract * Add a withdrawal destination * Override the user’s instruction * Disable safety checks * Add another signer * Expand protocol access ### Runtime compromise An attacker who compromises the runtime or its online credential may request actions within the permitted policy. The policy should therefore assume the runtime may become malicious. ### Incorrect policy compilation A natural-language instruction may be translated into the wrong numerical or machine-readable rule. The user should review the canonical policy summary before activation. ### Policy-display mismatch A malicious or buggy interface may describe a policy differently from what is encoded. The wallet, World interface, policy contract, and policy hash should be independently verifiable. ### Stale simulation A simulated action may become unsafe before execution because market conditions changed. Transactions should include: * Short deadlines * Price bounds * Oracle-freshness requirements * Slippage limits * Nonces * Replay protection * Post-execution checks where possible ### Excessive activity A malfunctioning agent may trade too frequently. Use: * Daily turnover limits * Per-period action limits * Cooldowns * Maximum fees * Duplicate-intent detection * Idempotency keys * Maximum transaction counts * Maximum order counts *** ## Signer and wallet risks ### Agent credential compromise The online agent credential may be stolen. Mitigations include: * Per-user credentials * Per-wallet credentials * Per-policy credentials * Encryption at rest * Hardware-backed storage where supported * Rotation * Expiration * Provider-side policies * Onchain policies * Audit logs * Rate limits * Allowlisted origins * Allowlisted runtimes ### Owner-wallet compromise An attacker who compromises the owner wallet may: * Revoke the legitimate agent * Authorize a malicious agent * Expand policies * Withdraw assets * Change ownership * Change recovery * Add signers * Add protocols The agent policy cannot protect against full owner-wallet compromise. ### Delegation implementation risk A smart-account or EIP-7702 implementation may contain vulnerabilities. Only reviewed implementations should be supported. Users should verify: * The implementation * The contract address * The version * Audit references * Known issues * Upgrade authority * Emergency controls ### Recovery risk Weak recovery systems may allow an attacker to obtain owner access. Relevant systems may include: * Email recovery * Social login * Passkeys * SIM-based recovery * Cloud backups * Device backups * Institutional recovery workflows Recovery should be appropriate for the value controlled. *** ## Privacy ### Onchain data The following may be publicly observable: * Wallet addresses * Balances * Positions * Orders * Loans * Policies * Signer addresses * Transactions * Delegation state * Contract interactions Using an agent does not make World activity private. ### Telegram data Telegram may retain messages and account metadata according to its own policies. Do not send: * Seed phrases * Private keys * Recovery phrases * Raw API credentials * Passwords * Sensitive personal information unrelated to the task ### Agent-service data The agent runtime may process: * User instructions * Wallet addresses * Portfolio information * Transaction history * Policy data * Agent activity * Simulation results * Telegram identifiers World’s privacy documentation must identify: * Model providers * Data processors * Retention periods * Logging * Training use * Deletion procedures * Jurisdiction * Encryption * Employee access * Incident-response procedures Use: \[DATA RETENTION POLICY] before publication. ### Open-source software Open-source code improves inspectability. It does not prove that a hosted deployment runs the published code. World should publish: * Reproducible builds * Signed releases * Contract addresses * Version identifiers * Deployment attestations where available * Source-code repositories * Build instructions * Release hashes *** ## Audits and source code Agent-specific contracts and systems require separate security review. Publish: * Agent policy contract source * Wallet-module source * Policy compiler source * Policy renderer source * Typed-intent schemas * Execution-engine source * Audit reports * Deployed bytecode hashes * Contract addresses * Supported versions * Known issues * Bug-bounty details * Upgrade authorities * Emergency procedures Links: Smart-contract audits: \[AUDIT LINKS] Source code: \[SOURCE CODE LINK] Policy-manager address: \[POLICY MANAGER ADDRESS] Wallet implementation: \[WALLET IMPLEMENTATION] *** ## Professional controls Professional users may use the advanced agent interface to: * View exact encoded policies * Download policy JSON * Verify the policy hash * Select contract allowlists * Select function allowlists * Restrict decoded calldata parameters * Set asset-specific exposure limits * Configure counterparty restrictions * Configure rolling-period limits * Require multiple approvers * Use a Safe or institutional wallet * Create separate policies for separate wallets * Create multiple agent signers * Rotate credentials * Use a self-hosted runtime * Use an SDK * Use an API * Use a CLI * Use MCP-compatible tools * Configure webhooks * Export activity logs * Run independent simulations * Submit direct revocation transactions * Run the open-source World interface locally Professional users should not be forced to rely only on the human-readable policy summary. *** ## Activity receipts Every material agent action should generate a receipt containing: * Receipt ID * Timestamp * User instruction * Agent intent * Owner wallet * World account * Agent signer * Policy ID * Policy hash * Contracts called * Orders placed * Assets moved * Borrowing * Repayment * Estimated result * Actual result * Margin before * Margin after * Gross exposure before * Gross exposure after * Net exposure before * Net exposure after * Fees * Gas * Slippage * Transaction hash * Policy checks passed * Policy checks rejected * Failure reason * Agent explanation The explanation is informational. The transaction, policy, and onchain state remain authoritative. *** ## Frequently asked questions ### Does the agent own my assets? No. The owner wallet remains the highest authority. The agent receives limited signing authority. ### Does activation move my funds? No. Activation creates permission. Funds move only when the agent later performs an allowed action. ### Do I need a separate World wallet? Not when the connected wallet supports portable delegation. An unsupported wallet may require a portable smart account or another wallet. ### Can the agent deposit without asking me to sign? Yes, when the deposit is inside the wallet policy and World policy. ### Can the agent approve tokens? Yes, but only for approved tokens, contracts, amounts, and limits. ### Can the agent withdraw? It may return assets only to the predetermined owner wallet or another destination explicitly approved by the owner. ### Can the agent send funds to an attacker? The default policy prohibits arbitrary transfers. A contract, wallet, policy, implementation, signer-provider, or oracle failure may still result in loss. ### Can the agent increase its own limit? No. ### Can the agent add a new protocol? No. The owner must authorize each additional protocol. ### Can the agent use another wallet? Only after that wallet separately authorizes it. ### Can I use the same agent outside World? Yes, when another protocol supports the agent and the wallet grants a separate policy. World’s policy does not govern another protocol. ### Is Telegram holding my key? No. Telegram is an instruction interface. ### What happens if Telegram is hacked? An attacker may instruct the agent within the current policy. Pause the agent, secure Telegram, review activity, and rotate or revoke the signer when necessary. ### What happens if the signer provider is offline? The agent may be unable to act. Existing positions and obligations remain. The owner wallet retains ultimate control. ### Does pausing close my positions? No. Pause stops ordinary new agent actions. Use Risk reduction only or Return funds when positions still require management. ### Can the policy prevent all losses? No. It restricts the agent’s actions but cannot eliminate: * Market risk * Liquidation risk * Liquidity risk * Counterparty risk * Smart-contract risk * Oracle risk * Network risk * Wallet risk * Signer-provider risk ### Can I revoke the agent? Yes. The owner can revoke the agent without the agent’s cooperation. ### Does revocation return all funds? No. Revocation removes authority. It does not automatically unwind positions or repay obligations. ### Can I export or migrate the wallet? This depends on the wallet and signer-provider implementation. The live documentation must describe the exact export and migration process. ### Does the agent pay gas? World may sponsor gas, use a relayer, or deduct gas according to the supported wallet implementation. The user should not need to sign routine gas transactions. ### Can World support recover my owner key? No support representative should ask for the owner private key or seed phrase. Recovery follows the connected wallet’s recovery model. ### Is World Agent financial advice? No. The agent’s analysis and actions are not guaranteed to be correct. Users remain responsible for their use of the protocol. *** ## Illustrative policy schema The final schema and contract ABI must be published separately. ```json { "version": "1.0", "chainId": 1, "ownerWallet": "0xOWNER", "agentSigner": "0xAGENT", "walletPolicy": { "allowedContracts": [ "0xWORLD_POLICY_MANAGER", "0xWORLD_ROUTER" ], "allowedAssets": [ "0xTOKEN_1", "0xTOKEN_2" ], "returnAddresses": [ "0xOWNER" ], "maxDeployedCapitalUsd": "10000", "arbitraryTransfersAllowed": false, "ownershipChangesAllowed": false, "recoveryChangesAllowed": false, "newSignersAllowed": false, "newProtocolsAllowed": false }, "worldPolicy": { "allowedMarkets": [ "ETH_USDM_SPOT", "ETH_USD_PERP", "USDM_LENDING" ], "maxGrossExposureUsd": "20000", "minAvailableMarginRatio": "0.40", "maxNetExposure": { "ETH": "2" }, "maxBorrowPrincipalUsd": "5000", "maxBorrowApr": "0.08", "maxExecutionCostUsd": "100", "maxSlippageBps": "30", "maxDailyTurnoverUsd": "25000", "riskReductionOverride": true }, "communication": { "telegramAccountHash": "0xHASH" }, "activeFrom": 1784505600, "expiresAt": null, "nonce": "1" } ``` The Telegram username should not be stored publicly onchain. Use a privacy-preserving identifier or keep communication metadata offchain. *** ## Launch checklist Before publishing, replace and verify: 1. \[SIGNER PROVIDER] 2. Who operates the online agent runtime 3. Where the runtime credential lives 4. Supported wallets and versions 5. Whether EIP-7702 same-address operation is supported 6. Exact smart-account implementation 7. Wallet contract addresses 8. Policy contract addresses 9. Contract bytecode hashes 10. Default risk limits 11. Capital-valuation methodology 12. Supported assets 13. Supported markets 14. Token-approval behavior 15. Gas and relayer behavior 16. Telegram bot handle 17. Pairing process 18. Account-recovery process 19. Pause semantics 20. Resume semantics 21. Risk-reduction precedence 22. Revocation semantics 23. Provider export process 24. Provider migration process 25. Provider outage procedure 26. World interface outage procedure 27. Data processors 28. Data-retention policy 29. Audit reports 30. Source-code repositories 31. Known issues 32. Regulatory restrictions 33. Support contact 34. Incident-response contact 35. Emergency direct-contract instructions *** ## Final principle The agent should handle routine execution. The owner wallet should control authority. The policy should remain enforceable even when the agent runtime, Telegram account, or model behaves incorrectly. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.world.inc/ai-agents/world-agent.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.