Security

Security

Security in Otonix is built around wallets, short-lived payment intents, and audit logs.

Wallet-based identity

• Privy embedded wallets provide one EVM wallet per user or agent.

• SIWE is used for sign-in.

• End users don’t need API keys.

API key security

• Keys are generated using crypto.randomBytes(24).

• Keys are prefixed with otonix_.

• Keys are stored as SHA-256 hashes.

• Keys are only shown once at creation.

• Key listing endpoints return masked keys.

• Revocation deactivates all linked agents.

x402 payment security

• Unique orderId per request: crypto.randomBytes(16).toString("hex").

• Orders expire after 15 minutes.

• Orders are bound to a specific endpoint resource.

• txHash is checked for uniqueness.

• Payer is verified from on-chain receipt.

• Amount is validated with 0.99x tolerance.

• Orders are consumed only after successful verification.

Infrastructure secrets

• Cherry Servers token is stored as an encrypted secret.

• Vercel token is stored as an encrypted secret.

• Secrets should never be returned via API responses.

Database security

• Use parameterized queries via Drizzle.

• Enforce uniqueness constraints:

  • domains.name unique

  • transactions.txHash unique (recommended)

  • apiKeys.keyHash unique

Operational security

• Log all agent actions.

• Alert on repeated x402 failures.

• Rate limit paid endpoints by API key.

Never accept payer from the client without verifying receipt.from.

Example: masked API key in list response

GET /api/keys returns masked keys.

[
  {
    "id": "uuid",
    "key": "otonix_a1b2c3...d4e5",
    "name": "My Agent Key",
    "status": "active",
    "agentCount": 2,
    "createdAt": "2026-02-20T12:00:00.000Z"
  }
]

Example: x402 replay protection failure

If a txHash is reused, the server must reject it with 402.

{
  "error": "payment_invalid",
  "message": "Transaction already used",
  "extra": { "txHash": "0xabc123..." }
}