Tools that make building on the Dash Evolution chain approachable.

Creating an identity, funding it, publishing a contract — the first steps on Dash Platform trip up nearly everyone. evotools is a set of small, focused tools that remove those hurdles one at a time, plus a hub that ties them together. Every tool runs on testnet and mainnet, entirely in the browser: no server holds your keys, because there is no server. Open source, by 247bas.

Live at evotools.dev · evotools.dash on Platform.

Tools

Tool	What it does	Status
Map	Where DASH, credits and identities sit, what each move costs, and where any identity's money came from	Live
Onboard	Wallet → fund → identity → .dash name → ready .env	Live
Keygen	One phrase → funding address + the five DIP-13 identity keys, fully offline, and adding one that is missing to an identity that already exists	Live
Credits	An identity's balance and every way to move it: top up, pay out, convert, withdraw to layer 1	Live
Playground	Run the cookbook recipes live in the browser	Live
Explorer	Identities, DPNS names, contracts, tokens, documents and the shielded pool, with proofs	Live
Tokens	Make a token in four questions, mint it, send it by name, and work out who holds it	Live
dash-name	Check and claim a .dash username for your identity	Live
Contests	Every .dash name masternodes are voting on, and every one they decided	Live
Shielded	The Orchard pool: what is in it, how it moves week by week, what the six shielded moves cost, and whether an address is a shielded one	Live
Cookbook	Verified, runnable @dashevo/evo-sdk v4 recipes	Live (own repo)
create-evo-app	Scaffold a Dash Platform app: npm create evo-app	Live (own repo)

Getting onto Platform needs no other software: layer-1 funding, identity creation, name registration and withdrawal all run here, each verified with real money on mainnet.

Structure

A pure static site — no build step. One folder per tool, a shared design system and a shared vendored SDK.

evotools/
├─ public/               the deployed site (Cloudflare Workers static assets)
│  ├─ index.html         the hub homepage
│  ├─ shared/
│  │  ├─ theme.css       design tokens + shared components
│  │  ├─ nav.js          injects the top nav + footer on every page
│  │  ├─ secrets.js      one rule for "this is a key, refuse it"
│  │  ├─ assetlock.js    build a layer-1 asset lock in the browser
│  │  ├─ dpns-register.js   resumable .dash registration (derived salt)
│  │  ├─ token-holders.js   who holds a token, walked from its history
│  │  └─ vendor/         @dashevo/evo-sdk v4 + dashcore-lib, shared by all tools
│  ├─ map/               → /map
│  ├─ onboard/           → /onboard
│  ├─ keygen/            → /keygen
│  ├─ credits/           → /credits
│  ├─ playground/        → /playground
│  ├─ explorer/          → /explorer
│  ├─ tokens/            → /tokens (a wizard; see steps.js)
│  ├─ name/              → /name   (dash-name)
│  ├─ contests/          → /contests
│  ├─ shielded/          → /shielded
│  └─ about/             → /about
├─ wrangler.jsonc        assets.directory = "public"
└─ package.json

Each web tool imports /shared/theme.css, /shared/nav.js, and the SDK from ../../shared/vendor/. Adding a tool is a new folder + a card on the hub.

Platform cannot list, so some things have to be walked

Platform proves a thing you name and cannot enumerate. /contests and /map work around that with an external indexer. /tokens does not need one: a token published with history writes a document for every mint, transfer, burn and purchase into one system contract, and tokens cannot move any other way — so walking that history finds everyone who ever held it, and their balances are then a normal lookup. The base supply is the one thing no document records; it goes to the contract owner at publish time and is added by hand.

That lives in public/shared/token-holders.js and both /tokens and /explorer call it. It only works for a token that keeps history; when one does not, the tools say so rather than presenting a short list as the whole truth.

The reverse question — which tokens does this identity hold — has no such route. Every index on the history contract starts with the token, so "every document naming this identity" is not a query it can serve, and that one list comes from the indexer instead. The balances next to it do not.

Keys never leave the browser

Every tool that signs does so client-side, and every box that takes an identifier refuses a key before it goes anywhere. That guard is one shared rule (public/shared/secrets.js), because the trap is not obvious: a WIF is 52 characters of base58, which DPNS accepts as a valid username — so an unguarded name lookup would carry a pasted key to a Platform node. The map never asks for a key at all.

Run locally

npm install            # only to (re)vendor the SDK; the site itself has no deps
npm run serve          # serves public/ at http://localhost:8000

npm run test:map       # address arithmetic, the shareable link, live traces
npm run test:onboard   # onboard's core flow against testnet
npm run test:explorer  # the explorer lookups
npm run test:name      # dash-name check/register + the secret guards
npm run test:credits   # the credits guards and live reads
npm run test:tokens    # the page flows (offline), then the guards, contract building and the holder walk
npm run test:tokens:page  # just the page: boots index.html in a shim DOM and clicks through
npm run test:contests  # the contests list and its indexer quirks
npm run test:keygen    # offline key derivation, the offline copy, and adding a key
npm run test:assetlock # builds a real signed asset lock
npm run test:dpns      # salt derivation for resumable registration

npm run vendor         # re-copy the SDK into public/shared/vendor after an update
npm run og             # regenerate the OG images

The tests read the live chain, so they need a connection and they report what is actually there rather than a fixture.

Deploy

Cloudflare Workers static assets, connected to this GitHub repo: pushing to main deploys. No build command; wrangler.jsonc serves the public/ directory, so .git, node_modules and tooling stay out of the upload. Custom domain: evotools.dev.

Adding a dependency without committing the updated package-lock.json makes the build's npm ci fail, and the deploy then silently stalls on the previous build — always commit the lockfile with a dependency change.

Credit

evotools is a thin layer over other people's work. What it leans on, and for what:

• @dashevo/evo-sdk v4 and dashcore-lib, by Dash Core Group. The SDK is vendored into public/shared/vendor/ and does every Platform read and write; dashcore-lib builds and signs the layer-1 asset lock.
• The masternode network serving DAPI. Every lookup, proof and broadcast in these tools is answered by a masternode; the SDK's trusted mode picks one.
• The Dash Bridge (bridge.thepasta.org), by PastaPastaPasta. Onboard opens it with your testnet address already filled in — it is where testnet DASH comes from, and without it the testnet path would stop at an empty address.
• pshenmic's Platform Explorer (platform-explorer.pshenmic.dev). Platform can prove a thing you name but cannot list things, so anything that needs an index needs an indexer: /contests reads its API for the list of names being voted on, and /map walks an identity's transactions through it to find the one that created it.
• The Insight API (insight.dash.org, insight.testnet.networks.dash.org), run by Dash Core Group — layer-1 UTXOs, confirmations, and the raw transaction an asset lock is read out of.

Everything above is public infrastructure this project uses as a guest, not a service it pays for or controls. If a tool here is unreachable, one of these usually is.

License

MIT