StablecoinX Paymaster — Operator Dashboard

Internal operator dashboard for the StablecoinX paymaster, the ERC-4337 service that sponsors gas for smart-account UserOperations on behalf of merchants. The dashboard is read-only: it aggregates what the paymaster has already sponsored on-chain and how much EntryPoint deposit remains to keep sponsoring. Sign-in is restricted to StablecoinX operators, so there is no public surface here and no expectation that merchants or end users land on this page. Integrators never talk to this dashboard; they call the managed paymaster path on the merchant API described below and in llms.txt.

What the dashboard shows

The headline block reports the total gas sponsored across every configured chain, in ETH with a USD equivalent, alongside the number of sponsored operations and their success rate, the number of denied requests, and the gas spent in the selected time window. A window toggle switches every windowed figure between the last 24 hours, 7 days, 30 days and all time. Next to the totals sit the available EntryPoint deposit that can still be spent on sponsorship, the 24-hour burn rate in ETH and USD per day, and the resulting runway in days at the current burn, with the chain and paymaster version that would run dry first called out explicitly. A donut chart splits sponsored gas by chain or by paymaster version.

The By chain table lists every chain and paymaster contract the service operates, one row per chain and EntryPoint version, with the contract address, its current deposit and runway, operations and gas in the selected window, and the cumulative success rate. Totals come from EntryPoint UserOperationEvent logs on-chain rather than from the paymaster's own counters, so the table reflects what actually landed. The service operates paymasters for EntryPoint v0.8, v0.7 and v0.6, and each version appears here as its own row when it is deployed on that chain.

Recent activity is a feed of the latest sponsored UserOperations across all chains: when it landed, on which chain and paymaster version, the sender smart account, whether the operation succeeded or reverted, the gas it cost, and a link to the transaction on the chain explorer. Top senders ranks the smart accounts that burned the most paymaster gas in the selected window, with their operation count, success rate and last-seen time, which is where an operator first notices a single account draining a deposit. The overview refreshes automatically every 30 seconds, and a section that fails to load offers a retry.

Paymaster backend and integration path

The paymaster signing service itself is internal: the platform edge denies requests from outside the private network and only its health probe is public. Merchants integrate through the managed paymaster path on the merchant API, POST /v1/paymaster/rpc on the API host named in llms.txt, with a publishable client id in the X-Client-Id header. A pmc_live key sponsors mainnets and a pmc_test key testnets. The path implements the ERC-7677 methods pm_getPaymasterStubData and pm_getPaymasterData plus pm_sponsorUserOperation; every method takes the UserOperation, the EntryPoint address (v0.8, v0.7 or v0.6), the chain id and an optional context whose token field switches to gas paid by the user in an ERC-20, which pm_sponsorUserOperation refuses. A proxied bundler endpoint per chain, /v1/paymaster/bundler/{chainId}, keeps the third-party bundler key on the platform.

Before anything is signed the managed path checks the client's origin and chain allowlists and its gas mode, requires the call data to be execute(address,uint256,bytes), MetaMask's single execute((address,uint256,bytes)) call, or a direct batch through executeBatch(address[],uint256[],bytes[]) or ERC-7579 execute(bytes32,bytes) in BatchDefault mode, also accepts bounded MetaMask Advanced Permissions transfers through SingleDefault execution on Ethereum, Base, Arbitrum and their Sepolia testnets, applies the merchant's deny rules, requires the final token target of a delegated transfer, the direct execute target or every call target of a batch to be on the merchant's contract allowlist for that chain, requires a positive prepaid gas balance for sponsored mainnet operations, and applies per-sender limits. The harness platform defaults are 20 sponsored operations per hour and 50 USD per day per smart account plus a 500 USD daily budget across all merchants, with dollar caps off on testnets; a merchant can only tighten them. A policy refusal is a JSON-RPC error whose message starts with Policy denied, and a wallet must not fall back to another paymaster when it sees one. Denied requests are counted on this dashboard so operators can see policy pressure without reading service logs. The full error table and the per-chain paymaster and EntryPoint addresses are generated from the platform code into llms-full.txt.

Machine consumers, privacy and security

For machine consumers, a robots.txt explicitly allows GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and other major AI crawlers. A sitemap.xml lists the public route, and an llms.txt summarises the managed paymaster endpoints, networks and sponsorship rules for direct LLM retrieval, with llms-full.txt carrying the full reference, error table and per-chain contract addresses. Programmatic control of a merchant account, including managed-paymaster clients and their allowlists, is available through the official StablecoinX MCP server.

The dashboard does not register accounts, set tracking cookies, or persist anything beyond the signed-in operator session in browser-local state. The paymaster backend logs request metadata such as sender address, chain id and sponsored gas amount for observability and policy enforcement; addresses are inherently public on-chain and no off-chain identifiers are collected. Vulnerability reports go to tech@e2xlabs.com, with a machine-readable contact published at /.well-known/security.txt.