Security

Bankr x402 Cloud is designed with security as a foundation. Your code, secrets, and revenue are protected by multiple layers of isolation and encryption.

Environment Variable Protection

When you store environment variables via bankr x402 env set, they are:

• Encrypted at rest — stored in an encrypted, isolated configuration scoped to your account
• Scoped per user — each user's secrets are stored in an isolated namespace. No other user, their endpoints, or other Bankr services can access them. Every endpoint you deploy receives all of your x402 env vars.
• Never logged — secret values are never written to application logs or any monitoring system
• Never returned via API — the GET /env endpoint and dashboard only return variable names, never values
• Available immediately — env vars are available via process.env as soon as you set them. No separate decryption step is needed.

What You See in the Dashboard

The dashboard shows:

WEATHER_API_KEY    [Remove]
DB_CONNECTION_URL  [Remove]

Values are never displayed, transmitted to the browser, or included in API responses. When you set a new variable via the CLI or dashboard, the value is sent over HTTPS and written to your account's encrypted configuration — it is never stored in Bankr's database.

How Secrets Reach Your Handler

CLI / Dashboard ──► API ──► Encrypted Config ──► process.env.YOUR_KEY

Env vars are written to your service's configuration at deploy time (or when you run env set). They are available immediately via process.env — no separate decryption step, no secrets service, and no network fetch at runtime.

Invalid or reserved keys are rejected before being stored — see the key rules.

Code Execution Isolation

Each deployed endpoint runs in its own isolated execution environment with:

• Dedicated compute — your handler runs in its own serverless function, completely separate from other users' handlers and from Bankr's own infrastructure
• Minimal permissions — each endpoint only has permission to write logs. It has no access to Bankr's backend systems, databases, or other users' secrets.
• No shared state — there is no shared filesystem, memory, or network namespace between endpoints. One user's endpoint cannot access another user's code, data, or secrets.
• Resource limits — each endpoint has bounded memory (256 MB) and execution time (30 seconds) to prevent abuse. Handlers that exceed the timeout will return a 503 error to the caller and the payment will not be settled

What Your Code Can Do

Action	Allowed
Make outbound HTTP requests	Yes
Read process.env variables	Yes (your own only)
Write to /tmp (ephemeral)	Yes (cleared between invocations)
Access other users' secrets	No
Access Bankr's backend	No
Access other Bankr systems	No

Payment Security

Settle-After-Response

Payments are only settled on-chain after your handler returns a successful response (status code < 400). If your handler throws an error or returns a 4xx/5xx, the payment is not collected. This protects callers from paying for failed requests.

Cryptographic Verification

Every payment goes through a three-step verification process:

1. Signature verification — the payment authorization is cryptographically verified using the EIP-712 standard, confirming the payer's wallet actually signed the payment
2. Amount verification — the payment amount matches or exceeds the endpoint's configured price
3. On-chain settlement — the verified payment is submitted to the Base blockchain, where the smart contract enforces that funds move exactly as authorized

Payment verification and settlement are handled by a dedicated facilitator service — your handler code never touches payment logic. The verified payer's wallet address is available to your handler via the x-402-payer header (see Examples → Identifying the Payer).

The facilitator's verify and settle operations are authenticated and rate-limited: each call carries a short-lived token bound to the specific endpoint being paid for, and settlement pays out to the address on that endpoint's record rather than anything supplied in the request. The facilitator URL returned in a 402 response tells payment clients which facilitator handled the quote; those two operations are driven by Bankr's router, not called directly by payers or by your handler.

Fee Transparency

The platform fee is split out on-chain during settlement and your share goes directly to your configured wallet on Base — see Pricing for the rates.

Authentication & Authorization

Management API

All endpoint management operations (deploy, configure, pause, delete, env vars) require authentication via your Bankr API key. The API verifies:

• The API key is valid and active
• The requesting user owns the endpoint being modified
• Operations are scoped to the authenticated user's endpoints only

User A cannot view, modify, or delete User B's endpoints or secrets.

Dashboard

The x402 dashboard at bankr.bot/x402 requires authentication via Privy (email, SMS, Twitter, Farcaster, or Telegram). All data displayed is scoped to the authenticated user.

Network Security

• All traffic is encrypted via TLS 1.2+
• HTTPS is enforced — plaintext HTTP is not accepted
• CORS is configured to allow cross-origin requests for agent compatibility
• Rate limiting is applied at the gateway level

Data Retention

• Request logs (including console output) are retained for 90 days, then automatically deleted
• Environment variables persist until you delete them — deleting an endpoint leaves them in place
• Endpoint code (bundled handlers) is stored encrypted.

Reporting Vulnerabilities

If you discover a security vulnerability in x402 Cloud, please report it responsibly: file a report at the Bankr Help Center (Request Type: Bug Bounty / Vulnerability). For Critical issues only, also email security@bankr.bot. See the Bug Bounty & Vulnerability Policy.