EmbarkAI Dashboard

Web console for managing projects, API keys, server wallets, paymaster policies, and usage analytics.

The Dashboard at dashboard.lumiapassport.com  is where you configure everything the SDK needs at runtime — project IDs, API keys, the wallets your backend controls, and the paymaster policies that gate gas sponsorship.

Projects

A project is the top-level unit in the Dashboard. It groups one set of credentials, networks, and policies and maps 1-to-1 to the projectId you pass to the SDK:

<Provider projectId={process.env.NEXT_PUBLIC_PROJECT_ID!} chainId={994873017}>
  {/* ... */}
</Provider>

For backend usage, the project’s API key goes into EMBARK_API_KEY:

createServerWalletManager({
  apiKey: process.env.EMBARK_API_KEY!, // generated in Dashboard → API Keys
  chainId: 994873017,
})

Typical setup: one project per environment (development, staging, production). Each project has independent API keys, wallets, and policies, so you never mix test limits with prod limits.

API Keys

Under Project → API Keys you can create, rotate, and revoke keys used by:

• @embarkai/core (EMBARK_API_KEY env var) for createServerWalletManager and createLumiaPassportCore
• @embarkai/mcp (EMBARK_API_KEY) for the MCP server binary
• Direct REST calls from your backend (if you bypass the SDKs)

Keys are secrets — treat them like database credentials. Rotate them if they leak and never commit them to a repo.

Server Wallets

Under Project → Server Wallets you can browse the MPC wallets your backend has registered via ServerWalletManager.createWallet(walletId). Each row shows:

• Wallet ID (your opaque string)
• Smart-account address per chain
• Owner (EOA) address and registration timestamp
• Last transaction and balance snapshot

The Dashboard is read-only for wallets — creation and signing still happen through the SDK with your keyshares. This view is for auditing and operations.

Wallet Policies

Under Project → Policies you define per-network rules that apply to every UserOperation sent from your project’s wallets. Each policy has:

Policies are evaluated server-side when the bundler receives a UserOperation. An op that violates any limit or isn’t on the allowlist is rejected before it reaches the chain — so you never accidentally sponsor gas for an arbitrary contract.

This is the mechanism you use to move from the rate-limited built-in Paymaster to a production-grade custom Paymaster with explicit guardrails. See Paymaster & Gasless Transactions for the on-chain side of the story.

Typical policies

• “Only our contracts” — allowedContractAddresses set to your app’s deployed contracts; enablePaymaster: true; reasonable monthly cap.
• “Power users” — higher limitPerDay for a wallet subset (implement by splitting users into a separate project or managing wallets differently).
• “Dry-run” — enablePaymaster: false; policy exists only to enforce contract allowlists without sponsorship.

Analytics

Under Project → Analytics you see UserOperation volume, success rate, gas consumed, and Paymaster spend. Useful for:

• Watching monthly Paymaster burn before it hits the policy cap.
• Spotting spikes in failed ops (typically policy-rejected or out-of-gas).
• Sizing rate limits from real traffic rather than guesses.

Environments & Access

• The Dashboard itself is hosted at dashboard.lumiapassport.com .
• Log in with the same account you use for the EmbarkAI-backed apps.
• Admin-only views (ecosystem-wide Paymaster monitor, user administration) are not shown to project owners.

Next Steps

• Paymaster & Gasless Transactions — how Paymasters work on-chain, and how to pick built-in vs. custom
• Server Wallets — the SDK side of wallet creation
• Getting Started: Backend — end-to-end backend setup including project + API key creation