Explorer

It is the quickest way to answer "what did the ledger actually record?" without writing a program to ask. That question comes up constantly while an application is being built, and it comes up again — usually under time pressure — when two systems disagree about a balance and somebody has to establish which of them is wrong.

Every tab that lists something can also create it, so a ledger can be set up and used end to end without writing any code. See what you can do from here.

What it showsLink to this section

Overview reports the totals the core keeps for the ledger — transactions, accounts, assets — alongside the most recent transactions and the sequence number of the latest one.

Transactions lists committed transactions, newest first, each with its sequence number, its timestamp, and how many actions it contains. Actions lists the individual movements inside those transactions: the type, the amount, the asset, and the accounts on either end.

Together they are the ledger's history. Tokens is its current state: holdings grouped by account, asset and token tags. Every figure there is derived from the actions that produced it, which is why a balance that looks wrong is usually a question about the history rather than about the balance.

Accounts and Assets show what has been created and, for each, the keys that control it and the quorum of signatures it requires. Keys lists key ids. Key material is held by the core and is never served to the console. Feeds shows each feed, its filter, and how far its consumer has acknowledged.

What you can do from hereLink to this section

Everything below requires the readwrite role; a readonly member sees the same lists without the controls. Each one posts the same RPC an SDK would, through the console's gateway, and the core authorizes it against your own credential — the console has no privileges of its own.

Keys creates a key. The core generates the material, keeps it, and returns an id.

Accounts and Assets create one, naming the keys that control it and the quorum of them that must sign. Both are fixed once the object exists.

Transactions builds and submits a transaction: one or more issue, transfer or retire actions, which settle together or not at all. Tokens offers the same thing from a holding — transfer or retire opens the builder with that account and asset already filled in.

Feeds creates a feed with a type and an optional filter, and deletes one. Deleting loses the acknowledged position, and a feed recreated with the same id starts at the head of the ledger rather than where the old one stopped.

Tags can be edited on accounts, assets and actions, from the row. The update replaces the whole object rather than merging into it, so the editor opens with what is there now and clearing it clears the tags.

What the console cannot do is anything the API cannot: an account's keys and quorum do not change, a settled action does not change, and a transaction is not deleted. Those are properties of the ledger, not omissions from this interface.

PrototypingLink to this section

While you are designing your model, the explorer is where you check that it holds up. Tag an account or an asset a particular way, issue a few tokens, and look at what the sum and list views can tell you afterwards — it is much cheaper to discover that a tag is in the wrong place before an application depends on it.

DebuggingLink to this section

As you develop, the explorer is the reference your application is checked against. When a balance is not what you expected, the actions view shows every movement that contributed to it, and the tags on each one show which part of your code submitted it.

Reading is what the explorer is for, but it is not all it does: an operator who has found the problem can usually fix it here too, and a transaction submitted from the Transactions tab is the same transaction an SDK would have submitted. What an application does in production still belongs in code.