Authentication

Every protected Droplit route uses BRC-103/104 mutual authentication. The client and server prove their identities through the SDK handshake; there is no bearer token or API-key header to construct.

HTTP requests

Use one long-lived AuthFetch instance so authenticated sessions can be reused.

import { AuthFetch, PrivateKey, ProtoWallet } from "@bsv/sdk";

const wallet = new ProtoWallet(
	PrivateKey.fromWif(process.env.DROPLIT_SIGNER_WIF),
);
const client = new AuthFetch(wallet);
const body = JSON.stringify({
	recipient_address: "1ExampleAddress...",
	satoshis: 1000,
});

const response = await client.fetch(
	`${process.env.DROPLIT_API_URL}/faucet/my-droplit/tap`,
	{
		method: "POST",
		headers: { "Content-Type": "application/json" },
		body,
	},
);

Browser requests with Sigma

Pass the connected Sigma iframe wallet to AuthFetch or Peer. Keys remain in the Sigma domain; the wallet performs the SDK operations on request.

WebSocket activity stream

The activity stream uses the same BRC-103/104 protocol through the SDK's Peer class and a WebSocket Transport. See the stream guide for the complete connection pattern.

Security notes

• Never commit WIFs or secrets.
• Keep one wallet identity per environment and runtime boundary.
• Reuse authenticated clients instead of rebuilding a handshake for each call.
• Never reimplement the SDK's nonce, signature, certificate, or session logic.

Next steps

• Permission Model
• WebSocket Activity Stream
• Agent Playbooks