How to authenticate Droplit requests using Sigma-hosted signing and BSV-native signatures.

Authentication

Droplit uses Bitcoin-native request signatures in the X-Auth-Token header. The recommended path is Sigma-hosted identity and signing, so your application does not need to store WIFs.

Preferred model: Sigma-hosted signing

For Droplit UI and app integrations using Sigma:

User authenticates with Sigma.
Request payloads are signed with Sigma-managed keys.
Your app sends requests with X-Auth-Token.

This keeps signing inside the Sigma domain while preserving BSV-native cryptographic verification.

Header format

X-Auth-Token: <signed-token>

What is signed

Droplit signatures are tied to:

requestPath
request body (when present)
signature scheme (brc77 or bsm)

This gives request-level verifiability for backend and agent workflows.

Service-to-service signing (advanced)

If you run a backend signer, use bitcoin-auth compatible libraries:

TypeScript example

import { getAuthToken } from "bitcoin-auth";

const requestPath = "/faucet/your-droplit/push";
const body = JSON.stringify({
	data: ["agent:event", "order:12345", "status:filled"],
	encoding: "utf8",
});

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

Security checklist

Prefer Sigma-hosted signers whenever possible.
Never expose private keys in frontend bundles.
Rotate backend signer keys on a schedule.
Use separate keys for dev, staging, and prod.
Scope public keys per droplit allowlist.

Authentication

On this page