Devnet
Devnet faucet.
Test tokens for building against UniNet. Devnet tokens carry no value and exist only so you can exercise identity, delegation and settlement paths without spending anything real.
What this is for
A faucet is only useful next to something you can build against. Here is what devnet tokens are meant to exercise once the connection lands.
- Delegated spending limits. Issue an agent a bounded authority and watch a transfer inside the limit succeed and one over it be refused. That refusal is the interesting half.
- Settlement between identities. Move value from an agent wallet to a node operator identity and read the recorded state back.
- Capacity reservation. Reserve compute and settle against it, rather than paying a provider out of band.
None of the above is a production path. Devnet exists so the shape of the system is testable before any of it carries real value. See the architecture for how the pieces fit, and build status for which ones are finished.
This page ships ahead of its integration on purpose: the form, its states and its copy are done, so wiring the faucet is a single change at a known place rather than a new page. Until that lands the form stays visibly disabled. A faucet that accepts an address and quietly does nothing is worse than one that says it is not ready.
The status shown at the top of this page is read from the same source as build status, so the two cannot drift apart.
The devnet faucet is not connected yet. The page exists so the integration has somewhere to land; it does not dispense anything today.
Whether you connect to a hosted network or run your own node. This determines what the quickstart can honestly claim.
What you install to build against the network. If only a node binary and RPC exist, the quickstart is written against RPC.
If you are evaluating UniNet for something specific, a conversation is more useful than a test balance. Tell us what you are building and which primitives it depends on.