Use cases

From building blocks to real workflows

The catalogue shows what each library does. This is what you can build when you compose them. Twenty-five end-to-end workflows -- each starts with a real person and a real problem, walks the steps, and names the exact ForgeSworn pieces it stands on.

25end-to-end workflows
5problem domains
38building blocks used
Explore the workflows ↓
Machine Payments & Agent Commerce

Make APIs payable, discoverable, and consumable by people and autonomous agents over Lightning.

A developer running an autonomous research agent with no human in the loop

An AI agent that discovers and pays for APIs on its own

The agent needs live data that sits behind paywalls, but there is nobody to sign up, enter card details, or rotate API keys for it.

The agent finds paid APIs on Nostr, pays per call in satoshis under a hard budget cap, and caches its credentials — fully unattended.

Workflow
  1. The agent calls l402-search to find APIs by keyword from kind 31402 announcements on Nostr — it needs no URLs in advance.
  2. It probes a candidate with l402-discover to read pricing and payment rails without spending anything.
  3. On an HTTP 402 it auto-pays the Lightning invoice from its NWC wallet, bounded by MAX_AUTO_PAY_SATS and a rolling spend window.
  4. The returned macaroon is cached encrypted on disk and replayed on later calls; for volume it buys a discounted credit bundle.
  5. Every request can be routed over Tor so the agent's data sources stay unlinkable.
Built with
402-mcpDiscovers, pays for, and calls L402/x402 APIs as MCP tools 402-announcePublishes the kind 31402 listings the agent searches toll-boothThe gate on the API side that issues the invoice and macaroon brayGives the agent its Nostr identity and marketplace tooling
L402 x402 NWC kind 31402 Lightning
An indie developer with a useful HTTP API and no billing stack

Turn an existing API into a Lightning toll booth in an afternoon

Stripe means accounts, KYC, chargebacks, and minimum charges that make per-call micropayments impossible.

Any route is gated behind a few satoshis per request, announced for discovery, and observable from an AI client — no user accounts at all.

Workflow
  1. Wrap the existing Express, Hono, or Workers handler with toll-booth middleware and set per-route pricing.
  2. Point it at a Lightning backend (Phoenixd, LND, CLN, LNbits, or NWC) and switch on a daily free tier for casual users.
  3. Call announce once at startup so a signed kind 31402 event publishes the service, pricing, and endpoints to relays.
  4. The listing appears live on the 402.pub directory and in any agent's l402-search within seconds.
  5. Attach the toll-booth-mcp read-only to the SQLite ledger and ask an AI client 'how much did I earn this week?' without exposing the database.
Built with
toll-boothHTTP 402 middleware that gates routes and tracks credit balances toll-booth-announceBridges the booth config to a Nostr service announcement toll-booth-mcpRead-only payment analytics surfaced as MCP widgets 402-pubThe live public directory the listing shows up on
L402 kind 31402 Lightning Cashu
Someone self-hosting an open model on their own GPU

Sell access to your own LLM, paid per token

They want to rent out spare inference capacity without running a SaaS, holding customer funds, or trusting a payment processor.

Clients stream tokens and pay only for what they consume, with one deposit funding a whole session.

Workflow
  1. Front the Ollama or vLLM endpoint with toll-booth configured for streaming, metered access.
  2. Use the Session payment method so a single Lightning deposit opens a balance that debits per request and refunds the remainder on close.
  3. For an LND-free setup, wire the aperture-phoenixd adapter into Aperture so Phoenixd replaces LND as the Lightning backend.
  4. Announce the inference service on Nostr so agents and apps can find it by capability and price.
  5. Settlement is atomic on the Lightning Network — no invoices to reconcile, no custody of customer money.
Built with
toll-boothMeters and gates inference requests per token payment-methodsThe Session payment spec (deposit, bearer, top-up, refund) the metering follows aperture-phoenixdPhoenixd Lightning backend for Aperture, no LND required 402-announceAdvertises the inference endpoint for discovery
L402 IETF Payment Lightning BOLT-11
A data provider whose customers are Nostr bots and have no HTTP client

Serve a paid API to clients that only speak Nostr

Some consumers live entirely on Nostr — they have a key and a wallet but no way to make authenticated HTTP calls.

Clients send a Nostr event, pay an invoice, and get results back as a Nostr event — the bridge never touches their funds.

Workflow
  1. Run toll-booth-dvm in front of the existing toll-booth-gated API as a NIP-90 Data Vending Machine.
  2. A client publishes a kind 5800 job request with the method, path, and a bid cap.
  3. The DVM proxies upstream, gets a 402, and replies with a kind 7000 'payment-required' event carrying the bolt11 invoice.
  4. The client pays; the DVM polls for settlement, retries with the L402 credential, and returns the result as a kind 6800 event.
  5. Funds flow peer to peer over Lightning — the DVM only relays invoice strings and discards them after settlement.
Built with
toll-booth-dvmExposes the API as a NIP-90 DVM and mediates payment over Nostr toll-boothThe underlying L402 gate the DVM proxies to brayLets a Nostr-native agent send the job request and pay it
NIP-90 L402 kind 5800/6800/7000 Lightning
An operator in a hostile jurisdiction or fighting payment-rail censorship

Run a paid API no single party can deplatform

Card networks and cloud billing can freeze an account on a complaint; a clearnet-only endpoint can be blocked.

The service is reachable over Tor, paid in sats, and discoverable without any central registry that can be pressured.

Workflow
  1. Host toll-booth behind both a clearnet URL and a Tor hidden service; the same macaroon validates on either.
  2. Announce both URLs in a single kind 31402 event so clients can choose their transport.
  3. 402-mcp already defaults to onion-first transport, so with a Tor proxy it pays and fetches over the onion URL before trying clearnet.
  4. Because discovery is a self-signed Nostr event, no domain registrar or app store sits in the path to revoke.
  5. Go-native shops can run the same pattern with Aperture and aperture-announce instead of the TypeScript stack.
Built with
toll-boothGates the API and serves it on clearnet and onion at once toll-booth-announcePublishes both transports in one signed listing 402-mcpPays and consumes the API with an onion-first preference aperture-announceThe Go-side equivalent for Aperture deployments
L402 Tor kind 31402 Lightning
An operator of a fleet of specialised agents that need to delegate

Let one AI agent hire another and pay on completion

A generalist agent hits a task it can't do well and has no safe way to find, vet, and pay a specialist agent.

Agents advertise capabilities, dispatch work to each other, settle in sats, and check trust before committing.

Workflow
  1. Specialist agents publish their capabilities with bray's dispatch tools so others can discover them via NIP-89.
  2. The hiring agent checks the specialist's Signet verification tier and trust score before sending work.
  3. It sends an encrypted dispatch request describing the task and an agreed price.
  4. The specialist exposes its paid output as a toll-booth-DVM job, so payment and delivery happen atomically over Nostr.
  5. On success, the hiring agent acknowledges the job; both can leave portable attestations that feed future trust decisions.
Built with
brayCapability discovery, encrypted dispatch, and trust scoring for agents toll-booth-dvmDelivers and charges for the specialist's output over Nostr 402-mcpPays for any external L402 tools the specialist itself needs signetGives each agent a verifiable identity tier to vet before hiring
NIP-89 NIP-17 NIP-90 kind 31000 Lightning
Sovereign Identity & Signing

Hardware-backed keys, deterministic personas, and recoverable Nostr identities that never touch a server.

An investigative journalist whose device may be seized or compromised

Keys that never touch the laptop for a high-risk journalist

If the signing key lives in the browser or on disk, one malware infection or border search burns every source contact.

All signing happens on a dedicated appliance over Tor; the working machine holds no key material at all.

Workflow
  1. Provision a Heartwood appliance on a Raspberry Pi; the master secret is encrypted with Argon2id and AES-256-GCM and unlocked by PIN.
  2. Heartwood exposes NIP-46 remote signing as a Tor hidden service, so the laptop talks to it without a key ever leaving the Pi.
  3. Install the Bark browser extension, which implements NIP-07 by forwarding every request to Heartwood — zero key storage in the browser.
  4. Derive separate unlinkable personas per investigation from one master seed using nsec-tree.
  5. Manage and update the device — firmware, client policies, factory reset — from the Sapwood web UI.
Built with
heartwoodPi signing appliance with encrypted keys and NIP-46 over Tor barkNIP-07 browser extension backed by remote signing, no local keys nsec-treeDeterministic unlinkable personas from one master secret sapwoodBrowser-based device manager, firmware, and policy control
NIP-46 NIP-07 NIP-44 Tor Argon2id
A creator who keeps work, activism, and personal life cryptographically separate

Run many unlinkable personas from a single seed

Juggling multiple nsec keys is a backup nightmare, and any leaked link between them collapses the separation.

Unlimited personas derive deterministically from one master secret, provably unlinkable unless the owner chooses to prove a link.

Workflow
  1. Create a master tree from a BIP-39 mnemonic; nsec-tree derives child keys with HMAC-SHA256 so a leaked child reveals nothing about siblings or root.
  2. Derive named personas ('work', 'anonymous', 'social') on demand — each is a full Nostr identity.
  3. Switch the active persona straight from the Bark extension while signing stays on the Heartwood device.
  4. When you want to, publish a signed linkage proof to claim two personas as yours; otherwise they stay independent.
  5. Recover every persona later by re-deriving from the seed — there is no per-persona backup to lose.
Built with
nsec-treeHMAC-SHA256 derivation of unlimited unlinkable identities barkPersona switching and signing from the browser heartwoodHolds the master seed and signs for every derived persona nsec-tree-cliOffline derivation, proofs, and inspection from the terminal
NIP-19 NIP-78 BIP-39 HMAC-SHA256
An everyday user who would otherwise lose everything with one dropped device

Lose your phone, keep your Nostr account

Self-custody usually means a single seed phrase — lose it and the identity is gone forever; write it down and it can be stolen.

The identity is recoverable from a quorum of trusted contacts, with no single point of failure and nothing for a thief to grab.

Workflow
  1. Export the nsec-tree master secret and split it with shamir-words into, say, five shares needing any three to recover.
  2. Each share encodes as a BIP-39 word list with a checksum, easy to read aloud, write down, or engrave.
  3. Hand the word lists to five trustees; each can publish a signed attestation acknowledging they hold a recovery share.
  4. If the device is lost, collect three word lists, reconstruct the secret with nsec-tree-cli, and re-derive every persona.
  5. Those public acknowledgements let the recovering user rediscover who their trustees are, even if contact details changed.
Built with
nsec-treeMaster secret that the whole identity tree derives from shamir-wordsSplits the secret into human-readable threshold word shares nsec-tree-cliOffline split and recovery workflow nostr-attestationsTrustees' public acknowledgements of holding a share
Shamir SSS BIP-39 kind 31000 GF(256)
A field operative or hardware tinkerer who wants a cheap, tamper-evident signer

A pocket hardware signer with physical-button approval

A full appliance is overkill for the field; they want a sub-£20 device that approves signing with a real button press.

An ESP32 token holds up to eight master identities, shows each request on its screen, and only signs when a button is held.

Workflow
  1. Flash heartwood-esp32 onto a Heltec WiFi LoRa 32 board (ESP32-S3) and provision master secrets that never leave the chip.
  2. Each signing request renders on the 128x64 OLED with event kind and content preview plus a countdown.
  3. Approve by holding the button for two seconds; a short press or timeout denies — no silent remote signing.
  4. A host bridge relays end-to-end-encrypted NIP-46 envelopes, so even the bridge is zero-trust plumbing.
  5. Provision, set per-client policies, and run signed OTA firmware updates from the Sapwood UI; pair it to apps with Bark.
Built with
heartwood-esp32ESP32-S3 signing token with on-device approval sapwoodProvisioning, policy, and OTA firmware management barkConnects web apps to the token via NIP-46
NIP-46 NIP-44 secp256k1 Web Serial
A web developer who wants accounts without passwords or a user database

'Sign in with Nostr' for any site, no passwords stored

Email-and-password means breaches, resets, and storing credentials; they want users to own their identity.

One script tag gives users a choice of extension, QR, or remote-signer login, verified server-side with no shared secret.

Workflow
  1. Drop in signet-login; it presents a modal offering NIP-07 extension, cross-device QR, or a NIP-46 bunker URI.
  2. The chosen signer signs a fresh challenge as a kind 21236 auth event proving control of the pubkey.
  3. Verify that event server-side — Schnorr signature, recomputed event id, and challenge match — with no password to store.
  4. Fetch the user's display name with signet-credentials, deduplicated across relays and respecting expiry.
  5. Rust game servers and relays speak the same wire format through the signet-protocol crate.
Built with
signet-loginDrop-in login SDK with extension, QR, and bunker flows signet-credentialsFetches and validates the user's handle credential barkActs as the NIP-07 signer behind the login signet-protocol-rsShared Signet event types and canonical IDs for Rust backends and game engines
NIP-07 NIP-46 NIP-17 kind 21236 BIP-340
Verification, Trust & Privacy

Prove what matters, hide what doesn't — age, professional status, reputation, and anti-fraud without surveillance.

An e-commerce operator under the UK Online Safety Act and similar laws

Age-gate a shop without ever storing a date of birth

Collecting IDs and birthdates creates a honeypot, breaks privacy laws, and scares away customers.

Customers prove they are over 18 with a zero-knowledge proof; the shop stores no personal data and still satisfies the regulator.

Workflow
  1. A trusted verifier issues a Signet credential carrying a range-proof bound to the customer's pubkey — proving an age band, not a birthdate.
  2. On checkout, drop-in signet-verify shows a QR the customer scans with their Signet app.
  3. The site checks the proof and confirms the issuing verifier against public professional registers before accepting.
  4. Use jurisdiction-kit to apply the right digital-consent age and data-transfer rules for the customer's country.
  5. Nothing identifying is retained — only a cryptographic pass/fail and the verifier's confirmation status.
Built with
signet-verifyOne-script-tag age gate with verifier register checks range-proofZero-knowledge proof that age sits in a band, no DOB revealed signetIssues and structures the verifiable age credential jurisdiction-kitPer-country consent ages and cross-border transfer rules
ZK range proof NIP-VA BIP-340
A finance team that authorises payments over phone and video calls

Stop CEO-voice fraud on phone and video calls

Voice and video are now trivially faked, so 'it sounded like the CFO' is no longer proof of anything.

Both sides of a call speak a rotating word that only genuine members can know, with a silent duress signal built in.

Workflow
  1. Set up a canary-kit verification group; each member derives words from a shared secret with no network round-trip.
  2. On a call, each party speaks the current directional word — caller and agent words differ, so a replay can't pass.
  3. Words rotate on a schedule (seconds for live calls, longer for standing groups), so a captured word expires fast.
  4. Every member also has a unique duress word; speaking it verifies as valid to the attacker but silently raises an alarm.
  5. Optional liveness heartbeats act as a dead-man's switch if a member goes dark under coercion.
Built with
canary-kitGroup verification, duress signalling, and liveness over Nostr spoken-tokenThe rotating human-speakable token primitive underneath
HMAC-SHA256 TOTP NIP-44 NIP-17
A family or a field-ops team that needs to verify each other remotely

A family safe-word system that survives coercion

A spoken safe-word can be forced out of someone; a panic button can be taken away.

Members verify each other with rotating words, can signal duress invisibly, and share location only with the trusted group.

Workflow
  1. Create a canary-kit group with a family preset; members and the shared secret derive from an nsec-tree identity.
  2. Each member's app shows the current verification word for confirming a caller is really them.
  3. Under threat, a member speaks or sends their personal duress word — it looks valid but flags the rest of the group.
  4. Encrypted beacons let members share location and timestamp with the group only, gift-wrapped over Nostr.
  5. Removing a member with the reseed option immediately rotates the shared secret, so they instantly lose the ability to verify.
Built with
canary-kitGroups, duress words, encrypted beacons, and reseed-on-change nsec-treePer-member identity the group secret is bound to spoken-tokenUnderlying rotating verification words
NIP-44 NIP-17 kind 30078/20078 NIP-40
A moderation circle on a community platform

Report abuse without exposing the reporters

Named moderators get targeted and retaliated against, so people stop flagging bad actors.

A circle issues a collective trust signal where each contribution is provably from a member but no individual is identifiable.

Workflow
  1. Form a trust circle of moderator pubkeys with nostr-veil.
  2. Each moderator signs their assessment with an LSAG ring signature proving 'a member of this circle contributed' — and nothing more.
  3. Linkable key images stop any one member from voting twice, while keeping them anonymous.
  4. nostr-veil aggregates the contributions into a standard NIP-85 assertion readable by any client ('vouched by 3 of 5').
  5. Human-readable endorsements or vouches can ride alongside as revocable kind 31000 attestations.
Built with
nostr-veilAnonymous threshold trust assertions over NIP-85 ring-sigLSAG ring signatures with double-vote-proof key images nostr-attestationsOptional human-readable, revocable endorsement records
LSAG NIP-85 kind 30382-30385 secp256k1
A professional marketplace that needs to prove its providers are real and licensed

A 'verified solicitor' badge that no platform owns

Centralised verification locks providers into one platform and creates a database of sensitive credentials to breach.

Providers carry portable, revocable proof of professional status that any client or app can check independently.

Workflow
  1. A registered verifier issues a tiered Signet credential as a kind 31000 attestation for the provider's pubkey.
  2. jurisdiction-kit confirms the verifier belongs to a recognised body and exposes the public register to check against.
  3. Clients compute the provider's Signet IQ and tier from on-relay events to gate who can offer regulated services.
  4. Revocation is atomic — a superseding event instantly invalidates a credential if a licence lapses.
  5. Because every record is a signed Nostr event, the reputation is portable across every client, not trapped in one marketplace.
Built with
signetFour-tier verification, trust scoring, and verifier lifecycle signet-credentialsFetches, parses, and validates the credential events jurisdiction-kitProfessional-body registries for 28 countries nostr-attestationsThe universal kind 31000 attestation container
kind 31000 NIP-VA NIP-40 BIP-340
A newsroom verifying a sensitive source

Corroborate a whistleblower source without a byline

Editors need to signal that a source is credible without naming who vouched or exposing the source's identity.

A reader sees 'verified by N of M trusted journalists' as a cryptographic fact, with no editor identifiable and the source pseudonymous.

Workflow
  1. The newsroom forms a circle of journalist keys; the source operates under an unlinkable nsec-tree persona.
  2. Each editor who has independently checked the source signs a ring-signed corroboration with ring-sig.
  3. nostr-veil aggregates those into a threshold trust score attached to the source's pubkey.
  4. A revocable kind 31000 vouch can carry a human-readable note alongside the cryptographic proof.
  5. Editors sign from a Heartwood appliance over Tor so no signing key sits on a seizable newsroom laptop.
Built with
ring-sigAnonymous per-editor corroboration signatures nostr-veilThreshold aggregation into a NIP-85 trust signal nostr-attestationsHuman-readable, revocable vouch records heartwoodTor-only hardware signing for at-risk editors
LSAG NIP-85 kind 31000 Tor
A borrower, trader, or applicant facing a threshold check

Clear a threshold check without revealing the figure

Proving 'balance over X' or 'score over Y' normally means handing over the exact, private value.

The holder proves the value sits in or above a range; the verifier learns only pass or fail.

Workflow
  1. The holder creates a Pedersen-commitment range proof with range-proof, binding it to their pubkey to prevent reuse by others.
  2. They publish it as a kind 31000 credential, or present it directly to a counterparty.
  3. The verifier checks the proof against the stated bound — the committed value never appears.
  4. Agents can generate and check these proofs through bray's privacy tools as part of a larger negotiation.
  5. The live ForgeSworn demos let you try a range proof end to end.
Built with
range-proofPedersen-commitment range proofs on secp256k1 nostr-attestationsCarries the proof as a portable credential event brayGenerate and verify range proofs as agent tools
Pedersen commitment ZK range proof kind 31000 secp256k1
An operator of a decentralised P2P marketplace

Reputation that travels with the trader, not the platform

Reputation locked inside one platform can't move with the trader and dies if the platform does.

Every trade leaves signed, portable feedback, and community standing is computed from open events — owned by no one.

Workflow
  1. After each trade, both parties publish a kind 31000 endorsement — bilateral, queryable, and individually revocable.
  2. A moderation circle periodically scores vendors anonymously with nostr-veil, deduplicated by LSAG key image.
  3. Before trading, a buyer sees both peer endorsements and the threshold trust score for the seller.
  4. Signet tiers gate high-value categories to verified sellers only.
  5. For big trades the seller can attach a range proof of sufficient balance, settled via a toll-booth-gated escrow flow.
Built with
nostr-attestationsBilateral, revocable trade endorsements nostr-veilAnonymous community vendor scoring signetVerification tiers gating regulated or high-value trades toll-boothPayment gating for escrowed settlement
kind 31000 NIP-85 LSAG L402
Access, Spatial & Coordination

Encrypted tiered access, fair meeting points, and location-aware discovery on open protocols.

A writer or artist selling free, supporter, and inner-circle tiers

Sell creator tiers no platform can revoke

Platform paywalls take a cut, own the audience, and can demonetise on a whim.

Content is encrypted once per epoch and unlocked only for the right tier, with revocation that takes effect automatically.

Workflow
  1. Encrypt each post once with a dominion epoch content key derived via HKDF, then distribute that key to tiers.
  2. Publish encrypted key shares as kind 30480 events, gift-wrapped per recipient over Nostr.
  3. Gate the paid drop with toll-booth so a Lightning payment adds the buyer to a tier.
  4. Tiers and recipients are keyed to the creator's nsec-tree identity; high-value vaults can split the content key M-of-N across custodians.
  5. Revoke by simply not distributing the next epoch's key — access lapses on the next weekly rotation, no re-encryption needed.
Built with
dominionEpoch content keys, AES-256-GCM, and tiered key distribution nsec-treeCreator identity that tiers and recipients are keyed to toll-boothLightning payment that grants tier access shamir-wordsOptional human-readable word shares for custodian-held keys
HKDF AES-256-GCM kind 30480 NIP-59
A remote team or friend group scattered across a region

Find the fair place for a distributed team to meet

'Meet in the middle' by straight-line distance is unfair once real roads and transit times are involved.

An AI assistant suggests venues that genuinely balance everyone's travel time, ranked by a fairness strategy.

Workflow
  1. Ask the assistant in plain language; it drives rendezvous-mcp's tools over MCP.
  2. rendezvous-kit computes each person's reachability isochrone and intersects them to find the shared zone.
  3. It searches OpenStreetMap via the Overpass API for cafes or venues inside that intersection.
  4. Candidates are scored by fairness — minimise the worst commute, the total, or the variance — and ranked.
  5. geohash-kit underpins the spatial maths; paid routing can be metered with L402 if you self-host the engine.
Built with
rendezvous-mcpExposes fair-meetup tools to AI agents over MCP rendezvous-kitIsochrone intersection, venue search, and fairness scoring geohash-kitGeospatial primitives and Nostr location filters
MCP isochrones GeoJSON L402
A community building a local services board without a central platform

Find local providers on open relays, not a walled garden

Local discovery usually means a walled-garden app that owns the listings and the trust signals.

Providers and requests are tagged by location on open relays, found by proximity, and filtered by verified trust.

Workflow
  1. Providers publish listings with geohash g-tags from geohash-kit so they're queryable by area.
  2. A seeker builds a proximity filter — encode their location, expand to neighbouring cells, and query relays.
  3. bray runs the discovery, weaving in trust so results can require a verification tier or proximity.
  4. Verified-professional listings carry kind 31000 attestations the seeker can check inline.
  5. The seeker contacts a chosen provider over an encrypted DM; coarse public geohashes keep exact locations private until both sides agree to share.
Built with
geohash-kitGeohash encoding and Nostr proximity filters brayTrust-aware discovery and querying over relays nostr-attestationsVerifiable provider credentials attached to listings
geohash g-tags kind 31000 NIP-50
Protocol, Compliance & Tooling

Provenance trails, jurisdiction intelligence, and supply-chain-hardened release infrastructure.

A heritage materials maker proving where every batch came from

Verifiable provenance for conservation-grade materials

Paper certificates are forgeable and centralised registries can be edited or lost.

An append-only, independently verifiable trail follows a product from source to site on open relays.

Workflow
  1. Publish a product certificate as a provenance event (the draft NIP-PROVENANCE, kind 30404) with composition, origin, and batch.
  2. The source records lab results as timestamped evidence events (draft NIP-EVIDENCE) with file hashes.
  3. Each logistics handoff appends a chain-of-custody event (draft NIP-CUSTODY) referencing the previous one.
  4. Authenticity is anchored with kind 31000 attestations, and the installing professional's status is checked with Signet.
  5. If a dispute arises, the whole signed chain — certificate, evidence, custody — is available to an arbitrator.
Built with
nip-draftsDraft provenance, evidence, and custody event specifications nostr-attestationsAuthenticity attestations anchoring the chain signetVerifies the installing professional's credentials jurisdiction-kitCross-border recognition and compliance context
NIP-PROVENANCE NIP-CUSTODY NIP-EVIDENCE kind 31000
An open-source maintainer of a security-sensitive package

Ship a library nobody can tamper with in transit

A leaked npm token or a compromised CI step can publish a poisoned build that users trust implicitly.

Every release is built twice, byte-compared, provenance-signed, and tied to a Nostr identity — verifiable end to end.

Workflow
  1. anvil builds the package on two independent runners and refuses to publish unless the tarballs are byte-identical.
  2. It publishes via OIDC trusted publishing — no long-lived npm token to leak — and emits SLSA provenance.
  3. The tarball hash is stamped into the GitHub release and uploaded as an asset for a second, independent check.
  4. The maintainer signs a kind 31000 authorship attestation linking their Nostr identity to the exact version.
  5. Consumers verify the npm provenance, the release hash, and the attestation before trusting the bytes.
Built with
anvilReproducible two-runner builds with OIDC and SLSA provenance nostr-attestationsSigned authorship attestation tying identity to a release forgesworn-demosLive, hardened-and-published examples of the crypto primitives
SLSA OIDC kind 31000 SHA-256

Pick a block and start

Every workflow above is built from open-source, MIT-licensed libraries. Use one, use many, or use them all together.

Browse the catalogue View on GitHub