Dashboard tour
app.co-relayer.com is the dashboard. It is a single-page application that talks only to the
CoRelayer API — it never contacts a chain node directly, and it holds no key. Your wallet signs;
the dashboard builds the transactions to be signed and shows you what happened afterwards.
This page is a written tour rather than a gallery of screenshots. Screenshots of an application that has nothing to connect to would show empty states, which teaches nothing.
Getting in
| Screen | What happens |
|---|---|
| Connect | Choose a wallet. The dashboard learns your address and nothing else. Public screens work from here. |
| Welcome | Shown once, for an address with no plan: what the service does, what a Relay Unit is, and the way to the plan picker. |
Signing in properly — a native-auth login — happens the first time you open a screen that shows data only you should see. That is a signature over a short-lived message, not a transaction: it costs nothing and moves nothing.
The screens
Overview
The answer to "am I able to send transactions right now". It shows the active plan, Relay Units used against the cap, the period end, whether pay-as-you-go is on, and any notice the account has not acknowledged — a scheduled tariff change, a relayer draining, a lapsed renewal.
Plan
The tier ladder with your current plan marked, and what changing to another one would do. Prices
come from the contract through GET /v1/pricing; the page states the tariff they were computed
from. Checkout is a separate screen because it builds a transaction and asks for a signature.
The plan's own controls live here too: auto-renew (with the price ceiling you sign), pay-as-you-go and its escrow budget, and releasing the escrow back to credits. Each one that changes on-chain state builds a transaction, and the screen says so before you press it.
Billing and Deposit
Credits, purchases and the escrow. Deposit builds the USDC transfer that turns money into credits. Every purchase you have ever made is listed here, taken from the contract's own events, so the list cannot disagree with the chain.
Usage and Transactions
Transactions is the per-transaction view: one row per relayed transaction, with the intent state, the Relay Units it cost, the relayer that carried it and the time each stage took. A row opens into the full timeline of that one transaction.
Usage is the aggregate: units per day, split between plan cap and pay-as-you-go, and a CSV export for accounting. Totals come from a counter, not from counting pages, so the numbers do not drift as the history grows.
Latency
What the service did for your transactions: the time from your submission to co-signature, to first gateway acknowledgement, and to inclusion. It is a record of what happened, not a promise of what will happen — see Status and SLOs for why this site publishes no latency target.
Relayers
The relayers that served your account, and their current registry state. You can verify any of them against the chain yourself; the page tells you which view to call.
Senders
Named wallets: the addresses you know in advance that your plan pays for besides your own. Adding one is an on-chain change — the contract enforces the named-wallet limit of the plan you bought — so this screen builds a transaction for you to sign. Removing one is free. To pay for your users without listing them, use a sponsor key instead.
API keys
Sponsor keys: from Builder up, a key on your server pays for your users' transactions, only for
the contracts you list and within the daily limits you set. A key with only the read scope serves
headless reads. A key is shown once, at creation. Keys cannot create, change or revoke other
keys: that always needs your wallet. See Pay for your users and
Key handling.
Notifications
The notice inbox: every notice the account received, such as a scheduled price change, a skipped renewal or a cap threshold, newest first, marked read up to where you choose. New notices arrive while the screen is open. Your server can read the same notices from the notice feed or follow them on the account stream (Do not poll the cap).
The screen also keeps e-mail and webhook preferences. This deployment does not deliver webhooks or e-mail: registering a webhook endpoint answers 503 with reason: WEBHOOK_DELIVERY_NOT_AVAILABLE, and no e-mail is sent. The inbox, the
notice feed and the stream carry every notice.
Incidents
Anything the service has declared, with its own history. The public version of the same data is on the status site, which is deployed separately so that it survives an outage of the API.
Settings
Appearance (theme), the session — who is signed in and until when — the data export, and the facts of the build you are looking at: its environment, chain id and the API host in use. Nothing on Settings changes on-chain state.
What the dashboard never does
- It never signs for you, and it never asks for a second signature for one action. (One signature)
- It never invents a number. Every figure is a response from the API or a value read from the chain; where a value is a snapshot, the screen carries the date it was taken.
- It never silently retries a transaction with a new signature. If the service needs one, it asks, and it tells you what the previous attempt did — which, in that specific case, is nothing.