> ## Documentation Index > Fetch the complete documentation index at: https://docs.agg.market/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > To integrate AGG, start with Quickstart: REST (https://docs.agg.market/quickstart/rest), then Order lifecycle & statuses (https://docs.agg.market/concepts/order-lifecycle). > Track every trade until it reaches a terminal status. Before retrying a failed or timed-out call, read Errors, retries & idempotency (https://docs.agg.market/concepts/errors). > The API reference is generated from https://docs.agg.market/openapi/openapi.json. # Accounts & wallets > How a user's sign-in identity, managed wallet, self-custody wallets, and venue accounts relate, and which address to pass where A user signs in with one or more identities. Funds sit in one of several places: a managed wallet AGG signs for, the user's own wallet, or an account on a single venue. This page names each one and links to the page that owns its procedure. ## Sign-in identity vs trading wallet A person has one AGG user per app. That user can have several sign-in identities: Ethereum and Solana wallets, Google, Twitter, Apple, and email. Add more with [Account linking](/recipes/account-linking). One identity belongs to one AGG user; linking it to a second user returns `409`. Signing in does not choose where funds are held. A wallet used to sign in is only a self-custody trading wallet when you pass it as `signingAddress`. Without that, every trade uses the managed account. ## Managed account Each user gets a managed wallet with two addresses: `evmAddress` and `svmAddress`. AGG holds the keys and signs every trade, bridge, and withdrawal. The user does not sign anything. * `evmAddress` receives on every supported EVM chain and on Hyperliquid. * `svmAddress` receives on Solana. * Balances are tracked per chain and per token. A trade can spend from any chain; AGG moves the funds to the venue it routes to. ```ts SDK theme={null} const deposit = await client.getDepositAddresses(); if (deposit.ready) { console.log(deposit.evmAddress, deposit.svmAddress); } ``` ```bash cURL theme={null} curl https://api.agg.market/execution/deposit-addresses \ -H "x-app-id: $AGG_APP_ID" \ -H "Authorization: Bearer $ACCESS_TOKEN" ``` [Get deposit addresses](/api-reference/funding/get-deposit-addresses). It returns `{ "ready": false }` until the addresses exist; [Funding & withdrawals](/concepts/funding) owns the poll, balances, and withdrawals. **Privy wallet provider.** When your app uses Privy as its wallet provider, the managed wallet is the user's own Privy wallet instead of one AGG creates. AGG still signs, through the authorization key you saved, with no user present. `evmAddress` is that Privy wallet. See [Privy wallet provider](/recipes/privy-wallet-provider). ## Self-custody The user keeps their own key. Their EVM wallet, an **EOA**, must first be linked to the account with [Account linking](/recipes/account-linking). Quotes and fills name it as `signingAddress`. AGG prices the route against that wallet's balances and asks it to sign each step. A Solana wallet cannot be a `signingAddress`. `fundingAddresses` names other linked EVM wallets the same trade may spend from. The signing wallet still signs the venue order; each funding wallet signs only the transfers of its own money. Self-custody is supported on these venues. Any other venue is refused at fill time. | Venue | Where the funds are | Who signs | | - | - | - | | Polymarket | The EOA, its Polymarket deposit wallet on Polygon, and a legacy Polymarket wallet if one exists | The EOA | | Hyperliquid | The EOA's own Hyperliquid balance | The EOA. Where enabled, an agent named `agg` that the EOA approved may sign orders and cancels. An agent cannot move funds. | | Kalshi | The user's own Kalshi account | AGG, with the user's Kalshi API key from [Venue keys](/recipes/venue-keys). No wallet prompt. | **Polymarket deposit wallet.** Each linked EOA has one Polymarket deposit wallet. Its address is derived from the EOA and stays fixed once AGG records it. Polymarket orders are placed from it. A self-custody Polymarket limit order needs it to exist already. **Legacy Polymarket wallets.** Some users have a wallet Polymarket created before AGG, owned by their EOA. AGG finds it and reads its balance. There are two kinds: * **Legacy Safe**: a Gnosis Safe. Its balance can fund a trade on any venue. The EOA approves moving funds out of it with a `safe_tx` signature. * **Legacy proxy**: its balance can only be spent on Polymarket. Nothing moves it to another venue, and self-custody limit orders are refused for a wallet that has one. `GET /execution/balances?custody=self` lists each of these with a `custodyKind` of `EOA`, `DEPOSIT_WALLET`, or `POLYMARKET_LEGACY`, plus `legacyKind`. A `proxy` row still counts in the token's `totalRaw` and `availableRaw`; subtract it to show what can be spent elsewhere. Kalshi cash does not appear in this view. Procedures: [Self-custody trading](/recipes/self-custody) and [Self-custody signing reference](/recipes/self-custody-signing). ## Venue accounts Some balances live inside a single venue and can only be spent there. * **BetDEX hosted account.** AGG creates and runs a BetDEX account for the user. It has its own Solana USDC deposit address, separate from the managed balance. See [Hosted venue accounts](/recipes/hosted-venue-accounts). * **ProphetX and Novig direct accounts.** When your app's execution mode for that venue is `direct`, the user stores their own venue credentials with `PUT /venue-keys` and trades with that account's cash. AGG does not deposit, withdraw, or redeem those funds. See [Market resolution](/concepts/market-resolution). * **Kalshi account.** The user's own Kalshi account and API key, stored with [Venue keys](/recipes/venue-keys). Every Kalshi trade, managed or self-custody, spends that account's cash. See [Kalshi](/venues/kalshi). ## Which mode, at a glance | Mode | Funds held in | Who signs | Address you pass | | - | - | - | - | | Managed | The managed wallet | AGG | None | | Privy wallet provider | The user's Privy wallets | AGG, with your Privy authorization key | None | | Self-custody | The user's EOA and its Polymarket deposit and legacy wallets | The user's wallet | `signingAddress`, optionally `fundingAddresses` | | Kalshi | The user's Kalshi account | AGG, with the user's Kalshi key | None. In a self-custody route, `signingAddress` as usual. | | BetDEX hosted account | A BetDEX account AGG hosts | AGG | None. Deposit to the hosted account's address. | | ProphetX or Novig direct | The user's own venue account | AGG, with the user's venue key | None | Compare the trading flows in [Choose your integration](/integration-options). ## Glossary | Term | Meaning | | - | - | | EOA | An externally owned account: an ordinary EVM wallet controlled by one private key. The user's linked wallet in self-custody. | | Signing address | The linked EOA passed as `signingAddress` on a quote or fill. It signs the venue order. | | Funding address | A linked EVM wallet passed in `fundingAddresses`. It pays part of the trade and signs only its own transfers. | | Deposit address | `evmAddress` or `svmAddress` from `GET /execution/deposit-addresses`, where the user sends funds to the managed account. A hosted BetDEX account has its own. | | Deposit wallet | The Polymarket deposit wallet on Polygon, derived from one EOA. Polymarket orders are placed from it. | | Managed wallet | The wallet AGG holds keys for and signs with. With the Privy wallet provider, it is the user's Privy wallet. | | Legacy Safe | A Gnosis Safe Polymarket created for the user before AGG. Its balance can fund any venue. | | Legacy proxy | An older Polymarket proxy wallet. Its balance can only be spent on Polymarket. | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.