Skip to main content

Overview

When you obtain an API key from the Rhinestone dashboard and fund sponsorship there, any SDK client that embeds this key directly will leak this secret to the end user’s client (browser/wallet): an attacker could exfiltrate the key and use the Orchestrator to sponsor their own transactions. To prevent this, never expose your Rhinestone API key in the browser. Instead, proxy Orchestrator requests through a trusted server. The simplest option in a Next.js app is to use a Next Route Handler that forwards requests to the Orchestrator while enforcing your own allow/deny logic.
Do not store RHINESTONE_API_KEY in public client-side variables like NEXT_PUBLIC_*. Keep it server-only and validate/whitelist what gets proxied.

Approach

  • Use a server-side proxy that adds the x-api-key header.
  • Bypass the default SDK endpoint with your proxy URL.
  • Enforce contract and method-level allowlists as appropriate.
  • For this example, we whitelist ERC-20 transfer contracts on Base.

Next.js Route Handler (Proxy)

Create a dynamic API route at app/api/orchestrator/[...path]/route.ts:
Set RHINESTONE_API_KEY only on the server (e.g., in .env without NEXT_PUBLIC_).

Client Usage

Point the SDK to your proxy URL so user traffic never touches the Orchestrator directly:
You can then create an account and perform transactions as usual. For sponsored flows, set sponsored: true when sending a transaction.

Additional Hardening

  • Validate function selectors, token addresses, and chain IDs.
  • Add rate limiting and bot protection on the proxy route.

Example Code