Get started

Build waved with the wallet API

WalletService and WalletInspectionService are compiled into waved only when the daemon is built with the wavewalletrpc build tag. That tag requires swapruntime transitively: building with wavewalletrpc but without swapruntime is a deliberate compile error, and a default make build includes neither, so the wallet API is off unless you opt in.

Build both waved and wavecli with the tag using the provided make target:

make build-wavewalletrpc

This produces bin/waved and bin/wavecli with the wallet RPC surface registered. make install-wavewalletrpc does the same via go install, landing the binaries in $GOPATH/bin.

Endpoints

waved starts two listeners by default:

Protocol	Default address	Notes
gRPC	`localhost:10029`	The daemon’s own RPC server.
REST	`localhost:10031`	An HTTP/JSON gateway in front of the same RPCs, enabled by default.

Every WalletService and WalletInspectionService method is reachable on both listeners with the same request and response shape, modulo JSON encoding. See REST conventions for the route and body shape used by the gateway.

The gRPC listener is secured by default

The daemon’s gRPC server wires up TLS and macaroon authentication by default: it serves TLS credentials and enforces a macaroon on every call. For loopback development and regtest you can disable both with --no-tls and --no-macaroons; on a mainnet TCP listener the daemon refuses both by default, so a stray flag can’t quietly expose an unauthenticated plaintext RPC surface. A deployment that terminates TLS and enforces authentication at an external proxy can set allow-insecure-mainnet to override that refusal, which acknowledges that the daemon’s own listener then runs without transport security. The default macaroon is written to admin.macaroon under the daemon’s network directory. The REST gateway (localhost:10031) is a local plaintext HTTP proxy: it forwards the macaroon HTTP header to the enforcing gRPC backend, so a call needs that header whenever macaroons are enabled.

Your first call

With waved running a wavewalletrpc build, call Status to confirm the daemon and wallet API are up. StatusRequest is empty, so an empty JSON object is a complete request body.

Over REST (a local daemon started with --no-macaroons; otherwise add a -H "macaroon: <hex>" header):

curl -X POST http://localhost:10031/v1/wallet/status -d '{}'

Over the CLI, the equivalent is:

wavecli getinfo --no-tls --no-macaroons

getinfo talks to the daemon’s own DaemonService rather than WalletService.Status directly, but it is the fastest way to confirm wavecli can reach waved at all before you start scripting WalletService calls. --no-tls --no-macaroons matches a daemon run with authentication disabled; it is the right pairing for local and regtest use.

Where to go next

Walk the method reference starting with Create and Unlock to bring up a wallet, then PrepareSend and Send to move funds.
Read REST conventions for the full request, error, and streaming shape shared by every route.
Explore the same surface from a terminal in the CLI slice: wavecli wraps every WalletService method as a subcommand.