> ## 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. # Create authentication challenge > Create authentication challenge. Generate a cryptographic challenge (nonce) for wallet-based authentication. The wallet must authorize the returned message to prove control of the address. An EOA does that by signing it with its private key. A smart-contract wallet has no private key and instead produces a signature its own contract will accept, which Monaco checks under EIP-1271 — see Verify. The challenge is single-use and binds the session public key supplied here, so it authorizes exactly one keypair, once. The lifetime is 5 minutes, or 30 minutes for EVERY address while contract-signature login is enabled on the deployment — a multisig must collect owner approvals before it can answer, and the window is uniform rather than eligibility-specific so this unauthenticated endpoint cannot be used to probe which addresses hold a BuilderCodes payout bucket. Widening it is cheap: a longer window is a longer-lived offer to authorize one predetermined keypair once, never a longer-lived credential. ## OpenAPI ````yaml /proto-openapi/api/openapi.yaml post /api/v1/auth/challenge 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/auth/challenge: post: tags: - AuthService - Auth summary: Create authentication challenge description: |- Create authentication challenge. Generate a cryptographic challenge (nonce) for wallet-based authentication. The wallet must authorize the returned message to prove control of the address. An EOA does that by signing it with its private key. A smart-contract wallet has no private key and instead produces a signature its own contract will accept, which Monaco checks under EIP-1271 — see Verify. The challenge is single-use and binds the session public key supplied here, so it authorizes exactly one keypair, once. The lifetime is 5 minutes, or 30 minutes for EVERY address while contract-signature login is enabled on the deployment — a multisig must collect owner approvals before it can answer, and the window is uniform rather than eligibility-specific so this unauthenticated endpoint cannot be used to probe which addresses hold a BuilderCodes payout bucket. Widening it is cheap: a longer window is a longer-lived offer to authorize one predetermined keypair once, never a longer-lived credential. operationId: create_challenge requestBody: content: application/json: schema: $ref: '#/components/schemas/ChallengeRequest' required: true responses: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/ChallengeResponse' '400': description: Invalid request parameters '403': description: Origin not allowed for this application '404': description: Invalid clientId '429': description: >- Authentication rate limit exceeded — challenge and verify share one per-client-address budget (60 requests/min sustained, burst 120); retry after the interval in details.retryAfter '500': description: Internal server error components: schemas: ChallengeRequest: required: - address - sessionPublicKey type: object properties: address: example: '0x742d35Cc6634C0532925a3b8D4060f31E2C3d8B5' maxLength: 42 minLength: 42 pattern: ^0x[0-9a-fA-F]{40}$ type: string description: Ethereum wallet address clientId: example: monaco-frontend type: string description: Optional application identifier nullable: true chainId: example: '1328' type: string description: Optional chain ID supplied by SDK clients nullable: true sessionPublicKey: example: 3b6a27bcceb6a42d62a3a8d02a6f0d73653215771de243a63ac048a18b59da29 maxLength: 64 minLength: 64 pattern: ^[0-9a-f]{64}$ type: string description: >- Lowercase hex (64 chars) ed25519 public key generated locally by the SDK. The returned challenge message will embed this key so the wallet's signature binds it; the same value must be submitted to /api/v1/auth/verify. additionalProperties: false ChallengeResponse: type: object properties: nonce: example: abc123def456 type: string description: Unique challenge nonce nullable: true message: example: Sign this message to authenticate with Monaco Protocol... type: string description: Message to sign nullable: true expiresAt: example: 1699876543 type: integer description: Unix timestamp when challenge expires format: int32 nullable: true ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.