> ## Documentation Index > Fetch the complete documentation index at: https://docs.0xmonaco.com/llms.txt > Use this file to discover all available pages before exploring further. # Register a deposit address for monitoring > Register a deposit address for monitoring. Every (application, user, deposit target) triple has a deterministic deposit address — the SAME address on every supported chain. This registers the caller's own address so the sweeper service watches it on every chain it is configured for (`get_sweeper_chains` lists the set) and automatically forwards every supported deposit into the exchange, crediting the caller under the application. One registration covers all supported chains — there is nothing chain-specific to choose. Authenticated, and the whole identity comes from the session: the application is the one `login` established the session under, and the credited address is the session's own. Neither is a request parameter, so a caller can only ever register their own address under their own application. The body carries only which ledger to aim at. Registration also runs a one-time initial check in the background: any balance already sitting on the address, on any supported chain, is swept without waiting for a new transfer. The response returns immediately with the derived address; it does not wait for that check. Idempotent and safe to retry: re-registering an existing triple returns `already_registered` with the same address and never re-triggers the initial check. Globally rate-limited: registration creates durable state, so the endpoint admits a bounded number per minute across all callers and answers `429` beyond it. ## OpenAPI ````yaml /proto-openapi/api/openapi.yaml post /api/v1/sweeper/register openapi: 3.0.3 info: title: Monaco Protocol API description: REST API for the Monaco Protocol hybrid CLOB exchange. version: 1.0.0 servers: - url: https://staging.apimonaco.xyz description: Staging server (Testnet) security: [] tags: - name: AccountsService - name: ApplicationsService - name: AuthService - name: BuildercodeRewardsService - name: CopyTradingService - name: DelegatedAgentsService - name: FaucetService - name: FeesService - name: HealthService - name: ManagedMarketsService description: |- Wallet-authenticated maker assignments. The signed session must match both configured maker user and application. Owner IDs are process fences, never auth. Only wallet sessions are supported; delegated-agent sessions receive 403. - name: MarginAccountsService description: |- Current public isolated-margin semantics: - a user has one parent margin account per application scope - opening orders create or reuse isolated position buckets under that parent - parent account creation is handled internally by margin workflows - name: MarketService - name: OrderbookService - name: OrdersService - name: PositionsService description: |- Current public isolated-margin semantics: - positions link to a parent margin account and, when applicable, a bucket id - opening orders create or reuse isolated position buckets under the parent - users can open another isolated position by reusing the parent account with a different market bucket - name: PulseService - name: SweeperService - name: TraderCodeService - name: TradesService - name: WhitelistService - name: WithdrawalsService paths: /api/v1/sweeper/register: post: tags: - SweeperService - Sweeper summary: Register a deposit address for monitoring description: |- Register a deposit address for monitoring. Every (application, user, deposit target) triple has a deterministic deposit address — the SAME address on every supported chain. This registers the caller's own address so the sweeper service watches it on every chain it is configured for (`get_sweeper_chains` lists the set) and automatically forwards every supported deposit into the exchange, crediting the caller under the application. One registration covers all supported chains — there is nothing chain-specific to choose. Authenticated, and the whole identity comes from the session: the application is the one `login` established the session under, and the credited address is the session's own. Neither is a request parameter, so a caller can only ever register their own address under their own application. The body carries only which ledger to aim at. Registration also runs a one-time initial check in the background: any balance already sitting on the address, on any supported chain, is swept without waiting for a new transfer. The response returns immediately with the derived address; it does not wait for that check. Idempotent and safe to retry: re-registering an existing triple returns `already_registered` with the same address and never re-triggers the initial check. Globally rate-limited: registration creates durable state, so the endpoint admits a bounded number per minute across all callers and answers `429` beyond it. operationId: register_deposit_address requestBody: content: application/json: schema: $ref: '#/components/schemas/RegisterRequest' required: true responses: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/RegisterResponse' '400': description: Invalid request parameters '401': description: Authentication required '403': description: The application for this session is not active '429': description: Registration admission limit exceeded; retry shortly '500': description: Internal server error '503': description: >- Sweeper unavailable (not configured or resolver down); nothing was registered, safe to retry security: - monacoSignature: [] - monacoHttpSignature: [] components: schemas: RegisterRequest: type: object properties: depositTarget: example: MARGIN enum: - SPOT - MARGIN type: string description: >- Which ledger swept deposits are requested to be credited to. `SPOT` (the default when omitted) credits the spot wallet; `MARGIN` asks for the parent margin account's collateral, skipping the separate collateral transfer. The target is part of the address derivation, so `SPOT` and `MARGIN` yield two different deposit addresses for the same pair, and each address carries its own request. `MARGIN` is a routing request rather than a guarantee: a deposit the matching engine cannot route to collateral — an unsupported collateral asset, or a margin account that fails validation — is credited to the spot wallet instead, so funds are never stranded. A `SPOT` address is never credited to margin. nullable: true additionalProperties: false RegisterResponse: type: object properties: status: example: registered enum: - registered - already_registered type: string description: >- `registered` when the triple was added, `already_registered` when it was known before this call nullable: true sweeperAddress: example: '0xcf1eF339798914EF7Ee4984Ed45BD141D63a65C9' type: string description: >- The deposit address for this (application, user, deposit target) triple. Stable, and valid to publish and fund before any contract exists there. nullable: true initialSweepCheck: example: false type: boolean description: >- Whether the one-time registration balance check has completed. `false` right after a fresh registration; it runs in the background and flips once every pre-existing balance has been swept. nullable: true securitySchemes: monacoSignature: type: apiKey description: >- Ed25519 session-key request signing. Every authenticated request carries three headers: `X-Monaco-PublicKey` (64-char lowercase-hex session public key), `X-Monaco-Timestamp` (Unix milliseconds, within 30s of server time), and `X-Monaco-Signature` (hex ed25519 signature). The signature is over `METHOD\npath?query\ntimestamp_ms\nSHA256_hex(body)`, where the body hash is the SHA-256 of the empty byte string when there is no body. Obtain the session keypair from `POST /api/v1/auth/challenge` followed by `POST /api/v1/auth/verify`. name: X-Monaco-Signature in: header monacoHttpSignature: type: apiKey description: >- RFC 9421 Ed25519 session-key request signatures. Send Signature-Input, Signature, and Content-Digest together; never combine them with X-Monaco-* credentials. The monaco signature covers @method, @path, @query, and content-digest in that order, with created (Unix seconds within 30s of server time), keyid (registered lowercase-hex session public key), and alg=ed25519 parameters. Content-Digest uses RFC 9530 sha-256 over the exact body bytes, including the empty body. Query coverage retains ordering and percent encoding. Timestamp freshness does not reject repeated identical requests; use endpoint idempotency where supported. Existing legacy signing remains supported during server-first migration; SDK RFC 9421 signing is opt-in. See https://docs.0xmonaco.com/reference/http-message-signatures for the complete profile and trust model. name: Signature in: header ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.