Authentication

All Droplit API requests require an X-Auth-Token header generated from a Bitcoin signature. This preserves request-level cryptographic proof for app backends and agent runtimes.

Required header

X-Auth-Token: <signed-token>

Recommended approach

Use Sigma-hosted signing for user and app flows. This gives hosted identity convenience while keeping BSV-native signature semantics.

Signing inputs

When generating a token, sign:

• requestPath (for example /faucet/my-droplit/tap)
• request body string (for POST/PUT style requests)
• signature scheme (brc77 recommended)

Example: bitcoin-auth service signer

import { getAuthToken } from "bitcoin-auth";

const requestPath = "/faucet/my-droplit/tap";
const body = JSON.stringify({
	recipient_address: "1ExampleAddress...",
	satoshis: 1000,
});

const authToken = await getAuthToken({
	privateKeyWif: process.env.DROPLIT_SIGNER_WIF,
	requestPath,
	body,
	scheme: "brc77",
	bodyEncoding: "utf8",
});

const response = await fetch(
	`${process.env.NEXT_PUBLIC_DROPLIT_API_URL}${requestPath}`,
	{
		method: "POST",
		headers: {
			"Content-Type": "application/json",
			"X-Auth-Token": authToken,
		},
		body,
	},
);

Sigma integration notes

• Droplit web UI already uses Sigma-hosted signing flows.
• Signing stays in Sigma domain for browser-integrated workflows.
• You can still use backend service signers when architecture requires it.

Security notes

• Never commit WIFs or secrets.
• Use separate signer keys per environment.
• Rotate allowlisted keys and revoke stale identities quickly.
• Keep signing logic and request dispatch in trusted backend boundaries.

Next steps

• Permission Model
• SSE Activity Stream
• Agent Playbooks