Welcome to Skrybit

Skrybit puts your brand on Bitcoin. You pick an audience of Bitcoin wallets, attach your media, and Skrybit inscribes it directly on-chain and delivers it to every wallet in the audience — a real Bitcoin inscription, owned by the recipient, forever.

These docs cover the whole journey:

• For marketers — the full campaign lifecycle in the Skrybit Console: build a collection, choose an audience, estimate the cost, launch, fund the batch from your own wallet, and watch delivery happen on-chain. Start with Running an Airdrop Campaign.
• For recipients — someone airdropped you an inscription and sent you a claim link? Here is what that means and what to do. (Short version: it is already yours; claiming just proves it.)
• Wallets & accounts — how Skrybit thinks about your wallets, and what “verified” vs “watch-only” means. See Wallets & Accounts.
• API — the platform is API-first; everything the console does is available programmatically. See the API Reference.

Networks

Skrybit runs on Bitcoin mainnet and on testnet4. The two are fully separate: separate campaigns, separate wallets, separate funding. Every network-scoped action in the console and the API is explicit about which network it targets — nothing silently crosses over. Use testnet4 to rehearse a campaign end-to-end before spending real sats.

How delivery actually works

Skrybit inscriptions are standard ordinals inscriptions, created with a commit/reveal transaction pair and delivered straight to the recipient’s address. There is no escrow, no wrapped token, no bridge: once the reveal transaction confirms, the recipient’s wallet holds the inscription like any other sat they own. You (the marketer) fund the batch; Skrybit’s engine signs and broadcasts the inscription transactions.

Running an Airdrop Campaign

An airdrop campaign moves through a fixed lifecycle. Each step has its own page in this section; this page is the map.

create collection → upload media → build audience → estimate cost
      → launch (dry-run first) → fund via wallet → delivery → open claims

1. Create a collection and upload media — the content that will be inscribed. A collection groups media items; a campaign links one or more collections.
2. Build your audience — the wallets that will receive the inscriptions. Use an on-chain cohort (e.g. “ordinals whales”, “active traders”) or add addresses manually.
3. Estimate the cost — per-tier (slow / normal / fast) totals for inscribing the whole campaign, priced from live Bitcoin fee rates, plus a dry-run that shows the exact delivery plan without touching the chain.
4. Launch and fund — launching creates a batch and returns a payment address and an exact amount. You fund it from your own wallet (one click with UniSat); Skrybit’s engine does the rest.
5. Track delivery — watch the batch progress: payment seen → payment confirmed → commit tx → reveal tx → inscription in the recipient’s wallet.
6. Open claims — let recipients prove ownership on a public claim page and connect with your campaign.

How fast is it?

With a normal fee tier and normal mempool conditions, a campaign runs end-to-end in about three Bitcoin blocks. A real production run on mainnet (July 30, 2026) went from payment sent to claimed inscription in about 30 minutes:

Slower fee tiers cost less but each confirmation can wait more blocks; see Estimating Cost.

Rehearse on testnet4

The entire lifecycle — collections, cohorts, launch, funding, delivery, claims — works identically on testnet4 with valueless coins. If this is your first campaign, run it there first.

Collections & Media

A collection is the content side of a campaign: a named group of media items that will be inscribed and delivered to your audience. Campaigns link to collections, so the same collection can be reused across campaigns and a campaign can combine several collections.

Create a collection

In the console, create a collection with a name and description. The collection starts empty — it is just the container.

Upload media

Add media items to the collection. Each item is the exact payload that will be inscribed on Bitcoin:

• Images (PNG, JPEG, SVG, WebP, GIF) are the common case.
• Text, JSON, and HTML payloads are also valid inscription content.

Two things to keep in mind:

1. Size costs sats. Inscription cost scales with payload size — every byte of your media is written to the Bitcoin blockchain and paid for at the prevailing fee rate. A lean, well-compressed asset can cut your campaign cost dramatically. The cost estimate reflects your actual media sizes.
2. Inscriptions are forever. There is no editing or deleting an inscription after delivery. Proof your content before launch — the dry-run shows you exactly what will be inscribed for whom.

Organize as you go

Media can be added to, removed from, and moved between collections at any time before a batch is launched. Once a batch is funded and the engine starts inscribing, the content for that batch is locked.

Distribution

How collection items map to audience members is set on the campaign (distribution mode) — for example, every recipient gets the same item, or items are distributed across the audience. The dry-run plan shows the final item-to-wallet mapping so there are no surprises.

Next: Building Your Audience.

Building Your Audience

The audience is the set of Bitcoin addresses that will receive your inscriptions. Skrybit gives you two ways to build it — on-chain cohorts and manual targets — and you can combine both in one campaign.

Option 1: Cohorts (audience from on-chain behavior)

A cohort is a saved audience derived from real Bitcoin activity. Skrybit indexes the chain itself (ordinals, BRC-20, runes activity) and lets you target wallets by what they actually do:

• Prebuilt cohorts — ready-made segments like ordinals whales or recently active traders. On mainnet these are large, live segments (hundreds of thousands of wallets), refreshed from chain data.
• Custom cohorts — build your own from criteria (activity type, volume, recency, holdings), preview the size before saving, then save it under a name for reuse.
• Enrichment — optionally attach trader profiles, labels, and social handles to a cohort’s wallets so you can slice the audience further and report on who you reached.

Cohorts are network-scoped: a mainnet cohort targets mainnet wallets, a testnet4 cohort targets testnet4 wallets. Cohorts can be refreshed to pick up new chain activity before launch.

Workflow

1. Preview — define criteria and see the audience size instantly.
2. Build — save the cohort under a key when the size looks right.
3. Enrich (optional) — attach profiles/labels for reporting.
4. Attach — create the campaign from the cohort (or add it to one).

Option 2: Manual targets

Already know exactly who should receive the drop? Add addresses directly to the campaign as manual targets — paste a list of addresses (a snapshot from your community, an allowlist, partner wallets). Manual targets and cohorts coexist on the same campaign.

Sizing matters

Your audience size × collection items (per your distribution mode) is the inscription count — the single biggest factor in campaign cost. Preview cohort sizes and prune your audience before estimating, not after funding.

Next: Estimating Cost.

Estimating Cost

Before you launch anything, Skrybit answers the question every marketer asks first: “what would it cost to inscribe this whole campaign?”

Fee tiers: slow / normal / fast

Bitcoin transaction fees float with demand. Skrybit’s fee oracle tracks the live mempool and quotes three tiers:

The campaign cost estimate prices your entire campaign at each tier:

inscriptions = audience addresses × collection items (per distribution mode)
tier total   = inscriptions × (fee rate × inscription size + postage)

• Inscription size comes from your actual media — bigger payloads cost more per inscription.
• Postage is the small amount of sats that rides with each inscription into the recipient’s wallet (an inscription lives on real sats).
• The estimate may also include a cheapest-window hint from Skrybit’s fee forecaster — e.g. “inscribing in ~N hours could save X%” — useful when the drop is not time-critical.

The estimate excludes the platform service fee. The authoritative, all-in price (network cost + service fee) is fixed when the batch is created at launch — that is the exact amount you fund, and it will not change after you see it.

Dry-run the delivery plan

Separately from pricing, you can simulate a launch (dry-run). This runs the full planning path — audience resolution, distribution mapping, batch composition — and returns the plan without creating a batch or touching the chain:

• exactly which addresses receive exactly which items,
• the total inscription count,
• anything that would be skipped and why.

Make the dry-run your pre-flight check: if the plan looks wrong (audience too big, wrong collection linked, unexpected distribution), fix it now — after funding, the batch is in motion.

Next: Launching & Funding.

Launching & Funding

Launching turns your campaign into a batch — a priced, ready-to-inscribe unit of work. Funding it is the only on-chain action you take yourself; everything after that is automatic.

Launch

When the dry-run plan looks right, launch the campaign (pick your fee tier at launch time). Skrybit creates a batch and returns two things:

• a payment address — a fresh Bitcoin address dedicated to this batch;
• the total required — the exact amount in sats that funds the whole batch: network fees for every commit/reveal transaction, postage, and the platform service fee.

Nothing has touched the chain yet. The batch waits for funding.

Fund it — “Pay with UniSat”

You fund the batch from your own wallet. In the console, the batch funding row shows the network, the payment address, and the exact amount, next to a Pay with UniSat button:

1. Click Pay with UniSat.
2. The UniSat extension switches to the campaign’s network and opens its confirmation popup — showing the destination address and amount, signed from the wallet you choose in the popup.
3. Confirm. The extension broadcasts the payment and the console records the transaction id.

Prefer another wallet, an exchange withdrawal, or a treasury multisig? Send the exact amount to the payment address from anywhere — the button is a convenience, not a requirement. Skrybit watches the address either way.

What you are (and are not) signing

The payment is funding, not inscribing. Your wallet signs one ordinary Bitcoin send to the payment address. Skrybit’s engine then signs and broadcasts the actual inscription transactions, paid for out of your funding. Your keys never touch the inscription transactions, and Skrybit’s keys never touch your wallet.

Two practical notes:

• Send the exact amount. The batch is priced precisely; the engine starts when the required amount is confirmed at the payment address.
• No wallet registration required. Any wallet can fund a batch — paying never requires registering the address with Skrybit (see Wallets & Accounts).

After the payment confirms

The engine takes over within seconds of the funding confirmation — in the July 30, 2026 mainnet run, the first inscription transaction was broadcast 2 seconds after the payment confirmed. Follow along on the next page: Delivery Tracking.

Delivery Tracking

From the moment you fund a batch, everything is observable. The batch view in the console tracks each stage with the underlying transaction ids, so you can verify every step in any Bitcoin explorer.

The delivery pipeline

Each inscription is delivered with the standard ordinals two-transaction pattern:

Each confirmed stage normally takes one block (~10 minutes on average at the normal fee tier); the engine’s own steps between confirmations take seconds. A full mainnet delivery has been measured at ~30 minutes end-to-end including the funding payment and the recipient’s claim (see the timeline).

Verify it yourself

Every stage exposes its transaction id. The reveal transaction id is the inscription id (with an i0-style suffix) — paste it into an ordinals explorer to see the delivered inscription, its content, and the owning address. Skrybit verifies delivery against its own Bitcoin nodes, but you never have to take our word for it: it is all on-chain.

Resilience

The engine’s delivery ledger is reconciled against the chain continuously. If anything interrupts a batch mid-flight — an infrastructure restart, a temporarily unreachable node — the engine resumes exactly where the chain says it left off; funds at the payment address are never double-spent and inscriptions are never duplicated.

When it’s delivered

Delivered means delivered: the recipient’s wallet holds the inscription with no further action from you or them. What remains is the engagement layer — letting recipients discover and prove what they received: Managing Claims.

Managing Claims

Delivery puts the inscription in the recipient’s wallet. Claims are how recipients find out, prove it’s theirs, and connect with your campaign — the engagement half of the airdrop.

What a claim is

A claim is prove-and-acknowledge: the inscription was already airdropped directly to the wallet; claiming does not move anything on-chain. The recipient proves control of the receiving wallet with a cryptographic signature, and Skrybit records the claim against your campaign. You get an attributable, wallet-verified engagement event; the recipient gets confirmation that the inscription is genuinely theirs.

Opening claims

Claims are per-campaign and closed by default:

1. In the console’s Claims view, find your campaign.
2. Toggle claims open.
3. Copy the public claim URL and share it — in your announcement, your community channels, or directly to the airdropped audience.

The claim page is public and mobile-friendly, and requires no Skrybit account to view. While claims are open it shows the campaign name and media; when you close claims, the public read closes with it.

What recipients experience

The recipient opens the link, connects their wallet (UniSat or Xverse), signs a one-time message — no transaction, no fee — and the page confirms whether that wallet received the drop. The full recipient-side walkthrough is in the recipient guide, which is written to be linked directly from your own announcement if you prefer.

Privacy & anti-abuse properties

The claim surface is designed to leak nothing about your audience:

• No audience disclosure. The page never lists recipients. It answers yes/no for a single address, and only after that address has proven itself by signature — you cannot probe someone else’s wallet.
• Signature challenges are single-use and short-lived, bound to the specific campaign and address.
• Rate-limited public endpoints.

Tracking claims

The Claims view shows per-campaign claim state — open/closed and how many claims have been made — so you can measure engagement against the delivered audience and time your follow-up.

You Received an Inscription 🎉

Someone airdropped a Bitcoin inscription to your wallet and sent you a claim link. Here’s what that means — and what to do. It takes about a minute.

What you got

An inscription: a piece of media written directly onto Bitcoin itself and delivered into your wallet. It is not a token IOU or a voucher — it already lives on sats you control, permanently. Nobody can take it back, and you don’t need to do anything to keep it.

So why “claim” it?

Claiming just proves the wallet is yours and tells the sender you got it. It doesn’t move anything, doesn’t cost anything, and doesn’t need any BTC in your wallet.

How to claim

1. Open the claim link you were given — it works fine on your phone.
2. Connect your wallet — tap Connect and pick UniSat or Xverse. Use the wallet that received the drop.
3. Sign the message — your wallet shows a one-time message to sign. This is a signature, not a transaction: zero fee, nothing leaves your wallet, nothing to approve on-chain.
4. Done — the page confirms the inscription is yours.

Is signing safe?

Yes. The signature (a Bitcoin standard called BIP-322) only proves you control the address — it cannot spend your funds or grant any access. The claim page will never ask for your seed phrase or private key. If anything asks for those, close it: it’s not us.

“Wallet not in this campaign”?

• Make sure you connected the same wallet/address that received the inscription (check the address the sender used).
• Some wallets hold several addresses — try the one the drop was sent to.
• The campaign’s claim window may have closed — check with whoever sent the link.

Verified wallets

Signing once also verifies that wallet on Skrybit — if you make an account, the verified wallet is already attached to it, and future claims to the same wallet are instant. More in Wallets & Accounts.

Wallets & Accounts

Skrybit keeps the wallet model deliberately simple: one account, one list of wallets — and the only thing that distinguishes wallets in that list is whether they are verified.

One account, many wallets

Your Skrybit account (one login, shared across Skrybit products) can hold any number of Bitcoin wallets. Add a treasury address, your personal UniSat wallet, a partner payout address, mainnet and testnet4 addresses — they all live in the same list on your account page.

There are no separate registries to choose between and no jargon to learn up-front. A wallet is a wallet; verification is just a property of it.

Verified vs. watch-only

Every wallet in your list is in one of two states:

• Watch-only — you saved the address, no signature involved. Perfect for tracking, receiving, and labeling addresses you care about (including ones you can’t sign from, like an exchange or a cold-storage address).
• Verified ✓ — you proved ownership by signing a one-time message from the wallet (UniSat or Xverse, BIP-322 signature — no transaction, no fee).

What each can do

Two things worth calling out:

• Paying never requires registration. Funding a batch is an ordinary Bitcoin send from any wallet — saved, verified, or completely unknown to Skrybit. Saving a wallet just makes it convenient to reuse.
• Only claiming (and other act-on-your-behalf operations) needs verification, because those must prove the wallet is really yours.

Verify when you need to, not before

You never have to verify a wallet up-front. When you hit an action that needs verification — claiming an airdrop, say — Skrybit prompts for the signature right there, and the wallet upgrades from watch-only to verified in place. Same list, same entry, now with a ✓. Verification can also be re-run at any time (for example, after wallet migration) without losing the wallet’s history.

Networks

Wallets are network-scoped: a mainnet address and a testnet4 address are separate entries, and every operation says which network it acts on. Nothing crosses between networks implicitly.

API Reference

Skrybit is API-first: everything the console does — collections, media, cohorts, campaigns, launch, funding status, claims, wallets — is a documented HTTP API underneath.

The live spec is the source of truth. The API serves its own OpenAPI document at /openapi.json on the console origin, generated directly from the running backend — so it is always in sync with the deployed code. Any static endpoint table in these docs would rot; fetch the spec instead, or load it into your favorite OpenAPI tooling (Swagger UI, Postman, client generators).

Reading the spec

Conventions used across the API:

• Base path — product endpoints live under /api/v1/…, grouped by resource: campaigns, collections, media, cohorts, wallets, claims, fees, and friends. A handful of operational endpoints (/health, the root) sit outside /api/v1.
• Methods — standard REST semantics: GET reads, POST creates or triggers (e.g. POST /api/v1/campaigns/{id}/launch), PUT/PATCH update, DELETE removes.
• Networks — network-scoped endpoints take an explicit network parameter (mainnet or testnet4). There is no implicit default across products; when in doubt, pass it.
• Authentication — operations that act on your account or campaigns require an authenticated request (an Authorization header carrying your Skrybit token). In the OpenAPI spec these are the operations with a security requirement or an authorization header parameter. Public surfaces — like the recipient claim challenge/verify endpoints and open claim-page reads — are unauthenticated by design, rate-limited, and only expose safe fields.

A future interactive reference

The former console Docs page rendered the live spec as grouped, collapsible endpoint tables (grouped by the first path segment after /api/v1, one row per method with color-coded badges, an auth-lock marker per operation). This site will regain that interactive rendering in a future revision — generated live from /openapi.json, never checked in as a static snapshot.

Until then: GET /openapi.json — generated live from the running API, always current.