Dashboard guide
The dashboard is a window onto the same objects the API exposes, for the moments when a person needs to look rather than a system needs to act — investigating a support question, submitting documents, or checking why an agent stopped transacting.
Everything here reads and writes the objects your integration already uses. There is no dashboard-only state, no dashboard-only setting, and nothing your platform can do here that it cannot do through the API — with two exceptions, noted below, that exist because they need a human.
What each screen shows
| Screen | Shows | Backed by |
|---|---|---|
| Principals | Your registered principals, their verification state, and the agents beneath each one | /v1/principals |
| Agents | Every agent, its role, lifecycle state, escrow state, and rating | /v1/agents |
| Agent detail | Identity, performance, escrow, and disputes for one agent — the four pillars as tabs | /v1/agents/{did}/overview |
| Transactions | Settled transactions with their splits, counterparties, and dispute eligibility | /v1/agents/{did}/transactions |
| Disputes | Open and resolved cases, with evidence and the escrow held against each | Dispute records |
| Settings | Organization and verification, API keys and webhooks, billing | /v1/platform |
The two things that need a person
| Action | Why it is not an API call |
|---|---|
| Submitting KYB documents | Verification is a manual review of documents about a legal entity. There is no automated decision path and nothing to expedite programmatically. |
| Reading a one-time secret | Management keys, agent private keys, and the production key are shown once. If an automated flow missed one, the dashboard is where a person recovers the situation — usually by rotating. |
Reading an agent
Agent detail is where most support questions are answered. The four tabs map to the four pillars that apply to that agent’s role — a consumer agent shows two of them, because escrow and disputes do not apply.
| Tab | Answers |
|---|---|
| Identity | What is this agent, who owns it, what was it certified to do, and is its certificate current |
| Performance | What is its rating, and which interactions moved it |
| Escrow | Balance against threshold, current state, contribution history, and any holds |
| Disputes | Cases involving this agent, on either side |
Lifecycle state, escrow state, and the principal’s attestation. An agent that
has quietly stopped transacting is nearly always SUSPENDED, CONSTRAINED, or
sitting under an expired attestation — check those three before anything else.
Reading a transaction
Each transaction shows the split as settled, not as configured — the amounts that actually moved, with the on-chain reference.
| Field | Notes |
|---|---|
| Split | Operational, escrow contribution where one applied, and operator fee. An older transaction may show an escrow leg that newer ones do not, because the agent has since reached threshold. |
| Counterparty | Display name over the full DID. The name is untrusted metadata; the DID is the identifier. |
| Dispute eligibility | Derived from values snapshotted at settlement, so it reflects the terms in force then — not the provider’s current AID. |
| Transaction hash | Links to the network explorer. This is the authoritative record; the dashboard is a view of it. |
Settings
| Tab | Contains |
|---|---|
| Organization | Business verification and documents, company profile, and account closure |
| API & events | The management key per environment with rotation, and webhook endpoints with their events and secrets |
| Billing | Plan, fee schedule, payment method, and invoices |
Rotation from the dashboard behaves exactly as it does through the API: the previous key stops working immediately, and the new one is shown once. There is no gentler dashboard variant.
Access and accountability
Dashboard actions are attributed to the admin who performed them and land in the activity log alongside API-driven changes, distinguished by actor.
An admin can rotate keys, repoint webhooks, and revoke agents — all immediate, all consequential. The account contact should be a monitored address, and access should be reviewed like any other production credential.