Playground
The Playground imports @agntn/chains into the page and runs it in your browser. Every lookup, check and identify is the library's own answer, the same code the CLI and the agent tools run. Nothing is sent anywhere. The docs worker serves the page and that's the end of its involvement.
| Operation | Runs | Tool equivalent |
|---|---|---|
| Lookup | getChain(input) and every field on the class | chains_lookup |
| Validate | getChain(input).assertAddress(address) | chains_validate_address |
| Identify | identify(address) | chains_identify_address |
| List | chains().map(create), narrowed to one family | chains_list |
The chain field takes what getChain takes: a key, a display name or an alias. The sample chips load one chain's alias and a known good address for it, so the fastest way to see a rejection is to load a sample and change one character.
Every state is a link
The form writes itself into the address: /playground?op=validate&chain=btc&address=bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 opens the page on that answer. Paste it to someone and they see what you saw. The permalink button copies the current one.
The two snippets
Under the result the page prints the same call as a CLI line and as a tool invocation in JSON, both with copy buttons. They are built from the form, so what you copy is what you ran.
What green means
A green result means the string fits the chain's format. It doesn't mean the address exists, has a balance, or belongs to who you think, and it doesn't mean a checksum was verified, Address validation says which ones are. The page repeats that under every accepted address, on purpose.
The landing
The panels on the home page walk through all twenty-nine chains with one sample address each, computed the same way, in the browser, on one clock. Hover a panel to pause it. The arrows under the code step it by hand.