# Inscribe documentation, full corpus
===== inscribe-docs/404 =====
# That page is not here
The page you asked for does not exist on this documentation site. Here is where to go instead.
Nothing lives at that address. This is the documentation site, not the app.
## If you were looking for a workspace
Workspaces live in the app at
[inscribe.bitcoinuniverse.io](https://inscribe.bitcoinuniverse.io), not here. The
[workspace map](/docs-inscribe/reference/workspaces/) lists every one of them and what it is
for.
If you reached a 404 **inside the app** at Recover Sats or the Dogecoin BlockPad, that is a
switched-off feature rather than a broken link. Those two surfaces return a 404 when their
feature is off. See [status and lifecycle](/docs-inscribe/start/status/).
## If you followed an old link
This repository used to be flat Markdown files. Old paths redirect, but a link with a `.md`
extension will not.
[Where pages moved](/docs-inscribe/about/migration/) maps every old file to its new home.
## The usual destinations
- [Start here](/docs-inscribe/start/what-inscribe-is/)
- [Your first inscription](/docs-inscribe/start/first-inscription/)
- [What a transaction costs](/docs-inscribe/concepts/what-it-costs/)
- [Recovery routes](/docs-inscribe/manage/recovery/), if something has gone wrong
- [Coverage matrix](/docs-inscribe/protocols/coverage/)
Or use the search box at the top of the page. It searches every page on this site and works
without contacting anything outside it.
## Something is missing
If a page you expected should exist,
[open an issue](https://github.com/bitcoinuniverseio/docs-inscribe/issues) and say what you
were looking for.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
===== inscribe-docs/about/changelog =====
# Changelog
What changed in this documentation, and where to find the changelog for the Inscribe product itself.
This is the changelog for **this documentation**, not for the Inscribe product.
Inscribe itself is released continuously from verified commits and does not carry a version
number to quote. What identifies a build is its commit, and the footer of every page in the
app names the build you are looking at. See
[release evidence](/docs-inscribe/about/release-evidence/).
## 2026-09-01: rebuilt as a documentation site
The repository was a set of flat Markdown files. It is now a built site with search,
navigation and per-page provenance.
### Added
- A structure separating tutorials, task guides, concepts, protocol reference,
troubleshooting and safety, in place of one directory of files.
- Nine task guides covering inscribing files and text, batches, collections, deploys, mints,
etches and transfers, each stating its prerequisites, wallet support, network, costs,
safety considerations, exact steps, the wallet screen to expect, verification and a
recovery route.
- A [coverage matrix](/docs-inscribe/protocols/coverage/) generated from the Bitcoin
Universe protocol registry, plus seven protocol family pages.
- [The life of an order](/docs-inscribe/concepts/order-lifecycle/), documenting commit and
reveal, payment detection, and what the four order states cover.
- [Recovery routes](/docs-inscribe/manage/recovery/), collecting every route back from an
unpaid, underpaid, stuck or interrupted order, and naming the one situation that has none.
- [Wallets and the two addresses](/docs-inscribe/concepts/wallets-and-addresses/) and a
[wallet matrix](/docs-inscribe/reference/wallets/) recording the known limitations of each
integration.
- Reference pages for [fee tiers](/docs-inscribe/reference/fee-tiers/),
[order states](/docs-inscribe/reference/order-states/) and a
[glossary](/docs-inscribe/reference/glossary/).
- Local search, dark and light themes, and source provenance on every material page.
### Corrected
- **Order expiry.** Earlier text said an order with no payment inside one hour expires.
It does not. The hour is the life of the price quote; the order is not deleted, the
signing key is not discarded, and a late payment is still detected and reconciled. This
was the most consequential error in the previous text, because it would have encouraged
someone who had already paid to pay again.
- **Asset safety scope.** The claim that no Inscribe flow will spend an asset-bearing output
is now stated precisely: no **automatic** funding flow will. The Advanced TX Builder
deliberately lets you spend one after labelling it, and that is now documented rather than
omitted.
- **Release state.** Protocol availability is now taken from Inscribe production contract
rather than from what exists in the interface. Four workspaces present in the app are
recorded as not released, and the pages say so.
### Removed
- Operational detail that belongs in private engineering documentation rather than in a
public product site: database migration procedure, and infrastructure topology beyond what
a reader needs to understand where their data comes from.
## Before 2026-09-01
The repository history carries 44 commits of incremental documentation, beginning 2026-08-19
with the Control Center guide. The substance of every accurate page from that period has been
preserved here rather than rewritten. The most significant entries:
| Date | What was documented |
| --- | --- |
| 2026-08-31 | The unread chain-tip health state |
| 2026-08-30 | The theme architecture, and how contrast is checked |
| 2026-08-29 | What a transaction costs; the warning shown before a wallet payment; the workspace map; what happens when a release lands under an open tab |
| 2026-08-28 | Getting back to an order after closing the tab; what the portfolio shows while a source is down; the production preload budget |
| 2026-08-27 | Index height health states |
| 2026-08-26 | Asset safety; same-origin Bitcoin data relay |
| 2026-08-22 | Delivery performance, response caching and the media gateway |
| 2026-08-19 | The Control Center |
Full history:
[github.com/bitcoinuniverseio/docs-inscribe/commits/main](https://github.com/bitcoinuniverseio/docs-inscribe/commits/main).
## Where pages moved
Every page from the previous structure has a new home. See
[where pages moved](/docs-inscribe/about/migration/).
## Related
- [Release evidence](/docs-inscribe/about/release-evidence/)
- [Status and lifecycle](/docs-inscribe/start/status/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/about/migration =====
# Where pages moved
Every file from the previous flat structure and where its content now lives, plus the redirects that keep old links working.
This repository was a set of Markdown files read on GitHub. It is now a built site. Nothing
accurate was discarded; several pages were split, because a single file was covering two
different questions.
## The map
| Was | Is now |
| --- | --- |
| `README.md` | [The homepage](/docs-inscribe/), and [what Inscribe is](/docs-inscribe/start/what-inscribe-is/) |
| `workspaces.md` | [Workspace map](/docs-inscribe/reference/workspaces/) |
| `what-it-costs.md` | [What a transaction costs](/docs-inscribe/concepts/what-it-costs/), with [fee tiers](/docs-inscribe/reference/fee-tiers/) split out as reference |
| `asset-safety.md` | [Asset safety and UTXO classification](/docs-inscribe/concepts/asset-safety/) |
| `protocol-data-status.md` | Split three ways: [where the data comes from](/docs-inscribe/concepts/source-freshness/), [orders you started](/docs-inscribe/manage/pending-orders/), and [failure states](/docs-inscribe/troubleshooting/failure-states/) |
| `accessibility.md` | [Accessibility](/docs-inscribe/about/accessibility/) |
| `performance-and-media.md` | [Speed and media](/docs-inscribe/about/performance-and-media/) |
| `release-evidence.md` | [Release evidence](/docs-inscribe/about/release-evidence/) |
| `social-previews.md` | [Link previews](/docs-inscribe/about/social-previews/) |
| `admin-control-center.md` | [Control Center](/docs-inscribe/about/control-center/) |
| `assets/two-addresses.svg` | Redrawn inline in [wallets and the two addresses](/docs-inscribe/concepts/wallets-and-addresses/) |
| `assets/order-lifecycle.svg` | Redrawn inline in [the life of an order](/docs-inscribe/concepts/order-lifecycle/) |
## Why `protocol-data-status.md` was split
It answered three questions that different readers arrive with:
- **"Is the data I am looking at current?"** is a concept, and is now
[where the data comes from](/docs-inscribe/concepts/source-freshness/).
- **"How do I get back to my order?"** is a task, and is now
[orders you started](/docs-inscribe/manage/pending-orders/).
- **"What does this error mean?"** is troubleshooting, and is now
[failure states](/docs-inscribe/troubleshooting/failure-states/).
Someone whose payment has not appeared should not have to read about index architecture to
find out what to do.
## Redirects
Old paths redirect to their new homes, so a link to `/docs-inscribe/what-it-costs/` still
arrives at the right page. The redirect list lives in `astro.config.mjs` and is part of the
build.
Links to the Markdown files on GitHub still work as they always did, because the files
remain in the repository history.
## The diagrams
Both SVG diagrams were redrawn rather than moved. The originals were fixed dark-only images
with the colours written into the file, so they were illegible in the light theme.
They are now inline SVG using the same colour roles as the rest of the site, so one drawing
serves both themes, and each carries a title and a full description for anyone reading with
a screen reader.
## Related
- [Changelog](/docs-inscribe/about/changelog/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/concepts/asset-safety =====
# Asset safety and UTXO classification
How Inscribe decides which outputs it may spend on your behalf, the three classification states, why unknown is never treated as safe, and the one surface that deliberately lets you spend an asset.
Inscribe will not pay a fee with an output that holds your assets.
## Why this matters
Bitcoin spends an output whole. An output holding an inscription, a Rune balance or a
token balance looks identical to ordinary bitcoin to software that only checks the amount.
If a tool picks that output to cover a network fee, the asset goes with it, and there is
no way back.
This is not a rare edge case. Trust Wallet dropped inscription support in March 2026 and
warned its users that bitcoin sent from an address holding inscribed outputs could spend
those outputs by accident.
## The three states an output can be in
Every output Inscribe looks at is classified, and the classification has three values
rather than two. The third one is the important one.
| State | What it means | Used to pay a fee? |
| --- | --- | --- |
| **Assets detected** | An index positively reported an inscription, Rune balance or token balance on this output | Never automatically |
| **No known risk** | A complete, untruncated scan read this output and found nothing on it | Yes, and these are used first |
| **Unverified** | The scan did not complete, was cut short, or the source could not answer for this output | Yes, but only after the cleared ones |
Each classification carries its own receipt: which index answered, when it answered, and
which network the answer describes. A stale or wrong-network answer is not treated as an
answer.
The state that does the work is the first one. The product's own wording for the third is
the sentence to remember:
> Unknown is not the same as safe.
"No known risk" is only awarded when detections came back empty **and** the core metadata
was actually present **and** nothing was truncated **and** every outpoint was covered.
Anything short of that is unverified, not clear. Absence of evidence is never recorded as
evidence of absence.
## What Inscribe does with that
Every flow that chooses funding outputs for you asks what each output holds before it
picks anything.
- An output reported as holding an asset is **never** chosen automatically.
- An output with a complete scan showing plain bitcoin is chosen **first**.
- An output nothing could be established about is chosen **only after** those.
Everyday flows go further than ranking: they fund fees from plain-bitcoin outputs only.
UTXO Split lists only plain bitcoin outputs large enough to cover the outputs, the network
fee and the service fee. Sending an inscription pulls in only plain bitcoin outputs to
cover its fee.
Nothing here stops you from spending an asset-bearing output on purpose. It stops Inscribe
from doing it on your behalf.
## The one place this is deliberately left to you
The **Advanced TX Builder** has an inscription-output picker, and it will let you spend an
output carrying an inscription or a Rune. It labels them, with a badge naming the
inscription number and a badge marking a Rune, and then it lets you proceed.
That is a decision, not a gap. The builder exists for people who need to place a specific
satoshi in a specific position, which is not something a safety rule can do for you. Where
the satoshi ends up is your responsibility on that screen.
Every other surface that lets you choose outputs shows the asset report for each one
first:
- **Split UTXO** shows a full asset preflight report per output.
- **Custom transaction** lists your outputs with their classification.
## When funding is short
If Inscribe holds outputs back and the remaining balance cannot cover the action, it tells
you how many outputs were held back, how many satoshis they hold, and why. You are never
told to add bitcoin you already have.
To free the balance, send plain bitcoin to the address, or lower the fee rate.
## What Inscribe does not claim
It reports what the asset index knows. Where the index has no answer for an output,
Inscribe says so rather than calling the output safe. A selection is never described as
"safe": the screening removes outputs the index flagged, and it does not prove the rest
are clean.
Coverage has stated limits rather than hidden ones. When a lookup hits a cap on how many
items or groups it will read, the count is marked as a lower bound and the reason says so,
instead of a truncated list being presented as the whole picture.
If the private infrastructure cannot answer at all, the funding flow stops with an error
rather than returning an unscreened list of outputs. Failing closed is the point.
## The warning before a wallet payment
When you send bitcoin through your wallet's own send screen, your wallet chooses the
outputs, not Inscribe. Immediately before your wallet opens, Inscribe scans the address the
payment will come from and lists any outputs that hold assets:
> **The address you are paying from holds assets.** Your wallet chooses which outputs pay
> for this. If it spends one of these, the asset it carries goes with it, and Inscribe
> cannot bring it back. Pay from an address that holds only bitcoin, or pick the inputs
> yourself in your wallet before you approve.
It lists the outpoint and what each output carries. It does not stop you. The wallet owns
the selection, you may have a good reason to pay from that address, and an app that
blocked you would be wrong more often than it was right.
Only outputs the index positively identified appear. An output with an incomplete, stale,
or out-of-network scan is not listed, and is also never picked automatically.
## What can be detected
The asset inventory for an output recognises around thirty categories, including BRC-20,
ARC-20, CAT-20, Runes, Ordinals, Bitmap, rare sats, Stamps, SRC-20, SRC-101, Atomicals,
Alkanes, Mezcal, DMT, TAP, UNAT, BLOCK-20, DUST-20, OP-20, OP Names, OP_RETURN, Drops,
OP_DROP and Tandem. Anything it cannot place is shown as **Unclassified** rather than
dropped from the list.
Tandem state carriers get a firmer line than the rest: they cannot fund ordinary sends,
mints, replacements or recovery plans at all.
## A note on addresses
An Ordinals wallet keeps two addresses with different jobs, and the difference is the
reason none of this can be simplified into one balance. Read
[wallets and the two addresses](/docs-inscribe/concepts/wallets-and-addresses/).
## Related
- [Advanced transaction tools](/docs-inscribe/manage/advanced-transactions/)
- [Recovery routes](/docs-inscribe/manage/recovery/)
- [Where the data comes from](/docs-inscribe/concepts/source-freshness/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/concepts/order-lifecycle =====
# The life of an order
How an Inscribe order goes from a quote to an asset in your wallet, what you sign and when, how payment is detected, and what happens when the hour runs out.
Most creation flows in Inscribe use two transactions, not one. Knowing which is which
explains almost everything else: why you sign once rather than twice, why the app keeps
saying "in progress" after your transaction confirmed, and why closing the tab does not
lose your money.
## The path, end to end
You act in stages 1 and 2. Everything after that happens on Universe infrastructure and
on Bitcoin, and continues whether or not your browser is open.
## Commit and reveal, in plain terms
An inscription cannot be written in one transaction. The content is committed to in the
first transaction and revealed by the second.
1. **Inscribe builds the script** for what you are inscribing and works out how big the
reveal transaction will be.
2. **It generates a fresh key for this order alone** and derives one address from it, the
commit address.
3. **You pay that address one amount**, which covers the reveal's network fee, the service
fee, and the satoshi your inscription will sit on. That payment is the commit
transaction, and it is yours: your wallet builds it and your wallet signs it.
4. **Universe spends the commit output** in the reveal transaction, which is what actually
carries your content onto the chain. It signs that with the order's own key, which is
why you are not asked a second time.
The reveal has your inscription as its first output, the service fee as its second, and a
refund output as a third when you have overpaid.
## What you sign, and how many times
**One signature, for a typical order.** That is the commit payment in stage 2. The reveal
needs no signature from you.
Two flows ask for a second signature, and both have a good reason:
| Flow | Why a second signature |
| --- | --- |
| Parent and child | The reveal has to spend the parent inscription you already own, and only your wallet can authorise that. The order waits for your signature, and the prepared transaction is good for 15 minutes |
| Bring your own satoshi | You fund two addresses, the commit address and a separate address holding the exact satoshi you want inscribed. The reveal waits for both |
For the parent flow there is an extra check worth knowing about: before it accepts your
parent, the server re-derives the parent's output script and refuses it unless it matches
what the chain indexer currently reports for that inscription. A parent that has moved
since you loaded the page is rejected rather than spent.
## How the payment is noticed
Universe watches the commit address rather than waiting for you to tell it anything. A
monitor checks waiting orders **every ten seconds**.
- **An unconfirmed payment is enough.** As soon as the payment is visible in the mempool,
the reveal can be built and broadcast. A standard single inscription needs **zero
confirmations** to move forward.
- **The smallest sufficient payment is used.** If several payments land on the address,
Inscribe prefers one matching the quote exactly, then the smallest one that covers it.
Taking the largest would swallow an accidental overpayment that belongs to you.
Bulk jobs are different, because they fan a payment out across many addresses first and a
fan-out that gets reorganised would strand the whole job:
| Batch size | Confirmations required before the job proceeds |
| --- | --- |
| Up to 22 items | None. The payment is fanned out directly |
| 23 to 500 items | 1 |
| More than 500 items | 2 |
Batch reveals are also broadcast in chunks of no more than 24, because Bitcoin's mempool
refuses a chain of more than 25 related unconfirmed transactions.
## Why "in progress" outlasts your confirmation
A reveal that confirmed is not the same thing as an asset you can see and use. The
indexer still has to read the block and attribute the inscription, and your wallet still
has to report it.
Inscribe treats broadcast, confirmed and even indexed as **still in progress**, and only
says the order is done when the indexer and your wallet agree the asset exists. The status
line says so in as many words:
> Creation in progress, waiting for chain, indexer, and wallet evidence.
This is deliberate. Claiming success at broadcast would be right most of the time and
wrong in exactly the cases where being wrong costs you the most.
## What the hour means
Most flows quote a price good for **one hour**. The gallery flow quotes for 24 hours.
The on-screen warning asks you to pay within the hour, and you should: after it passes,
the fee rate you were quoted may no longer get your transaction mined, and the right move
is to start a new order at a current price.
What the hour does **not** do is destroy the order:
- The order does not move to a cancelled or expired state. No such state exists for
inscribe orders.
- The signing key is not erased. A key is only discarded after a confirmed successful
spend, or after an explicit recovery that hands control somewhere else. It is never
discarded because a data provider timed out, returned nothing, or hit a retry limit.
- The address keeps being checked, on a slowing schedule, so a payment that arrives late
is still found.
If you have already paid and the hour has passed, do not pay again. Go to
[recovery routes](/docs-inscribe/manage/recovery/).
## When a broadcast fails
A reveal that fails to broadcast is retried, not abandoned. Before the first network call
is made, the exact signed transaction is written down, so a retry can only ever send the
same transaction rather than a new one. Retries back off from 30 seconds up to a cap.
This is what makes it safe for the system to try again without your involvement: there is
no version of the retry that spends your money twice.
## Related
- [What a transaction costs](/docs-inscribe/concepts/what-it-costs/)
- [Order states](/docs-inscribe/reference/order-states/), every status and what it means
- [Orders you started](/docs-inscribe/manage/pending-orders/), getting back to one
- [Recovery routes](/docs-inscribe/manage/recovery/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/concepts/source-freshness =====
# Where the data comes from
The six states a data source can be in, how Inscribe reports a source that is down or catching up, why an empty result is never shown as an answer, and what stays working.
Inscribe keeps protocol construction tools separate from live discovery data. A provider
problem in one protocol does not disable unrelated pages, wallet access, or inscription
workflows.
The rule underneath every state on this page: **a source that did not answer is never
reported as a source that answered with nothing.**
## The six states
A data source is in exactly one of these, and the app names which:
| State | What it means |
| --- | --- |
| **Live** | Answering, and current with the chain |
| **Live, currency unverified** | Answering, but it reports no height, so how current it is cannot be checked |
| **Tip not verified** | Answering with a height, but the chain tip could not be read, so the two cannot be compared |
| **Behind** | Answering with a height that trails the chain tip |
| **Unavailable** | Not answering |
| **Unknown** | The payload named a source but not a state this build understands |
Two of those exist because a plain HTTP success is not proof of anything. A source can be
up, reachable and returning valid data while being a thousand blocks behind, and a source
can report a height while the chain tip it should be compared against is unreadable.
Collapsing either into "healthy" would be a lie with a green dot next to it.
Separately from all six, a capability an operator has switched off is reported as
**switched off by the operator**, not as a source being down. They are different problems
with different fixes, so they are never shown as the same thing.
## What you actually see
The app does not reduce this to one word.
- **A banner names the source** and says that everything which does not read it is working
normally. It does not claim the wait will be short.
- **"See what is affected" opens the service status panel.** Each source shows its state,
the block it has reached against the chain tip, how many blocks behind that leaves it,
and the workspaces that read it. Sources that are answering are listed too, so it is
clear what is unaffected.
- **Actions that write to the chain stay paused**, and the reason names the source and
states that nothing already signed or broadcast is at risk. Reading, drafting, and your
wallet keep working.
When a source is rebuilding its index, the panel shows how fast it is reading blocks,
measured from the heights your browser has actually seen since you opened the page, and
what that pace implies for the rest. Until there is enough measurement it says so rather
than showing a completion time it cannot support.
A workspace stays visible even when the index behind it is down or catching up. It says so
instead of disappearing, because a missing workspace looks like a product that never had
the feature.
## Availability labels on a workspace
- **Available**: the source answered and is at the chain tip.
- **Degraded**: the source answered but is behind, or one of several sources did not
answer. Reads still work, and the page names what is missing.
- **Unsupported**: the source is not running for this network. Nothing is guessed or
filled in from elsewhere.
## What the portfolio shows while a source is down
The portfolio reads several independent sources: the Bitcoin node for your balance, the
Ordinals index for inscriptions and Runes, and separate indexes for Mezcal, SRC-20,
OP_DROP and OP_RETURN names. One of them being down does not empty the page; the rest
still answer and what they report is still shown.
When a source does not answer, the portfolio names it above your holdings and says that
anything held there is missing from the page, that what is shown is everything the sources
that did answer reported, and that nothing you own has changed. The header reads
**Partial** rather than **Live** for as long as that is true.
An empty portfolio is never presented as an answer while a source is silent. The page says
that nothing was found in the sources that answered, and that this is not a complete
picture of what the address holds. "No assets found for this address" appears only when
every source answered.
This applies per source. If only the Ordinals index is behind, your Mezcal, SRC-20 and
OP_DROP balances are still real numbers from indexes that answered.
## Where the reads come from
Blockchain reads come from Universe-operated nodes and indexes rather than public
third-party APIs, so the data path is accountable end to end. Public blockchain providers
are not used as a fallback: if the private source cannot answer, the app says so instead
of quietly asking someone else.
Browser requests for fees, transactions, addresses and outputs stay on the Inscribe origin.
The API relays only reviewed read paths onward, so wallet and payment screens never connect
to an indexer or a public explorer directly.
Two things follow from that, and both are stated rather than hidden:
- **A missing indexed height is never filled in from somewhere else.** If the authoritative
height cannot be read, the report carries no height and says it is not synchronised. It
does not borrow a number from the node or an explorer to make the shape look complete.
- **Readiness tolerates a small lag and no more.** The index is expected to sit a block or
two behind a moving chain tip. Beyond the configured tolerance, or with a negative or
unreadable lag, readiness fails rather than rounding in its own favour.
Some protocols require more than one independent source to agree before they are treated as
ready. Where two verifiers disagree about a finalized block, readiness stays unavailable
rather than picking one.
## Safety gates
Some research protocols remain visible for documentation or controlled-network work while
production actions stay disabled. Universe does not turn these on merely to make a status
page look healthy. Mainnet writes require the protocol's network profile, independent
authorization, an authoritative index, transaction safety checks, and a verified readiness
canary.
CAT-20 transaction features remain fail-closed when the required Fractal data and signing
dependencies are unavailable. Market discovery reports that dependency state directly
instead of returning a misleading empty market.
## Fee data specifically
Fee rates refresh every 30 seconds. If the source stops answering, the fee control shows
**Cached fees** in place of the refresh countdown, so a stale number is visibly stale.
On a network where a fabricated rate would be worse than no rate, Inscribe refuses to quote
and reports the service as unavailable rather than serving a fallback price.
## Related
- [Failure states](/docs-inscribe/troubleshooting/failure-states/)
- [What a transaction costs](/docs-inscribe/concepts/what-it-costs/)
- [Asset safety](/docs-inscribe/concepts/asset-safety/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/concepts/wallets-and-addresses =====
# Wallets and the two addresses
Why an Ordinals wallet keeps a payment address and an Ordinals address, what each one is for, how Inscribe keeps them apart, and which wallets it connects to.
The single most useful thing to understand before you spend anything: your wallet almost
certainly has two Bitcoin addresses, and they do different jobs.
## One wallet, two addresses
Inscribe reads both addresses when it shows your holdings, and signs each action from the
address that actually holds what it moves.
An Ordinals wallet keeps a payment address for spendable bitcoin and a Taproot Ordinals
address for inscriptions, Runes and token balances. Inscribe reads both, keeps them apart,
and signs each action from the address that actually holds what it moves.
The bitcoin balance card reports the payment address on its own. Satoshis sitting at an
Ordinals address are carrying assets and are not spendable from there, so adding the two
figures together would tell you that you can spend money you cannot.
There is one rule the product holds itself to, and it is worth knowing as a reader:
> Payment addresses fund orders. Destination and recipient addresses receive assets. A
> wallet adapter must not silently substitute one for the other.
## Which address does what
| Question | Answer |
| --- | --- |
| Which address pays for an order? | The payment address |
| Which address receives the inscription? | The Ordinals address, or whatever destination you name |
| Which address pays a network fee? | The payment address, funded only from screened plain-bitcoin outputs |
| Which address signs a transfer of an inscription? | The one holding it, which is the Ordinals address |
| Which balance is "my bitcoin"? | The payment address balance |
## Supported wallets
Inscribe connects to five wallets. All five are production integrations.
| Wallet | What it covers | Address model |
| --- | --- | --- |
| Universe | The Bitcoin Universe wallet | Payment and Ordinals addresses |
| UniSat | Ordinals, BRC-20, Runes | Payment and Taproot addresses |
| Xverse | Ordinals, Stamps, Runes | Payment and Ordinals addresses, declared explicitly |
| OKX | Multi-chain | Payment and Ordinals where the provider exposes them |
| Wizz | Bitcoin, Ordinals, Atomicals and Runes | One active address, see below |
Two limitations are worth reading before you pick one:
- **Wizz exposes a single active address.** Inscribe does not invent a second one to fill
the gap, so a flow that genuinely needs two distinct addresses behaves differently here.
Mobile support varies by Wizz version, and an optional operation the installed version
does not support fails rather than silently doing something else.
- **UniSat sessions are not revived from memory.** If the extension cannot confirm a live
active account, Inscribe drops the session rather than trusting a stored address. You
reconnect; you never act against an address the wallet has not just confirmed.
If Universe Wallet is not installed, its install action and the `/wallet` shortcut open
the reviewed browser-store listing.
The wallet chooser keeps network, retry and diagnostic controls under **Connection
options**, so the first choice stays focused on picking a wallet.
## How Inscribe tells the two apart
By address form. A Taproot address, one starting `bc1p` on mainnet, is treated as the
Ordinals address, because that is where inscriptions live. When a wallet exposes only one
address, that address is used for both jobs, and Inscribe does not pretend otherwise.
When it looks up what you hold, it checks Taproot addresses first for the same reason.
## You do not need a wallet to look
Connecting is required only for actions needing a signature. Without a wallet you can:
- browse every workspace and read live protocol data;
- price an action in full, including the fee tiers;
- paste any address into **Explore** and see everything it holds;
- track addresses in **Watchlist** without connecting them.
## What Inscribe cannot control
When you send bitcoin from your wallet's own send screen, your wallet chooses which
outputs to spend, not Inscribe. Inscribe warns where it can see a risk, but it cannot
change that selection. Read [asset safety](/docs-inscribe/concepts/asset-safety/) for what
that warning says and when it appears.
## Related
- [Asset safety](/docs-inscribe/concepts/asset-safety/)
- [Wallet matrix](/docs-inscribe/reference/wallets/)
- [Your first inscription](/docs-inscribe/start/first-inscription/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/concepts/what-it-costs =====
# What a transaction costs
The three amounts in an Inscribe quote, what each satoshi buys, how a fee rate is chosen, and why only two of the three lines are fees.
Every Inscribe action that writes to Bitcoin shows its full cost before your wallet
opens. Nothing is signed or paid until you approve the amounts on the confirmation
screen.
This page explains the numbers on that screen.
## The three parts of a total
A quote has three lines and one total. Two of the lines are fees and are gone once the
transaction confirms. The third is the satoshi your inscription sits on, and it stays in
your wallet.
**Network fee.** What miners are paid to include your transaction. It is the fee rate you
pick, in satoshis per virtual byte, times the size of the transaction. A larger
inscription costs more because it is bigger, not because Inscribe charges more for it.
**Service fee.** A flat 1,500 satoshis for most actions, charged once per order rather
than per item. Some flows differ and say so on the confirmation screen: an `op_names`
batch pays the flat fee once per name, and Mezcal quotes its own amount. Splitting a batch
across separate outputs charges the fee per output rather than once. Fixing a stuck
payment and recovering padding sats charge no service fee at all.
**The inscription output.** Your inscription lives on a satoshi, and that satoshi has to
sit in an output of its own. The default is 546 satoshis, and 330 is offered as the
smaller standard size. This is not a fee. It stays with your inscription, and you still
own it.
The confirmation screen lists these separately and then adds them up. On screen the labels
read **Network Gas Fee**, **Mint UTXO Value** where the protocol carries an output,
**Service Fee**, and **Total Cost**.
A quote, as the confirmation screen itemises it
Line
Goes to
Example
Network Gas FeeFee rate times transaction size
Miners
1,500
Service FeeFlat, once per order
Universe
1,500
Mint UTXO ValueThe satoshi your inscription sits on
You
546
Total Cost
3,546 sats
The example is a small inscription at 10 sat/vB. Your own network fee moves with the size
of what you are inscribing and the rate you choose. The other two lines do not.
## How big is the transaction?
The size is decided by what you are inscribing, not by a setting. Inscribe estimates it
from the actual script it is about to build, so the figure on screen describes a real
transaction rather than a flat guess.
Two things worth knowing:
- **Inscribing a child under a parent adds about 101 virtual bytes**, because the parent
output has to be spent and returned.
- **The service fee output costs bytes too.** It is a real output on the transaction, so
you pay a little network fee for carrying it. That is already inside the total.
The figure shown before you create the order is a preview. The order the backend builds
carries the authoritative price, and that is the amount the payment screen asks for.
## Choosing a fee rate
Inscribe offers three tiers, quoted from Universe's own Bitcoin infrastructure and
refreshed every 30 seconds.
| Tier | What it targets |
| --- | --- |
| Normal | A place in the blocks mined over roughly the next half hour |
| Fast | A place in the next block, roughly ten minutes |
| Custom | Any rate you type |
Normal is selected when you arrive, and it is the tier marked Recommended. The default is
never the more expensive option.
The wait shown on each tier is the wait its rate has earned, not a label fixed in advance.
Bitcoin block times are random, so these are averages rather than promises.
Rates are accepted between 0.1 and 10,000 sat/vB. Some protocols raise that floor or round
to whole satoshis, and the fee control uses the protocol's own minimum where it has one.
### When Normal and Fast cost the same
Blocks are not always full. When there is room in the next block, the rate that gets you
into it is the same rate that would have got you in within half an hour, and both tiers
quote the same number.
Inscribe says so, on both tiers, rather than printing a shorter wait next to the
higher-sounding option:
> Blocks have room right now, so Normal costs the same as Fast and confirms just as soon.
Two prices that are the same number are the same purchase. Paying more for one of them
would buy nothing, so the screen does not offer it as if it would.
Some protocols round fee rates up to whole satoshis or apply a higher relay floor. That
can also land both tiers on one rate, and the same note appears for the same reason.
### Rates below 1 sat/vB
The **Sub 1** control accepts rates under one satoshi per virtual byte. These are real
rates that real miners sometimes accept, and they can take a long time or never confirm.
The control is marked Beta, shows the exact rate you have chosen, and never becomes the
default.
## Choosing the output size
The satoshi your inscription sits on defaults to 546. You can lower it to 330, or type a
value of your own.
330 is not an arbitrary floor. Bitcoin relays refuse outputs below a dust threshold that
depends on the address type, and for the Taproot and P2WSH addresses inscriptions use,
that threshold is 330 satoshis. An order asking for less falls back to the computed dust
limit rather than building a transaction the network would reject.
| Address type | Dust threshold |
| --- | --- |
| P2WPKH | 294 sats |
| P2WSH and Taproot | 330 sats |
| Legacy or unrecognised | 546 sats, used as a safe fallback |
Lowering the output saves 216 satoshis and makes that output harder to move later, because
a smaller output leaves less room to pay a fee out of it. That is why 546 is the default.
## Why the cost is shown first
An inscription is not reversible. Once a transaction is signed and broadcast, the fee is
spent whether or not the result is what you wanted. Showing the amounts before the wallet
opens is the only point at which the choice is still yours.
The same rule shapes the rest of the flow:
- The content preview shows exactly what will be inscribed, before payment.
- The confirmation screen names the receiving address and the operation type.
- No automatic funding flow picks an output holding an inscription, Rune, or token balance
to pay a fee. Read [asset safety](/docs-inscribe/concepts/asset-safety/).
## If you overpay
Pay more than the quote and the surplus comes back. The reveal transaction adds a third
output sending the extra to the address that funded the order, as long as that surplus is
large enough to survive the extra bytes it costs and still clear the dust threshold. If it
is not, it is added to your inscription output instead, where you still own it.
This matters most for manual payments, where it is easy to send a round number rather than
the exact quote.
## If you underpay
The order is not lost. It stays waiting, records that the payment was below the quote, and
keeps checking. Top the address up to the quoted amount and the flow resumes. Nothing is
cancelled and no key is discarded. See
[recovery routes](/docs-inscribe/manage/recovery/).
## Reading a cost with a screen reader
Each fee tier is a button whose accessible name carries the tier, the rate in satoshis per
virtual byte, and the wait, so the price is available without reading the visual card. The
recommended tier says that it is recommended.
## When fee data is unavailable
Fee rates come from Universe-operated Bitcoin infrastructure. If that source stops
answering, the fee control says **Cached fees** instead of counting down to the next
refresh, so you can see that the number in front of you is not fresh. A stale quote is
never presented as a live one.
On networks where a made-up rate would be worse than no rate, Inscribe refuses to quote at
all rather than serve a fallback price. Read
[where the data comes from](/docs-inscribe/concepts/source-freshness/).
## Related
- [The life of an order](/docs-inscribe/concepts/order-lifecycle/), which spends this money
- [Fee tiers](/docs-inscribe/reference/fee-tiers/), as a reference table
- [Asset safety](/docs-inscribe/concepts/asset-safety/), which decides what pays the fee
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/batch =====
# Inscribe in a batch
Inscribe up to 1,000 items in one job, how the payment is fanned out, why bigger batches wait for confirmations, and what the service fee does across a batch.
**Who this is for.** Anyone inscribing many items at once: a numbered series, a word list,
a set of files.
**Goal.** Many inscriptions from one payment and one signature.
## Prerequisites
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet |
| Workspace | **Inscribe**, at `/inscribe`, the **Text** sub-tab in bulk mode |
| Destination | **Ordinals only.** Drops, OP_RETURN and Stamps force single-item mode |
| Wallet | Universe, UniSat, Xverse, OKX or Wizz |
| Maximum | **1,000 inscriptions per bulk job** |
| Reversible? | No, and a batch multiplies the consequence |
## How bulk text works
One line per inscription. Each non-empty line in the box becomes its own inscription, and
empty lines are skipped.
That is the whole rule. It means a list you already have, pasted in, is a batch.
## What it costs
The batch is one order with one payment, so the pricing is not simply the single-item cost
times the number of items.
How a batch is priced
Line
How it scales
Network fee
Per item, plus the fan-out transaction that distributes your payment
Service fee
Once for the whole batch in the default single-transaction mode
Inscription outputs
Per item, at your chosen output size
The service fee is the line worth understanding. In the default mode you pay the flat
1,500 satoshis once, no matter how many items. If you choose the **separate outputs** mode,
where each inscription is funded independently, the fee is charged per output instead.
Choose separate outputs only when you need the independence. It costs meaningfully more.
## Batch size changes the mechanics
Larger batches distribute your payment across temporary addresses first, and a fan-out
that gets reorganised would strand the whole job. So the job waits for confirmations
before it proceeds:
| Items | How it is funded | Confirmations before it proceeds |
| --- | --- | --- |
| Up to 22 | Fanned out directly from your payment | **None.** It starts as soon as the payment is visible |
| 23 to 500 | Temporary addresses | **1** |
| More than 500 | Temporary addresses | **2** |
That is why a 30-item batch feels slower to start than a 20-item one. It is waiting for a
block, on purpose.
Reveals are then broadcast in chunks of no more than 24, because Bitcoin's mempool refuses
a chain of more than 25 related unconfirmed transactions.
## Safety considerations
- **A mistake is repeated 1,000 times.** Proofread the list. A trailing space or a stray
blank entry is cheap to fix now and impossible to fix later.
- **Budget properly.** A 500-item batch at 546 satoshis per output is 273,000 satoshis in
outputs alone, before any fee.
- **Do not close the tab expecting to cancel.** Closing the tab does not stop a paid job.
## Steps
**Open `/inscribe` on the Text sub-tab and switch to bulk.**
The destination must be Ordinals. Connect your wallet.
**Paste your list, one item per line.**
Empty lines are skipped, so you do not need to tidy them. Check the item count the app
reports against what you expected. If they differ, your list has a problem.
**Choose the funding mode.**
The default single-transaction mode charges the service fee once. Separate outputs charges
it per output and costs considerably more. Take the default unless you know you need the
other.
**Set the fee rate and output size.**
Both apply to every item. At batch scale, the difference between output sizes and between
fee tiers is multiplied by your item count, so look at the total rather than the per-item
figure.
**Review the confirmation screen.**
Check the item count, the total, and the receiving address. The total is what your wallet
will be asked for.
**Confirm and pay.**
*Expected wallet screen:* one send, to one commit address, for the whole batch total. One
signature covers the entire job.
**Wait.**
Depending on size, the job may wait for one or two confirmations before it fans out, then
reveal in chunks. The status page reports progress. You can close the tab.
**Verify.**
**Portfolio** should list the full set once the indexer and your wallet agree. Compare the
count against what you submitted. Check the reveal transaction ids on an explorer for a
sample.
## Expected result
One inscription per non-empty line, all at your Ordinals address, from one payment and one
signature.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| The item count is not what you expected | Blank lines, duplicates, or an unintended line break in your source | Fix the list before paying |
| More than 1,000 items refused | Over the bulk cap | Split into several jobs |
| The job sits waiting after payment | A batch over 22 items is waiting for its confirmations | Wait for the block. This is by design |
| Some items completed, some did not | Reveals are broadcast in chunks and one chunk failed | Failed reveals are retried automatically with backoff. See recovery |
| Bulk mode is unavailable | You have a non-Ordinals destination selected | Switch the destination to Ordinals |
## Recovery route
A partly completed batch is not abandoned. Failed reveals retain their signed transaction
and key and are retried with backoff, so a retry can only ever resend the same transaction
rather than spend your money again. **Activity** carries a recovery queue that ranks
anything needing attention and offers one action per item.
See [recovery routes](/docs-inscribe/manage/recovery/).
## Related
- [Create a collection](/docs-inscribe/create/collections/), for a gallery of up to 500
- [The life of an order](/docs-inscribe/concepts/order-lifecycle/)
- [Orders you started](/docs-inscribe/manage/pending-orders/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/collections =====
# Create a collection
The three ways Inscribe groups inscriptions into a collection, gallery, parent and child, and delegate, with the limits on each and when to use which.
**Who this is for.** Anyone launching a set of inscriptions that belong together.
**Goal.** A collection whose membership is provable from the chain rather than from a
list someone maintains.
## The three approaches
Inscribe offers three sub-tabs in the **Inscribe** workspace, and they solve different
problems. Pick before you start; converting later means inscribing again.
| Approach | Sub-tab | What it gives you | Limit |
| --- | --- | --- | --- |
| **Gallery** | Gallery | A set defined by a JSON manifest you upload | **500 items**, manifest file up to 512 KB |
| **Parent and child** | Parent/Child | Each item provably inscribed under a parent you own, verified on chain | One parent per child |
| **Delegate** | Delegate | Many inscriptions pointing at one piece of content, so the bytes are stored once | Same as an ordinary inscription |
**Gallery** is the straightforward route for a numbered set.
**Parent and child** is the strongest claim: the child's provenance comes from spending
the parent, so nobody can add themselves to your collection. It costs more and needs a
second signature.
**Delegate** is the cheap route for many items sharing one artwork. It does not store the
content again, so a 1,000-item delegate set costs a fraction of 1,000 full inscriptions.
## Prerequisites
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet |
| Workspace | **Inscribe** at `/inscribe` |
| Wallet | Universe, UniSat, Xverse, OKX or Wizz |
| For parent and child | You must already own the parent inscription |
| Reversible? | No |
## Parent and child: what is different
This is the only common flow that asks for **two signatures**, and the reason is worth
understanding.
The reveal transaction has to spend the parent inscription you already own. Only your
wallet can authorise that, so the order pauses in a waiting-for-signature state and
presents a prepared transaction for you to sign. That prepared transaction is good for
**15 minutes**.
There is a check on top of it. Before accepting your parent, the server re-derives the
parent's output script and refuses it unless it matches what the chain indexer currently
reports for that inscription. **A parent that has moved since you loaded the page is
rejected rather than spent.** If you see that rejection, reload the workspace so the
current location of the parent is picked up.
Cost note: the parent input and its return output add about **101 virtual bytes** to the
reveal, which shows up in the network fee line.
## Steps: a gallery
**Prepare the manifest.**
A JSON file describing your items. It can be uploaded or pasted. The manifest itself is
capped at 512 KB and the set at 500 items.
**Open `/inscribe` and select the Gallery sub-tab.**
Connect your wallet. Upload or paste the manifest.
**Check the item count and the preview.**
Confirm the count matches what you intended before you look at any price.
**Set the fee rate and output size.**
Both apply per item, so at 500 items the totals move quickly. Look at the total, not the
per-item figure.
**Review the confirmation screen and pay.**
*Expected wallet screen:* one send to the commit address, for the total shown.
Note that the gallery flow quotes a price good for **24 hours** rather than the usual one
hour.
**Verify.**
**Portfolio** should list the set. Check the count, then verify a sample of reveal
transaction ids on an explorer.
## Steps: parent and child
**Open `/inscribe` and select the Parent/Child sub-tab.**
Connect the wallet holding the parent inscription.
**Choose the parent** from the inscriptions your wallet holds, and add the child content.
**Review the confirmation screen and pay the commit address.**
*Expected wallet screen (first signature):* one send to the commit address for the total.
**Sign the reveal when asked.**
Once the payment is seen, the order moves to a waiting-for-signature state and presents a
prepared transaction.
*Expected wallet screen (second signature):* a transaction spending your parent
inscription and returning it to you, alongside the commit input. Check the parent is
returned to an address you control.
**You have 15 minutes.** If it lapses, the order asks again rather than losing anything.
**Verify.**
Confirm on an explorer that the parent came back to your address and the child exists.
That the parent returned is the check that matters.
## Safety considerations
- **Decide the approach first.** Gallery, parent and delegate produce different provenance
and you cannot convert between them afterwards.
- **A parent must be spent to be used.** It is returned to you in the same transaction, but
it does move. Verify it came back.
- **Check the manifest before paying.** At 500 items, a systematic error is 500 errors.
- **Delegates depend on their target.** If the content you delegate to is what people
actually want, keep it inscribed and reachable.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| The parent is rejected | The parent has moved since the page loaded, and the server checks that | Reload the workspace and start again |
| The 15-minute signing window lapsed | The prepared reveal expired | The order asks again. Nothing is lost |
| The manifest is refused | Over 500 items, or over 512 KB, or not valid JSON | Split the set or fix the file |
| Item count is not what you expected | The manifest has duplicates or blanks | Fix it before paying |
| Still awaiting payment | The payment has not reached the commit address | Wait. Do not pay again |
## Recovery route
See [recovery routes](/docs-inscribe/manage/recovery/). A parent-and-child order waiting
for your signature is not lost, and neither is a paid gallery order.
## Related
- [Inscribe in a batch](/docs-inscribe/create/batch/)
- [Inscribe a file](/docs-inscribe/create/inscribe-a-file/)
- [Ordinals family](/docs-inscribe/protocols/ordinals-family/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/deploy-a-token =====
# Deploy a token
Create a new token on Bitcoin. Which protocols support a deploy, what each one does differently, the shared workflow, and what a deploy does not give you.
**Who this is for.** Anyone launching a new fungible token on Bitcoin.
**Goal.** A token deployed on the protocol you chose, with a ticker nobody else can now
claim on that protocol.
## Which protocols support a deploy
The registry records Inscribe implementing a `deploy` operation for these:
| Protocol | Workspace | Released | What is distinctive |
| --- | --- | --- | --- |
| **BRC-20** | `/brc20` | Ungated | JSON text inscriptions. Supports 4-byte, 5-byte self-issuance, and brc2.0 |
| **SRC-20** | `/src20` | Ungated | Data lives in 330-satoshi P2WSH outputs. Your wallet signs pre-built transactions |
| **TAP** | `/tap` | Ungated | Transfers take two steps. Also mints DMT tokens claiming block numbers |
| **OP-20** | `/op-return` | Ungated | OP_RETURN based. The same workspace registers OP Names |
| **BLOCK-20** | `/block20` | Released | Each mint embeds the latest block hash, filled in at mint time |
| **DUST-20** | `/dust20` | Released | The mint output's satoshi value encodes the amount |
| **ARC-20** | `/arc20` | A deployment must switch it on | Coloured-sat tokens with direct wallet signing, and no payment-address step |
| **OP_DROP** | `/op-drop` | A deployment must switch it on | Every operation is a compact JSON inscription, funded wallet-only |
Two protocols support creating a new asset but call it something else:
- **Runes** and **Mezcal** use `etch` rather than `deploy`. See
[etch a rune](/docs-inscribe/create/etch-a-rune/).
- **AVM** records a `deploy` in the registry, but the production contract classifies AVM
as **not released**. Do not plan around it.
## Prerequisites
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet |
| Wallet | Universe, UniSat, Xverse, OKX or Wizz |
| Funds | Spendable bitcoin at your payment address |
| A ticker | Available on your chosen protocol. Check in the workspace before you pay |
| Reversible? | **No.** A deploy is permanent and a ticker cannot be un-deployed |
## Safety considerations
- **Check the ticker is free first.** Every workspace browses the existing token list.
Deploying a ticker somebody already took wastes the fee and produces nothing useful.
- **Get the supply and limit right.** These are written into the deploy and cannot be
changed afterwards. A mint limit that is too low makes your token painful to mint; a
supply you regret is permanent.
- **A deploy is not a listing.** It creates the token on the protocol. It does not make it
tradeable anywhere, and Inscribe does not claim otherwise. Creation and trading are
independent surfaces.
- **The protocols are not interchangeable.** A BRC-20 ticker and a TAP ticker with the same
letters are different tokens on different indexes.
## The shared workflow
Most protocol workspaces have one shape: browse the token list, fill a Deploy, Mint or
Transfer form, then pay through one checkout.
**Open the workspace** for your protocol from the table above, and connect your wallet.
**Browse the existing tokens** and confirm your ticker is not taken. This is the step
people skip and regret.
**Fill in the Deploy form.**
Ticker, total supply, and per-mint limit are the usual fields. Read the workspace's own
field help: protocols differ in what they allow, particularly on ticker length and
decimals.
**Set the fee rate.**
**Normal** is selected and marked Recommended. A deploy is a small inscription, so the
flat 1,500-satoshi service fee is often the largest line in the total.
**Review the confirmation screen.**
It names the operation type, the token type, the fee rate, and the three cost lines
totalled. Check the ticker, the supply and the limit one more time here.
**Confirm and pay.**
*Expected wallet screen:* one send to the commit address for exactly the Total Cost shown.
One signature.
**ARC-20 is different:** it signs directly with your wallet and has no payment-address
step, so expect a transaction to sign rather than a payment to make.
**Wait, then verify.**
The order reaches **Wallet visible** when the indexer and your wallet agree. Then find the
token in the workspace's own token list, which is the check that matters: it means the
protocol's index recognised your deploy.
## Expected result
Your ticker deployed on your chosen protocol, visible in that workspace's token list, with
a reveal transaction id you can verify on any explorer.
## How to verify
1. The order page shows **Wallet visible** and gives you the transaction id.
2. **The protocol workspace's token list** shows your ticker. This is the meaningful check:
it proves the protocol index parsed your deploy, not just that a transaction confirmed.
3. Any Bitcoin explorer confirms the transaction independently of Inscribe.
A transaction that confirmed but does not appear in the token list means the protocol index
did not accept it, or has not read that block yet. Check the service status panel before
assuming the deploy failed.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| The ticker is rejected | Already deployed, or invalid for that protocol's rules | Choose another. Check length and character rules in the workspace |
| The transaction confirmed but the token is not listed | The protocol index has not read that block, or rejected the deploy | Check the service status panel. If the index is behind, wait. If it is current, the deploy was invalid |
| The workspace says its source is unavailable | The protocol index is down or catching up | Reads and drafts still work; writes stay paused. Nothing signed is at risk |
| The workspace is visible but refuses to act | Its release gate is off in this deployment | It is not a fault you can clear. See [status](/docs-inscribe/start/status/) |
| Still awaiting payment | The payment has not reached the commit address | Wait. Do not pay again |
## Recovery route
See [recovery routes](/docs-inscribe/manage/recovery/). A deploy order behaves like any
other: unpaid and underpaid orders are kept, keys are retained, and failed reveals are
retried.
There is no recovery from deploying the wrong parameters. That is why the confirmation
screen restates them.
## Related
- [Mint a token](/docs-inscribe/create/mint-a-token/)
- [Transfer an asset](/docs-inscribe/create/transfer-an-asset/)
- [Etch a rune](/docs-inscribe/create/etch-a-rune/)
- [Coverage matrix](/docs-inscribe/protocols/coverage/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/etch-a-rune =====
# Etch a rune
Create a new rune with Runes or Mezcal, mint an open rune, and split a rune balance across outputs. What etching commits to permanently and how the two protocols differ.
**Who this is for.** Anyone creating a new rune, or minting and moving an existing one.
**Goal.** A rune etched with the name, supply and mint terms you intended, or a minted
balance you hold.
Etching is the Runes word for what other protocols call a deploy. It is the same idea: you
bring a new asset into existence and fix its rules.
## Two protocols, one idea
| Property | Runes | Mezcal |
| --- | --- | --- |
| Workspace | `/runes` | `/mezcal` |
| Released | Ungated | Ungated |
| Operations | etch, mint, transfer | etch, mint, transfer |
| How it is written | Runestones, the Runes protocol encoding | JSON records in OP_RETURN rather than runestones |
| Service fee | The flat 1,500 satoshis | Mezcal quotes its own amount |
Mezcal is a separate protocol with its own index, not a variant of Runes. A name etched on
one is not the same asset as the same name on the other.
## What etching fixes permanently
An etch commits to the rune identity and its mint terms. None of it can be changed
afterwards:
- **The name.** Runes names are spaced uppercase letters, and shorter names are subject to
the protocol unlocking schedule.
- **Divisibility**, which is how many decimal places the rune has.
- **The mint terms**, if you allow minting at all: the amount per mint, the cap on how many
mints, and any block height or offset window during which minting is open.
- **The premine**, the amount you allocate to yourself at etch time.
Get these wrong and the only remedy is etching a different rune.
## Prerequisites
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet |
| Workspace | `/runes` or `/mezcal` |
| Wallet | Universe, UniSat, Xverse, OKX or Wizz |
| Funds | Spendable bitcoin at your payment address |
| Reversible? | No |
## Safety considerations
- **Check the name is available** in the workspace before you pay. A name already etched
cannot be taken.
- **Decide on divisibility deliberately.** Zero decimals makes a rune indivisible forever.
- **Mint terms are the whole economics.** Amount, cap and the open window together decide
how the supply is distributed. Model it before you sign.
- **A premine you did not intend is permanent.** Check the field even if you left it at
zero.
## Steps: etch a rune
**Open `/runes`** (or `/mezcal`) and connect your wallet.
**Browse existing runes** and confirm your name is free.
**Fill the Etch form.**
Name, divisibility, premine, and the mint terms if you want the rune to be mintable. Read
each field back before continuing; this is the set of values you cannot change.
**Set the fee rate.**
An etch is a small transaction. **Normal** is selected and marked Recommended.
Runes rounds fee rates to whole satoshis in some conditions, which is one reason Normal and
Fast can show the same number. That is not an error.
**Review the confirmation screen.**
Check the name, divisibility, premine and mint terms one final time, then the cost lines
and the total. Mezcal shows its own service fee amount here rather than the flat 1,500.
**Confirm and pay.**
*Expected wallet screen:* one send to the commit address for the Total Cost shown. One
signature.
**Verify in the rune list.**
When the order reaches **Wallet visible**, find the rune in the workspace list. That proves
the Runes index parsed your etch, which a confirmed transaction alone does not.
## Minting an open rune
Open mints are first come, first served against the cap. The workspace lists runes that are
currently mintable.
The mint flow is the same shape as the etch: choose the rune, set the fee rate, review the
total, pay once. On a contested mint the fee rate decides whether you get in before the cap
fills. See [mint a token](/docs-inscribe/create/mint-a-token/) for why a confirmed mint can
still claim nothing.
## Splitting a rune balance
The Runes workspace can split a rune balance across outputs. This is genuinely useful and
worth doing deliberately:
- A single output holding your whole balance has to be spent whole every time you move any
of it.
- Several outputs let you send part of a balance without disturbing the rest.
Splitting shows the asset report for each output before you sign. See
[advanced transaction tools](/docs-inscribe/manage/advanced-transactions/).
## Expected result
Your rune etched with the exact terms you set, visible in the workspace rune list, with a
transaction id verifiable on any explorer.
## How to verify
1. The order reaches **Wallet visible**.
2. **The rune list in the workspace** shows your rune with the terms you set. Check the
divisibility and mint terms here, not just the name.
3. Any Bitcoin explorer confirms the transaction independently.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| The name is rejected | Already etched, or not valid under the Runes name rules | Choose another |
| Confirmed, but the rune is not listed | The index has not read that block, or the etch was invalid | Check the service status panel first |
| Normal and Fast quote the same rate | Blocks have room, or the protocol rounds to whole satoshis | Nothing to fix. Paying more would buy nothing |
| The mint says the cap is reached | The supply was exhausted before your transaction | Nothing to do. The fee is spent |
| Still awaiting payment | The payment has not reached the commit address | Wait. Do not pay again |
## Recovery route
See [recovery routes](/docs-inscribe/manage/recovery/). There is no recovery from etching
the wrong terms.
## Related
- [Mint a token](/docs-inscribe/create/mint-a-token/)
- [Deploy a token](/docs-inscribe/create/deploy-a-token/)
- [Runes family](/docs-inscribe/protocols/runes-family/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/first-inscription =====
# Your first inscription
From an empty wallet to a confirmed inscription, with every check in between.
## Before you start
You need a Bitcoin wallet with sats available on mainnet, and about ten minutes. The app uses a two-address model: a payment address that funds transactions and an ordinals address that holds inscriptions. Both are yours; both live in your wallet.
A practice run in the [Practice Studio](/docs-inscribe/practice/) costs nothing and shows every screen before you touch real funds.
## The short version
1. **Connect your wallet** in the app. Approve the popup in the extension.
2. **Open the Inscribe workspace** and pick the Text sub-tab.
3. **Type your content.** The quote updates live: network fee, service fee, and the 546 sats of postage that stays yours.
4. **Review the quote.** The final in-app quote is authoritative; the numbers in guides and planners are previews.
5. **Pay the commit address** exactly. The app watches for your payment and runs the reveal.
6. **Wait for confirmations.** The order page shows the lifecycle: created, paid, committed, revealed, complete.
## What the wallet review shows
Before you sign anything, your wallet lists the destination, the amount, and the fee. Check all three against the order page. The app never asks a wallet to sign without showing the same numbers first.
## If it stops moving
Payments can take longer than the quote timer, reveals can fail and retry, and tabs can be closed by accident. The [Recovery Navigator](/recovery/navigator/) diagnoses your exact situation and names the next action. The one thing it will never suggest is sending a second full payment.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-02
===== inscribe-docs/create/inscribe-a-file =====
# Inscribe a file
Put an image, audio, video, HTML or JSON file on Bitcoin, with the accepted types, the size limits per destination, what it costs and how to verify the result.
**Who this is for.** Anyone with a file they want written onto Bitcoin.
**Goal.** A file inscribed at an address you control, verifiable on any explorer.
## Prerequisites
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet |
| Workspace | **Inscribe**, at `/inscribe`, the **Files** sub-tab |
| Wallet | Universe, UniSat, Xverse, OKX or Wizz |
| Funds | Spendable bitcoin at your payment address. A large file can cost significantly more than a small one |
| Reversible? | No |
If this is your first time, do
[your first inscription](/docs-inscribe/start/first-inscription/) instead. It covers the
same ground with more explanation.
## What you can upload
Inscribe accepts these types, and rejects a file whose extension does not match its actual
content:
| Category | Types |
| --- | --- |
| Images | JPG, JPEG, PNG, WEBP, GIF, SVG |
| Text and data | TXT, HTML, JSON |
| Audio and video | MP3, MP4 |
**The overall limit is 4 MB.** A larger file is refused with `File too large (max 4 MB).`
The same guard runs whether you drag a file in or pick one, so there is no path around it.
## Size limits by destination
The Files tab can send your file to more than one protocol, and each has its own payload
ceiling. These are protocol limits, not Inscribe preferences.
| Destination | Payload limit | Notes |
| --- | --- | --- |
| **Ordinals** | No protocol cap, subject to the 4 MB upload limit | The default, and the one to use unless you have a reason not to |
| **Stamps** | 65,529 bytes | One image only: PNG, JPG, WEBP or GIF. Data goes into the UTXO set, so it cannot be pruned |
| **OP_RETURN** | 34,000 bytes | Well above the 79-byte standard relay reference. A file path is capped at 25,000 bytes |
| **Drops** | 256 bytes | Small artifacts with stable IDs. Released, but a deployment must switch it on |
| **Atomicals** | 2,000,000 bytes, and lower where the backend reports a smaller ceiling for your case | Released, but a deployment must switch it on |
Choosing a destination changes the cost as well as the limit. Stamps encode data directly
into outputs, which is why they are more expensive per byte and why they cannot be pruned.
## Safety considerations
- **The preview is the contract.** What the preview shows is what is written. There is no
edit afterwards.
- **Fund from an address holding only bitcoin** where possible. See
[asset safety](/docs-inscribe/concepts/asset-safety/).
- **Active content is sandboxed on display, not on chain.** HTML, scripts and SVG with
scripts render inside an isolated sandbox when Inscribe shows them. That protects the
viewer; it does not change what you wrote.
- **Cost scales with size.** The network fee is your fee rate times the transaction size.
Doubling the file roughly doubles that line.
## Steps
**Open `/inscribe` and select the Files sub-tab.**
Connect your wallet if you have not. Nothing is spent by connecting.
**Add your file.**
Drag it in or use the picker. If it is refused, the message says why: an unsupported type,
a mismatch between the extension and the real content, or over 4 MB.
**Choose the destination.**
Ordinals is the default. Pick another only if you specifically want its properties, and
check your file fits the limit in the table above.
**Check the preview.**
Confirm this is the file you meant, at the quality you meant. Read it properly; this is
the last cheap moment.
**Set the fee rate and output size.**
**Normal** is selected and marked Recommended. Leave the inscription output at 546 sats
unless you have a reason to use 330.
Watch the network fee move as you change the rate. On a large file the difference between
tiers is real money.
**Review the confirmation screen.**
It shows the operation type, the fee rate, **Network Gas Fee**, **Service Fee** of 1,500
sats, **Mint UTXO Value** and **Total Cost**, and it names the receiving address.
If the paying address holds assets, a warning lists them here. It does not block you.
**Confirm and pay.**
*Expected wallet screen:* a single send to the commit address, for exactly the Total Cost
shown. Compare the two numbers. Reject if they differ.
This is your only signature for this order.
**Wait, then verify.**
The status page moves from **Awaiting payment** to **Creation in progress** to **Wallet
visible**. You can close the tab.
Verify by finding the inscription in **Portfolio**, and independently by looking up the
reveal transaction id on any Bitcoin explorer.
## Expected result
Your file on a 546-satoshi output at your Ordinals address, with a reveal transaction id.
The exact original bytes are what is stored; any thumbnail Inscribe shows you later is a
derived preview and does not alter the original.
## How to verify
1. **Portfolio** lists it under your connected wallet.
2. **Explore** with your Ordinals address pasted in shows the same thing without a wallet.
3. Any Bitcoin explorer, using the reveal transaction id, shows the output exists at your
address. This check does not depend on Inscribe.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| `File too large (max 4 MB).` | Over the upload limit | Compress or resize the file |
| The file is rejected on type | The extension does not match the actual content, or the type is not accepted | Re-export in a supported format |
| The payload exceeds the destination cap | Your file is fine for Ordinals but too big for the destination you picked | Use Ordinals, or reduce the file |
| Still **Awaiting payment** after paying | The payment has not reached the commit address yet | Wait. Do not pay again. See recovery |
| The payment will not confirm | Fee rate too low for current conditions | **Fix My Payment** or **Bump Stuck TX** |
| The workspace says a source is unavailable | An index it reads is down or catching up | Reads and drafts still work; writes stay paused. Nothing signed is at risk |
## Recovery route
[Recovery routes](/docs-inscribe/manage/recovery/) covers unpaid orders, underpayment,
stuck payments, closed tabs and failed reveals. Nothing here is lost by closing a tab, and
paying twice is never the fix.
## Related
- [Inscribe text](/docs-inscribe/create/inscribe-text/)
- [Inscribe in a batch](/docs-inscribe/create/batch/)
- [Create a collection](/docs-inscribe/create/collections/)
- [What a transaction costs](/docs-inscribe/concepts/what-it-costs/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/inscribe-text =====
# Inscribe text
Write text onto Bitcoin as an Ordinals inscription, an OP_RETURN record or a Drop, with the size limits, the cost and how to find it again afterwards.
**Who this is for.** Anyone wanting a line of text, a message, or a small JSON document
permanently on Bitcoin.
**Goal.** Text inscribed at an address you control, findable by its content afterwards.
## Prerequisites
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet |
| Workspace | **Inscribe**, at `/inscribe`, the **Text** sub-tab. This is the tab the workspace opens on |
| Wallet | Universe, UniSat, Xverse, OKX or Wizz |
| Funds | Spendable bitcoin at your payment address. Text is small, so this is usually the cheapest thing you can inscribe |
| Reversible? | No |
## Where the text can go
| Destination | Limit | What it is for |
| --- | --- | --- |
| **Ordinals** | No protocol cap | The default. A normal inscription you own, transfer and see in your portfolio |
| **OP_RETURN** | 34,000 bytes | A free-form record in an OP_RETURN output, with an optional file |
| **Drops** | 256 bytes | A confirmed data artifact with a stable ID and on-chain proof. A deployment must switch it on |
| **ChainBloom** | Its own flow | A contribution to a shared world. A deployment must switch it on |
For anything you want to hold, transfer, or see in your wallet, use Ordinals.
## Safety considerations
- **Text is public and permanent.** Anyone can read it, forever. Do not inscribe anything
you would not publish under your own name.
- **Check spelling before you sign.** There is no edit.
- **Fund from an address holding only bitcoin** where you can. See
[asset safety](/docs-inscribe/concepts/asset-safety/).
## Steps
**Open `/inscribe`.**
It opens on the **Text** sub-tab. Connect your wallet.
**Type or paste your text.**
One line or many. The character count and the resulting size drive the network fee.
**Pick the destination.**
Ordinals unless you specifically want one of the others.
**Read the preview.**
Check the exact characters, including trailing spaces and line breaks, and check any JSON
is valid if you meant it to be.
**Set the fee rate.**
**Normal** is selected and marked Recommended. Text is small, so the network fee is
usually a small part of the total. The flat 1,500-satoshi service fee will often be the
largest line.
**Review the confirmation screen and pay.**
Compare the amount in your wallet against the **Total Cost** on the confirmation screen.
*Expected wallet screen:* one send, to the commit address, for the total. One signature.
**Verify.**
When the order reaches **Wallet visible**, find it in **Portfolio**. Text inscriptions can
also be found by their content in **Search Txt**, which searches text inscriptions by what
they say.
## Expected result
A text inscription on a 546-satoshi output at your Ordinals address, with a reveal
transaction id you can look up on any explorer.
## How to verify
1. **Portfolio** shows it under your wallet.
2. **Search Txt** finds it by its content.
3. Any Bitcoin explorer, using the reveal transaction id, confirms the output at your
address independently of Inscribe.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| The text exceeds the destination limit | OP_RETURN and Drops have hard caps | Shorten it, or use Ordinals |
| Still **Awaiting payment** | The payment has not reached the commit address | Wait. Do not pay again |
| Payment below the quote | You sent less than the total | Top the same address up to the quoted amount |
| The payment will not confirm | Fee rate too low for current conditions | **Fix My Payment** or **Bump Stuck TX** |
| The hour ran out | The price quote expired | Start a fresh order. If you already paid, see recovery |
## Recovery route
See [recovery routes](/docs-inscribe/manage/recovery/). An unpaid or partly paid order is
not lost, and its signing key is not discarded.
## Related
- [Inscribe a file](/docs-inscribe/create/inscribe-a-file/)
- [Inscribe in a batch](/docs-inscribe/create/batch/), for many lines at once
- [What a transaction costs](/docs-inscribe/concepts/what-it-costs/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/mint-a-token =====
# Mint a token
Claim an amount of an existing token or rune, which protocols support minting, the shared workflow, and why a confirmed mint can still be refused by a protocol index.
**Who this is for.** Anyone claiming an amount of a token or rune somebody has already
deployed.
**Goal.** A minted balance held at an address you control.
## Minting is a race
Most open mints are first come, first served against a fixed supply. Two consequences
follow, and both are about fees rather than about Inscribe:
- **A mint that confirms late may claim nothing.** If the supply is exhausted before your
transaction is mined, the protocol index will not credit you, even though your
transaction confirmed and your fee was spent.
- **The fee rate is the whole strategy.** On a contested mint, **Fast** exists for this
reason. On an uncontested one, paying for Fast buys nothing.
Inscribe does not predict whether a mint will succeed and does not pretend to. It shows
what the protocol index currently reports about supply and progress, and prices the
transaction you asked for.
## Which protocols support a mint
| Protocol | Workspace | Released |
| --- | --- | --- |
| BRC-20 | `/brc20` | Ungated |
| SRC-20 | `/src20` | Ungated |
| SRC-101 | `/src101` | Ungated |
| TAP | `/tap` | Ungated |
| OP-20 | `/op-return` | Ungated |
| Runes | `/runes` | Ungated |
| Mezcal | `/mezcal` | Ungated |
| Alkanes | `/alkanes` | Released |
| BLOCK-20 | `/block20` | Released |
| DUST-20 | `/dust20` | Released |
| ARC-20 | `/arc20` | A deployment must switch it on |
| Atomicals, NFTs, Realms and Subrealms | `/atomicals`, `/atomicals-nfts`, `/atomicals-realms` | A deployment must switch it on |
| OP_DROP | `/op-drop` | A deployment must switch it on |
| TAP on Doge | `/tap-doge` | A deployment must switch it on |
| CAT-20 | `/cat20` | **Not released.** Transaction features stay fail-closed |
| DRC-20 | none | **No creation workspace in Inscribe** |
## Protocol quirks worth knowing
Several protocols do something specific at mint time. These are not Inscribe behaviours;
they are how the protocol works.
- **BLOCK-20** embeds the latest block hash in every mint, filled in at mint time.
- **DUST-20** encodes the amount in the mint output's satoshi value, so the output value
carries meaning rather than being padding.
- **Alkanes** are minted by ID, and the workspace ranks tokens by live mempool minting so
you can see what is being contested right now.
- **TAP** also mints DMT tokens that claim block numbers.
- **ARC-20** signs directly with your wallet and has no payment-address step.
- **Subrealms** are claimed inside the Realms workspace, which is a two-part claim and pay
sequence rather than a single mint.
- **SRC-101** registers permanent Bitcoin domain names ending `.sats` or `.btc`, funded by
one signature.
## Prerequisites
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet, or Dogecoin mainnet for TAP on Doge |
| Wallet | Universe, UniSat, Xverse, OKX or Wizz |
| Funds | Spendable bitcoin at your payment address |
| The token | Must already be deployed, and open for minting |
| Reversible? | No. The fee is spent whether or not you receive a balance |
## Safety considerations
- **Check the remaining supply before you pay.** The workspace shows what the index
reports.
- **Check the mint limit.** Most tokens cap how much one mint can claim. Asking for more
than the limit usually produces an invalid mint that the index ignores, and your fee is
still spent.
- **A confirmed transaction is not a credited balance.** See the verification section.
- **Fund from an address holding only bitcoin** where you can. See
[asset safety](/docs-inscribe/concepts/asset-safety/).
## Steps
**Open the workspace** for your protocol and connect your wallet.
**Find the token** in the workspace's token list, and check the supply remaining and the
per-mint limit.
**Fill the Mint form.**
The amount, within the token's per-mint limit. Some protocols fill parts of this in for
you at mint time; BLOCK-20's block hash is the clearest example.
**Set the fee rate.**
On a contested mint this is the decision that matters. On an uncontested one, **Normal**
is selected and marked Recommended, and is enough.
**Review the confirmation screen.**
Operation type, token, amount, fee rate, then **Network Gas Fee**, **Service Fee**, **Mint
UTXO Value** where the protocol carries an output, and **Total Cost**.
**Confirm and pay.**
*Expected wallet screen:* one send to the commit address for the Total Cost shown. One
signature.
**ARC-20 differs:** it signs a transaction directly, with no payment-address step.
**Verify against the protocol index, not just the chain.**
See below. This is the step that actually tells you whether you got the balance.
## Expected result
A minted balance credited to your address by the protocol's index, visible in
**Portfolio** and in the workspace's own balance view.
## How to verify
1. The order reaches **Wallet visible**, meaning the indexer and your wallet agree.
2. **The protocol workspace's balance view** shows the amount. This is the meaningful
check.
3. Any Bitcoin explorer confirms the transaction, independently of Inscribe.
**If step 3 passes and step 2 does not**, the transaction is on the chain but the protocol
did not credit it. The usual causes are that the supply ran out before your transaction was
mined, that the amount exceeded the per-mint limit, or that the index has not read that
block yet. Check the service status panel to tell the last case from the first two.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| Confirmed, but no balance | The mint was late, invalid, or the index is behind | Check the service status panel. If the index is current, the mint did not qualify. The fee is spent |
| The mint form rejects the amount | Above the token's per-mint limit | Reduce the amount to the limit |
| The token is not listed | The index is behind, or the ticker does not exist on this protocol | Check the status panel, and check you are on the right protocol |
| The workspace is visible but refuses to act | Its release gate is off in this deployment | Not a fault you can clear. See [status](/docs-inscribe/start/status/) |
| CAT-20 features do not work | CAT-20 is not released and stays fail-closed | Do not plan around it |
| The payment will not confirm | Fee rate too low, and on a mint this may cost you the claim | **Bump Stuck TX** immediately |
## Recovery route
An unpaid, underpaid or stuck mint order recovers like any other. See
[recovery routes](/docs-inscribe/manage/recovery/).
There is no recovery from a mint that lost the race. The transaction did what you asked;
the supply was gone.
## Related
- [Deploy a token](/docs-inscribe/create/deploy-a-token/)
- [Transfer an asset](/docs-inscribe/create/transfer-an-asset/)
- [Fee tiers](/docs-inscribe/reference/fee-tiers/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/transfer-an-asset =====
# Transfer an asset
Move an inscription, rune or token balance you already hold, which address signs, why TAP transfers take two steps, and how fees are funded without touching your assets.
**Who this is for.** Anyone moving something they already own to another address.
**Goal.** The asset at its destination, and nothing else spent by accident.
## Where to do it
| What you are moving | Where |
| --- | --- |
| An inscription, or an output you hold | **Send Inscriptions** workspace |
| A token balance | The Transfer form in that protocol workspace |
| Part of a rune balance | The Runes workspace, which can split a balance across outputs |
## Which address signs
The address that actually holds the thing. For inscriptions and token balances that is your
**Ordinals address**, not your payment address. Inscribe works this out and signs from the
right one rather than assuming.
The network fee is funded separately, from plain bitcoin outputs at your payment address.
That separation is the point: sending an inscription pulls in only outputs proved to be
plain bitcoin to cover its fee, so paying to move one asset cannot cost you another.
## Prerequisites
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet |
| Wallet | Universe, UniSat, Xverse, OKX or Wizz, connected to the address holding the asset |
| Funds | Plain bitcoin at your payment address for the network fee |
| Destination | An address that can hold the asset type. For inscriptions, a Taproot address |
| Reversible? | No |
## Safety considerations
- **Check the destination address character by character.** A transfer to a wrong address
is final. Paste it, do not type it.
- **Send inscriptions to an Ordinals-aware address.** An exchange deposit address is
usually not one, and an inscription sent to an exchange is usually gone.
- **Do not send an inscription to a wallet that does not understand inscriptions.** That
wallet may later spend the output as ordinary bitcoin.
- **Two-step protocols are not finished until step two.** TAP is the common case.
## Steps
**Open the right workspace.**
**Send Inscriptions** for an inscription or an output. The protocol own workspace for a
token balance.
**Connect the wallet holding the asset.**
If the asset is at your Ordinals address, that is the account that needs to be active.
**Choose what to send, and where.**
Paste the destination. Check it. The confirmation screen names it again, and that is
deliberate.
**Review the asset report.**
Where a surface lets you pick outputs, it shows what each one holds before you sign. Read
it. An output carrying something you did not intend to move is the one thing worth catching
here.
**Set the fee rate and review the total.**
The fee is funded from plain bitcoin only. If Inscribe holds outputs back and the remainder
cannot cover the fee, it tells you how many outputs were withheld, how many satoshis they
hold, and why, rather than telling you to add bitcoin you already have.
**Confirm and sign.**
*Expected wallet screen:* a transaction spending the output holding your asset, with the
asset going to your destination and change returning to you. Check the destination in the
wallet screen, not only in Inscribe.
**For TAP, complete the second step.**
TAP transfers are a two-part operation by protocol design: an inscription that authorises
the transfer, then the transfer itself. A TAP transfer that has completed only the first
step has not moved anything.
**Verify.**
Confirm on an explorer that the output arrived at the destination, and check the protocol
workspace balance view for token transfers.
## Other protocols with their own shape
- **SRC-20** data lives in 330-satoshi P2WSH outputs, and your wallet signs pre-built
transactions rather than a simple send.
- **ARC-20** signs directly with your wallet, with no payment-address step.
- **OP_DROP** transfers are funded wallet-only, and both funding and settlement go through
the asset screening described above.
- **Bitmap and UNAT** are recorded in the registry as transferable, but Inscribe has **no
creation or transfer workspace** for them. They appear in your portfolio and in the asset
inventory for an output, and that is all. Move them with a tool that supports them.
## Expected result
The asset at the destination address, your fee paid from plain bitcoin, and nothing else
moved.
## How to verify
1. Any Bitcoin explorer shows the output at the destination address.
2. **Portfolio** no longer lists it under your address, and the protocol balance view
reflects the change for a token transfer.
3. For a transfer to your own second address, **Explore** on the destination shows it
arriving without needing a wallet connection.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| Not enough bitcoin for the fee, but your balance looks fine | Asset-bearing outputs were withheld from fee funding | Send plain bitcoin to the payment address, or lower the fee rate |
| The destination is rejected | The address type cannot hold this asset | Use a Taproot address for inscriptions |
| A warning that the paying address holds assets | Your wallet, not Inscribe, chooses the outputs for a wallet send | Pay from an address holding only bitcoin, or pick inputs yourself in the wallet |
| A TAP balance did not move | Only the first of the two steps completed | Complete the second step in the TAP workspace |
| The transfer confirmed but the balance is unchanged | The protocol index has not read that block, or rejected the transfer | Check the service status panel |
| No transfer option for Bitmap or UNAT | Inscribe has no workspace for these | Use another tool |
## Recovery route
There is **no recovery from a transfer to the wrong address**. The transaction did what you
told it to.
Everything else has a route: see [recovery routes](/docs-inscribe/manage/recovery/) for
stuck transactions, and
[advanced transaction tools](/docs-inscribe/manage/advanced-transactions/) for repairing an
output.
## Related
- [Asset safety](/docs-inscribe/concepts/asset-safety/)
- [Wallets and the two addresses](/docs-inscribe/concepts/wallets-and-addresses/)
- [Advanced transaction tools](/docs-inscribe/manage/advanced-transactions/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/what-it-costs =====
# What a transaction costs
Network fee, service fee, and the output value that stays yours, piece by piece.
# What a transaction costs
Every Inscribe action that writes to Bitcoin shows its full cost before your
wallet opens. Nothing is signed or paid until you approve the amounts on the
confirmation screen.
This page explains the numbers you see there.
## The three parts of a total
**Network fee.** What miners are paid to include your transaction. It is the
fee rate you pick, in satoshis per virtual byte, times the size of the
transaction. A larger inscription costs more because it is bigger, not because
Inscribe charges more for it.
**Service fee.** A flat 1,500 sats for most actions. Some flows differ and say
so on the confirmation screen: an `op_names` batch pays the flat fee once per
name, and Mezcal quotes its own amount. The confirmation screen always shows
the amount that applies to the action in front of you.
**The inscription output.** Your inscription lives on a satoshi, and that
satoshi has to sit in an output of its own. The default is 546 sats, and 330
sats is offered as the smaller standard size. This is not a fee. It stays with
your inscription, and you still own it.
The confirmation screen lists these separately and then adds them up. The total
is the amount your wallet will be asked to spend.
## Choosing a fee rate
Inscribe offers three tiers, quoted from Universe's own Bitcoin infrastructure
and refreshed every 30 seconds.
| Tier | What it targets |
| --- | --- |
| Normal | A place in the blocks mined over roughly the next half hour |
| Fast | A place in the next block, roughly ten minutes |
| Custom | Any whole rate you type |
Normal is selected when you arrive, and it is the tier marked Recommended. The
default is never the more expensive option.
The wait shown on each tier is the wait its rate has earned, not a label fixed
in advance. Bitcoin block times are random, so these are averages rather than
promises.
### When Normal and Fast cost the same
Blocks are not always full. When there is room in the next block, the rate that
gets you into it is the same rate that would have got you in within half an
hour, and both tiers quote the same number.
Inscribe says so, on both tiers, rather than printing a shorter wait next to
the higher-sounding option:
> Blocks have room right now, so Normal costs the same as Fast and confirms
> just as soon.
Two prices that are the same number are the same purchase. Paying more for one
of them would buy nothing, so the screen does not offer it as if it would.
Some protocols round fee rates up to whole satoshis or apply a higher relay
floor. That can also land both tiers on one rate, and the same note appears for
the same reason.
### Rates below 1 sat/vB
The **Sub 1** control accepts rates under one satoshi per virtual byte. These
are real rates that real miners sometimes accept, and they can take a long time
or never confirm. The control is marked Beta, shows the exact rate you have
chosen, and never becomes the default.
## Why the cost is shown first
An inscription is not reversible. Once a transaction is signed and broadcast,
the fee is spent whether or not the result is what you wanted. Showing the
amounts before the wallet opens is the only point at which the choice is still
yours.
The same rule shapes the rest of the flow:
- The content preview shows exactly what will be inscribed, before payment.
- The confirmation screen names the receiving address and the operation type.
- No output holding an inscription, Rune, or token balance is ever picked to
pay a fee. Read [asset safety](/safety/asset-safety/).
## Reading a cost with a screen reader
Each fee tier is a button whose accessible name carries the tier, the rate in
satoshis per virtual byte, and the wait, so the price is available without
reading the visual card. The recommended tier says that it is recommended.
## When fee data is unavailable
Fee rates come from Universe-operated Bitcoin infrastructure. If that source
stops answering, the fee control says **Cached fees** instead of counting down
to the next refresh, so you can see that the number in front of you is not
fresh. A stale quote is never presented as a live one. Read
[protocol data status and recovery](/reference/protocol-data-status/).
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/create/workspaces =====
# Workspace map
Every Inscribe workspace, what it does, and which ones have in-app guides.
# Where things live
Inscribe has one workspace per job. This page lists all of them, in the order
the sidebar shows them, so you can find the right one without opening each.
If you already know what you want to do, four routes are faster than the
sidebar:
- The search box in the header.
- The **Mint** menu beside it, which lists every workspace that creates
something, with a line saying what each one does.
- The command palette, `Ctrl` + `K` on Windows and Linux, `Cmd` + `K` on macOS.
- The paste box on Home. Paste an address, a txid, an inscription ID or a
ticker and Inscribe opens the workspace that handles it.
All four read the same list, so a workspace appears in every one of them or in
none, described the same way.
Most workspaces also have a guide under **Docs & Guides** in the app, with the
exact field names, the diagrams, and worked examples. This page is the map;
those guides are the detail. Seven workspaces have no guide yet: ChainBloom,
Witness Circles, Tandem, Patina, Atomicals NFTs, Atomicals Realms, and the
Stamps protocol tab, though Stamps inscription is covered under Create.
## Workspace
| Workspace | What it is for |
| --- | --- |
| Home | The task picker, then live fees and unfinished work, then the paste box. The full catalogue, the protocol map and the live mempool view sit behind **Browse all workflows** |
| Inscribe | Eight sub-tabs for putting content on Bitcoin: Text, Files, Names, Parent/Child, Delegate, Gallery, Stamps and Data Lab |
| Ord Studio | Full inscription-envelope control: live HTML sandbox, templates, and the ord spec fields (pointer, parent, metadata, gzip, metaprotocol) |
| AVM Studio | Build, test, deploy, call and verify Atomicals AVM contracts, with the academy alongside the editor |
| ChainBloom | Grow a shared world one contribution at a time |
| Witness Circles | Taproot outputs a group authorises together |
| Send Inscriptions | Move inscriptions or UTXOs you already hold |
| Search Txt | Find text inscriptions by their content |
## Account
| Workspace | What it is for |
| --- | --- |
| Portfolio | Everything your connected wallet holds, grouped by protocol |
| Explore | The same view for any address you paste, no wallet needed |
| Watchlist | Track wallets without connecting them |
| Activity | Orders this browser has started, and the recovery tools for them |
## Protocols
Most protocol workspaces share one shape: browse a token list, fill a Deploy,
Mint or Transfer form, then pay through one checkout. Read
[How the protocol tabs work](https://inscribe.bitcoinuniverse.io/docs) in the
app before your first one.
**Ordinals**
| Workspace | What it is for |
| --- | --- |
| brc-20 | Deploy, mint and transfer BRC-20 tokens: JSON text inscriptions. Supports 4-byte, 5-byte self-issuance, and brc2.0 |
| tap | Deploy, mint and transfer TAP tokens, or mint DMT tokens that claim block numbers. TAP transfers take two steps |
| block-20 | Deploy, mint and transfer BLOCK-20 tokens. Each mint embeds the latest block hash, filled in at mint time |
**Atomicals**
| Workspace | What it is for |
| --- | --- |
| arc-20 | Mint, deploy and transfer coloured-sat tokens with direct wallet signing. No payment-address step |
| atomicals nfts | Atomicals non-fungible assets |
| atomicals realms | Names and sub-realms in the Atomicals namespace |
**Stamps**
| Workspace | What it is for |
| --- | --- |
| stamps | Bitcoin Stamps: images encoded straight into the UTXO set, so the data cannot be pruned |
| src-20 | Deploy, mint and transfer SRC-20. Data lives in 330-sat P2WSH outputs; your wallet signs pre-built PSBTs |
| src-101 | Register permanent Bitcoin domain names ending in `.sats` or `.btc`, funded by one signature |
**OP_RETURN family**
| Workspace | What it is for |
| --- | --- |
| op_return inscriptions | Free-form OP_RETURN inscriptions, with an optional file |
| op20 | OP-20 token deploy, mint and transfer, plus OP_Names registration and transfer |
**Drops and OP_DROP**
| Workspace | What it is for |
| --- | --- |
| drops | Browse verified Drops: confirmed data artifacts with stable IDs and on-chain proof. Read-only; creation runs through Inscribe |
| drop pacts | Design and launch Drop Pact agreements, with a resumable tutorial |
| op-drop | Deploy, mint and transfer op-drop tokens. Every operation is a compact JSON inscription, funded wallet-only |
**Collaborative and time**
| Workspace | What it is for |
| --- | --- |
| Tandem | Build and change one object together, with a signed record of each change |
| Patina | How long a value-carrying output has stayed where it is |
**Other protocols**
| Workspace | What it is for |
| --- | --- |
| runes | Mint open Runes, etch your own, or split a rune balance across outputs |
| alkanes | Browse Alkane tokens ranked by live mempool minting, and mint them by ID |
| cat-20 | Explore CAT-20 on Fractal, check balances, and prepare covenant mints. You pick the network yourself |
| tap on doge | Mint TAP tokens indexed on Dogecoin, including Doge DMT blocks. Mint only |
| dust-20 | Deploy and mint DUST-20, where the mint output's sat value encodes the amount |
| mezcal | Mint, etch and transfer Mezcal, which writes JSON OP_RETURN records instead of runestones |
## Market intel
| Workspace | What it is for |
| --- | --- |
| Mempool | What is waiting to confirm, grouped by protocol family and sized by transaction weight |
| Ecosystem | The apps and indexes Universe runs, and whether each answers |
| Ordinal Duels | Head-to-head comparisons between collections |
| Meme Map | Where attention is going across meme assets |
| Pending TX Analyzer | Read one pending transaction in detail |
| Bitcoin Tools | 33 focused tools: decoders, estimators, inspectors, planners |
| Analytics | Longer-range activity across protocols |
## Advanced
Use these when a normal flow will not do what you need. Each one shows the
asset report for an output before you sign it.
| Workspace | What it is for |
| --- | --- |
| Bump Stuck TX | Compare RBF and CPFP for a transaction that is not confirming |
| Advanced TX Builder | Choose inputs and outputs yourself |
| UTXO Split | Split one output into several |
| Asset Recovery | Reclaim sats locked in inscription padding |
## Help
| Workspace | What it is for |
| --- | --- |
| Docs & Guides | 63 in-app guides across getting started, create, protocols, workflows, wallet, intel, safety and troubleshooting |
## What the availability labels mean
A workspace stays visible even when the index behind it is down or catching up.
It says so instead of disappearing, because a missing workspace looks like a
product that never had the feature.
- **Available**: the source answered and is at the chain tip.
- **Degraded**: the source answered but is behind, or one of several sources
did not answer. Reads still work, and the page names what is missing.
- **Unsupported**: the source is not running for this network. Nothing is
guessed or filled in from elsewhere.
[Protocol data status and recovery](/reference/protocol-data-status/) explains where
these states come from and what each one blocks.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/manage/advanced-transactions =====
# Advanced transaction tools
Four tools for when a normal flow will not do what you need, what each is for, and which one deliberately lets you spend an asset.
Use these when a normal flow will not do what you need. Each one shows the asset report for
an output before you sign it.
| Tool | What it is for |
| --- | --- |
| **Bump Stuck TX** | Compare RBF and CPFP for a transaction that is not confirming |
| **Advanced TX Builder** | Choose inputs and outputs yourself |
| **UTXO Split** | Split one output into several |
| **Asset Recovery** | Reclaim satoshis locked in inscription padding |
## Read this first
Three of these four screen your outputs and refuse to spend anything carrying an asset.
**One does not.** The Advanced TX Builder will let you spend an output holding an
inscription or a Rune, on purpose, after labelling it. If you do not need that, use a
different tool.
## Bump Stuck TX
A transaction that is broadcast and not confirming, because the fee rate was too low for
conditions at the time.
The workspace compares the two ways out:
| Method | How it works | When it applies |
| --- | --- | --- |
| **RBF**, replace-by-fee | Broadcast a replacement of the same transaction at a higher fee rate | Only if the original signalled that it could be replaced |
| **CPFP**, child-pays-for-parent | Spend an output of the stuck transaction at a rate high enough to make mining both worthwhile | When RBF is not available, or the transaction is not yours to replace |
The tool says which applies to your case rather than making you work it out, and shows the
asset report for every output before you sign.
**It is marked Beta in the app.** It is released and reachable; that label is the product
own assessment.
If the stuck transaction is the payment to an order commit address, use **Fix My Payment**
instead. See [recovery routes](/docs-inscribe/manage/recovery/#the-payment-is-stuck).
## Advanced TX Builder
Choose the inputs and outputs yourself. This exists for people who need a specific satoshi
in a specific position, which is not something an automatic rule can do for you.
**This is the one surface that will spend an asset-bearing output.** It has an
inscription-output picker that labels what it finds, with a badge naming the inscription
number and a badge marking a Rune, and then it lets you proceed.
That is a decision, not a gap. On this screen, where the satoshi ends up is your
responsibility.
Everywhere else, an output the index reports as carrying an asset is never chosen
automatically. See [asset safety](/docs-inscribe/concepts/asset-safety/).
## UTXO Split
Split one output into several.
**Why you would want to.** Bitcoin spends an output whole. One large output means every
payment drags the whole amount through a transaction and hands you change. Several
right-sized outputs let you spend a little without disturbing the rest, and give a fee
funder something to work with that is not your savings.
It is also how you prepare for a busy mint: separate outputs mean separate transactions can
be funded without waiting for each other.
**What it shows you.** A full asset preflight report per output before you sign. It lists
only plain bitcoin outputs large enough to cover the new outputs, the network fee and the
service fee, so an asset-bearing output is not offered as split material.
## Asset Recovery
Reclaim satoshis locked in inscription padding, at `/recover-sats`.
Inscriptions sit on outputs holding satoshis, and some of those can be reclaimed without
disturbing the inscription. The tool validates the chain and mempool state before calling
anything recoverable, so a candidate it offers has been checked rather than guessed at.
**No service fee is charged**, here or in Fix My Payment. You are repairing something, not
buying something.
If this route returns the 404 page, the feature is switched off in this deployment. It is
one of only two surfaces that 404 rather than loading and refusing to act.
Full steps are in
[recovery routes](/docs-inscribe/manage/recovery/#recover-padding-satoshis).
## Safety rules for all four
- **Read the asset report.** It is the reason these surfaces exist rather than sending you
to a generic transaction builder.
- **Check the outputs list in your wallet**, not only in Inscribe. The wallet screen is the
last accurate description of what you are about to sign.
- **Confirm your inscriptions survived** after a split or a recovery, by checking the
destination on an explorer.
- **Never describe a screened selection as safe to yourself.** Screening removes outputs the
index flagged. It does not prove the rest are clean, and Inscribe does not claim it does.
## Other tools
**Bitcoin Tools** carries 33 focused utilities: decoders, estimators, inspectors and
planners. **Pending TX Analyzer** reads one pending transaction in detail. **Mempool** shows
what is waiting to confirm, grouped by protocol family and sized by transaction weight.
## Related
- [Asset safety](/docs-inscribe/concepts/asset-safety/)
- [Recovery routes](/docs-inscribe/manage/recovery/)
- [Workspace map](/docs-inscribe/reference/workspaces/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/manage/pending-orders =====
# Orders you started
How Inscribe gets you back to an order after a closed tab or a reload, what the browser remembers, what it deliberately does not, and why the list shows no status.
An order interrupted by a closed tab is not lost. Home lists the orders this browser
started.
## Why a reload loses access
Access to an order is a secret Inscribe keeps in the browser memory and never writes to
storage.
That is a deliberate trade. Keeping it in memory is what stops another site reading it. The
cost is that a reload lets it go, and the order page then has to ask who you are again.
**An order id proves nothing on its own.** Knowing the id does not grant access, which is
why a list of ids is safe to keep and a status is not.
## What Home remembers
Under "Orders you started in this browser", newest first:
- the workflow, so you can tell one order from another;
- a truncated order reference;
- how long ago this browser recorded it;
- a link to the order;
- a control to forget the entry.
**What it holds:** an order id, its workflow, and the time this browser saw it.
**What it never holds:** the order secret, an address, an amount, a draft transaction, a
transaction id, or anything about your wallet. It is not sent anywhere.
**Bounds:** the 50 most recent orders, and 30 days. An order that finishes drops off on its
own, and you can forget any entry at any time.
## Why there is no status column
Reading an order status requires the secret. The list does not have it, so any status shown
there would be invented.
The list tells you the order exists and how to reach it. The status page, after the
ownership check, tells you where the order stands. That division is the honest one.
## Entries with no time
An order started before this list existed still appears, because its reference was already
in the browser.
Those entries carry no time and **say so**, rather than showing an age that would be wrong.
Stamping them with the moment they were found would report a months-old order as new.
## Getting into an order
Open one and Inscribe asks your wallet to prove it owns the order before showing any
payment detail. It also accepts an encrypted recovery kit if you saved one at creation.
Four routes exist in total, covered in
[recovery routes](/docs-inscribe/manage/recovery/#you-lost-the-order): the order URL, this
list, a recovery kit, and a wallet signature.
## Activity
**Activity** is the fuller view: orders this browser has started, and the recovery tools for
them. It carries a recovery queue that ranks anything needing attention and offers one
action per item.
Unlike Home list, Activity requires a connected wallet to have signed an authorization
before it shows saved orders. That is why Home carries the lighter list: it works when you
have nothing but the browser you paid from.
## When a release lands while your tab is open
Every screen in Inscribe loads as its own file, and a release replaces those files. A tab
open across a release asks for a file that is no longer on the server, and the screen you
clicked does not open.
Inscribe recognises this and says so rather than reporting a crash: a new version was
released, reload to fetch it. A dropped connection produces the same failure and the same
fix, so the message covers both rather than guessing between them.
**Nothing you started is lost by the reload.** The orders this browser recorded are listed
on Home when it comes back, and your wallet reconnects the way it did before. Reopening an
order still asks your wallet to prove ownership, as it does after any reload.
## What keeps running without you
Everything after your payment. Universe watches the commit address, builds and broadcasts
the reveal, and retries a failed broadcast, whether or not your browser is open.
Closing the tab does not cancel a paid order, and there is no way to cancel one by closing
it.
## Related
- [Recovery routes](/docs-inscribe/manage/recovery/)
- [The life of an order](/docs-inscribe/concepts/order-lifecycle/)
- [Order states](/docs-inscribe/reference/order-states/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/manage/portfolio =====
# Portfolio
What Portfolio shows, why the bitcoin balance and the asset balance are never added together, what Partial means, and how to see any address without a wallet.
**Portfolio** shows everything your connected wallet holds, grouped by protocol.
## The three views
| View | What it shows | Wallet needed? |
| --- | --- | --- |
| **Portfolio** | Everything your connected wallet holds | Yes |
| **Explore** | The same view for any address you paste | No |
| **Watchlist** | Addresses you track without connecting them | No |
**Explore** is the one worth remembering. You can inspect any address, including your own,
without connecting anything.
## Two balances, never one
The bitcoin balance card reports the **payment address** on its own.
Satoshis sitting at an Ordinals address are carrying assets. They are not spendable from
there, and adding the two figures together would tell you that you can spend money you
cannot. So Inscribe does not.
Read [wallets and the two addresses](/docs-inscribe/concepts/wallets-and-addresses/) for
what each address is for.
## Where the numbers come from
Portfolio reads several independent sources:
| Source | What it supplies |
| --- | --- |
| The Bitcoin node | Your bitcoin balance and your outputs |
| The Ordinals index | Inscriptions and Rune balances |
| Separate indexes | Mezcal, SRC-20, OP_DROP and OP_RETURN names |
They fail independently, which is why the page can be partly right and says so.
## Live and Partial
The header reads **Live** when every source answered, and **Partial** when one did not.
When a source is silent, the page names it above your holdings and says three things:
- anything held there is missing from this page;
- what is shown is everything the sources that did answer reported;
- **nothing you own has changed**.
That last line matters. A missing index is a reporting problem, not a loss.
**An empty portfolio is never presented as an answer while a source is silent.** The page
says nothing was found in the sources that answered and that this is not a complete
picture. "No assets found for this address" appears only when every source answered.
This applies per source. If only the Ordinals index is behind, your Mezcal, SRC-20 and
OP_DROP balances are still real numbers from indexes that did answer.
## What gets classified
Around thirty protocol categories are recognised, including BRC-20, ARC-20, CAT-20, Runes,
Ordinals, Bitmap, rare sats, Stamps, SRC-20, SRC-101, Atomicals, Alkanes, Mezcal, DMT, TAP,
UNAT, BLOCK-20, DUST-20, OP-20, OP Names, OP_RETURN, Drops, OP_DROP and Tandem.
Anything it cannot place shows as **Unclassified** rather than being dropped from the list.
A dropped item would look like an item you do not own.
Several of these are recognised here but not creatable in Inscribe. Bitmap, UNAT and DRC-20
are the clearest cases: you will see them in your portfolio and Inscribe will protect them
from being spent as fees, but there is no workspace for making or moving one.
## Privacy
Portfolio, Watchlist, Activity, order, payment-recovery and wallet views suppress social
preview images and are marked not to be indexed. A link preview never contains a wallet
address, a balance, a session, an account, an order payload or a draft transaction.
If you need to share a view, **Screenshot safe** in Settings hides balances and addresses.
## Media
Inscription images, text, HTML, audio and video load from Universe-operated infrastructure
rather than third-party explorers.
Thumbnails use small AVIF or WebP renders where the shared media service has one, and
otherwise the original bytes scaled to the tile. **The exact original bytes are never
altered**; derived previews are for display only. Video and audio in galleries do not
download until you open them.
Active content, meaning HTML, scripts, and SVG with scripts, always renders inside an
isolated sandbox.
## Related
- [Where the data comes from](/docs-inscribe/concepts/source-freshness/)
- [Asset safety](/docs-inscribe/concepts/asset-safety/)
- [Speed and media](/docs-inscribe/about/performance-and-media/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/manage/recovery =====
# Recovery routes
Every route back from an unpaid, underpaid, stuck or interrupted order, the two dedicated repair tools, and the one situation with no recovery at all.
Start here when something has gone wrong after you paid.
**The first rule: do not pay again.** Almost every problem on this page is made worse by a
second payment, and none is fixed by one.
## Find your situation
| What happened | Where to go |
| --- | --- |
| You paid, but the order still says awaiting payment | [Payment not detected](#payment-not-detected) |
| You sent less than the quote | [You underpaid](#you-underpaid) |
| You sent more than the quote | [You overpaid](#you-overpaid) |
| Your payment is not confirming | [The payment is stuck](#the-payment-is-stuck) |
| You closed the tab and lost the order | [You lost the order](#you-lost-the-order) |
| The hour ran out | [The quote expired](#the-quote-expired) |
| Satoshis are trapped in inscription padding | [Recover padding satoshis](#recover-padding-satoshis) |
| You sent an asset to the wrong address | [No route](#the-situation-with-no-route) |
## What is never thrown away
Before the individual cases, the guarantee they all rest on.
An order signing key is discarded in exactly two situations: after a confirmed successful
spend, or after an explicit recovery that hands control somewhere else.
It is **never** discarded because:
- a data provider timed out;
- a lookup returned nothing;
- a retry limit was reached;
- an hour passed.
There is no expired or cancelled state for an inscribe order. An order that looks dead on
screen still has its key.
## Payment not detected
**What is happening.** Universe checks the commit address every ten seconds and accepts an
unconfirmed payment, so a payment that is genuinely there usually appears within a minute.
**What to do.**
**Wait two minutes.** The most common cause is impatience.
**Check where your payment actually went.** Look up your transaction on any explorer and
compare the recipient against the commit address the order gave you. A payment to a
different address is a different problem, and no amount of waiting fixes it.
**Check the service status panel.** If the source that reads addresses is unavailable or
behind, detection is delayed rather than broken.
**Do not send a second payment.** If several payments land on the address, Inscribe uses
the one matching the quote, or the smallest that covers it. Your second payment is not
consumed and is not automatically returned either.
## You underpaid
The order is not lost. It records that the payment was below the quote and keeps checking.
**Top the same commit address up to the quoted amount.** The flow resumes on its own.
Nothing is cancelled and no key is discarded.
If you can no longer reach the order page, recover access first: see
[you lost the order](#you-lost-the-order).
## You overpaid
The surplus comes back to you automatically. The reveal transaction adds an output sending
the extra to the address that funded the order.
Two conditions apply, and they are about physics rather than policy:
- The surplus must be large enough to cover the extra bytes the refund output costs.
- What remains must clear the dust threshold for the address type.
If the surplus is too small to send back, **it is added to your inscription output
instead**, where you still own it. Nothing is kept.
## The payment is stuck
Your transaction is broadcast but not confirming, because the fee rate was too low for
conditions at the time.
Inscribe has two tools, and they solve different halves of the problem.
### Fix My Payment
At `/fix-payment`. Use this when the payment to the commit address is the transaction that
is stuck.
**No service fee is charged.** You are paying to repair something, not to buy something.
**Enter the order ID** and prove ownership.
**Review the diagnosis.** The tool reads the current state of your payment and says what is
wrong with it.
**Choose the repair** it offers for your case.
**Set a fee rate that reflects current conditions**, not the one that failed.
**Sign the repair transaction.**
*Expected wallet screen:* a transaction fixing the original payment. Check the amount and
the recipient before approving.
### Bump Stuck TX
The fee-bumping workspace. Use this for a transaction of your own that is not confirming.
It compares **RBF** (replace-by-fee, sending a replacement of the same transaction at a
higher rate) against **CPFP** (child-pays-for-parent, spending an output of the stuck
transaction at a high enough rate to pull the parent in), and shows the asset report for
every output before you sign.
The workspace is **marked Beta in the app**. It is released and reachable, and that label
is the product own assessment rather than something this documentation is adding.
RBF only works if the original transaction signalled that it could be replaced. Where it
did not, CPFP is the route, and the tool says which applies.
## You lost the order
Access to an order is a secret Inscribe keeps in the browser memory and never writes to
storage. That is what stops another site reading it, and it means a reload lets it go.
There are four routes back.
| Route | What you need |
| --- | --- |
| **The order URL** | The exact `/inscribe/` link, if you still have it |
| **Home** | Nothing. Home lists the orders this browser started |
| **A recovery kit** | The encrypted kit, if you saved one when the order was created |
| **Wallet signature** | The order id, plus the same wallet and network used at creation |
**Start with Home.** Under "Orders you started in this browser" it lists them newest first,
with the workflow, the order reference, and how long ago it was recorded. Opening one takes
you to its status page.
Reopening an order asks your wallet to prove it owns the order before any payment detail is
shown. That check runs after any reload, because the order secret only ever lives in
memory.
The list holds an order id, its workflow, and when this browser saw it. Never a key, an
address, an amount, or anything about your wallet, and it is not sent anywhere. It keeps
the 50 most recent orders, for 30 days.
It does not show a status, because reading one requires the secret and any status shown
there would be invented.
See [orders you started](/docs-inscribe/manage/pending-orders/) for more.
## The quote expired
The hour on the screen is the life of the **price**, not the life of the order.
**If you have not paid:** start a fresh order at a current price. The old fee rate may no
longer get your transaction mined.
**If you have already paid:** do not pay again and do not start a new order. The address
keeps being checked on a slowing schedule, so a late payment is still found and reconciled.
Go to the order and, if it needs help, use Fix My Payment.
## Recover padding satoshis
At `/recover-sats`. Inscriptions sit on outputs with satoshis in them, and some of those
satoshis can be reclaimed without disturbing the inscription.
**No service fee is charged.**
**Connect your wallet.**
**Let it scan** for recoverable padding across your holdings.
**Review what it found.** It validates the chain and mempool state before offering anything
as recoverable, so a candidate here has been checked rather than guessed at.
**Select what to recover** and set a fee rate.
**Sign.**
*Expected wallet screen:* a transaction reclaiming the padding. Check that your inscription
outputs are preserved in the outputs list.
**Verify** that the inscriptions are still at your address afterwards.
If this route returns the 404 page, the feature is switched off in this deployment. It is
one of only two surfaces that 404 rather than loading and refusing.
## The recovery queue
**Activity** carries a recovery queue that ranks anything needing attention across your
orders and offers one action per item. It is the right place to look when you are not sure
what state something is in.
## Failed reveals
You do not need to do anything about these. A reveal that fails to broadcast is retried
with backoff, from 30 seconds upward.
The safety property that makes automatic retry acceptable: **the exact signed transaction
is written down before the first network call is made**, so a retry can only ever resend
the same transaction. There is no version of the retry that spends your money twice.
## The situation with no route
**A transaction you signed that did what you told it to.** If you sent an asset to the
wrong address, deliberately spent an asset-bearing output in the Advanced TX Builder, or
approved a wallet send from an address holding assets after being warned, the result is
final.
The fee is spent, the asset has moved, and no operator can reverse it. This is a property
of Bitcoin, not a limitation of Inscribe.
## Related
- [Orders you started](/docs-inscribe/manage/pending-orders/)
- [The life of an order](/docs-inscribe/concepts/order-lifecycle/)
- [Advanced transaction tools](/docs-inscribe/manage/advanced-transactions/)
- [Common problems](/docs-inscribe/troubleshooting/common-problems/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/accessibility =====
# Accessibility
The release gates every page and screen must pass, in both themes.
# Accessibility
Inscribe is built to be used with a keyboard, a screen reader, a magnifier, or
none of those. This page says what that means in practice and how it is
checked.
## Colour and contrast
Every colour in the app comes from a named role rather than a value typed into
a component, and each role is measured against the surface it lands on. A
component can say "this is a warning" or "this is the primary action". It
cannot say "this is amber".
That is a rule the build enforces, not a convention. A component that names a
colour fails the tests before it can be merged.
The brand pink is the clearest example of why roles exist. `#ff0066` is the
Bitcoin Universe colour, but white text on it measures 3.85:1, below the 4.5:1
that WCAG AA asks for. So the pink has three jobs and three values:
| Role | What it is for | Measured |
| --- | --- | --- |
| Brand fill | Buttons and chips that carry a white label | 4.80:1 with white |
| Brand text | Pink words on a page background | at least 4.5:1 on every surface it lands on |
| Brand tint | Washes and focus rings | nothing readable sits on it, so the original pink stays |
Success, warning, danger and information work the same way, and each has a
light value and a dark value that were measured separately.
They are measured in the hardest case rather than the easiest. A status chip
inside a status panel inside a section puts three tinted washes over the same
background, and each one shifts it. Every status colour is checked against
three stacked washes on the lightest surface of its theme, because that is what
actually reaches the screen.
## Type size
Nothing renders below 11 pixels. That is a floor the build enforces, not a
guideline: a component asking for a smaller size fails the tests.
The floor exists because small text collects in the places that matter most.
Before it was enforced, the smallest text in the product was on the panel that
lists what a UTXO holds, which is the one screen that tells you an asset is at
risk.
## Themes
Light and dark are both first-class. The app follows your system setting by
default and remembers an explicit choice. Neither theme is a filter over the
other: each has its own measured values for surfaces, borders, text tiers,
brand and status colours.
## Controls you can turn on
Settings carries display controls that change how the app renders for you:
- **High contrast** strengthens borders and separators.
- **Large text** raises the base type size.
- **Reduced motion** removes transitions and animation. The app also honours
your operating system's reduced-motion setting without being asked. There is
less to remove than there used to be: the app no longer runs decorative
animation at all. What moves is reporting something: content loading, a
panel arriving, a transaction still waiting on the chain.
- **Density** switches between compact, comfortable and spacious spacing.
- **Enhanced focus rings** makes the keyboard focus outline heavier.
- **Screenshot safe** hides balances and addresses so you can share a view.
- **Colour-blind safe** moves the success, warning and danger colours onto a
blue, yellow and purple set that separates under deuteranopia and
protanopia. Colour is never the only signal for a state, so this is a
legibility aid rather than the state itself.
Each of these changes the colour roles rather than a list of components, so it
reaches every screen, including ones written after the control existed.
## Keyboard and screen readers
- A skip link is the first focusable element on every page and jumps to the
main content.
- The command palette opens with `Ctrl` + `K`, or `Cmd` + `K` on macOS, and
reaches every workspace by name.
- Modal dialogs hold focus while they are open and hand it back to whatever
opened them.
- Live regions announce the changes you would otherwise have to notice, such
as a source going down or an order moving on.
- Primary buttons and inputs are 44 pixels tall, which is what a finger needs.
The enforced floor is lower, and the next section says exactly what it is.
## What gets checked, and how
Accessibility is a release gate, not a review pass.
Every pull request runs axe-core against the app's real routes in ten browser
and viewport combinations: Chromium, Firefox and WebKit, in light and dark,
from 320 pixels wide up to 1440. The routes include the states that are easy to
forget, such as a workspace whose data source is unavailable, an order being
recovered, and a first visit with the consent banner still up.
A run fails on any of these:
- an axe violation at serious or critical impact, against the WCAG 2.0, 2.1 and
2.2 A and AA rule sets;
- text measured below AA against the surface actually painted behind it, with
every see-through layer composited first;
- an interactive target whose pointer region is under 24 by 24 pixels, which is
the WCAG 2.2 AA floor, measured on the label where a control is bound to one;
- horizontal overflow on the document, the body, or the main region;
- a cumulative layout shift above 0.05 on Home, Explore, Runes, Tools, Activity
or Portfolio;
- a runtime error in the browser console.
## Two things that were hard to see
Both were found by measuring the app as it renders rather than by reading the
code, and both are worth naming because they are the kind of thing that hides
in plain sight.
**The mempool map labelled each protocol in that protocol's own colour**, on a
tile tinted with the same colour. Green on green measured 3.03:1. The colour
still tells you which protocol a tile is, through the tile and its heading
band. The name on top of it is now plain page text, so it reads at full
strength on every tile.
**The map also shrank names to fit.** On a busy map a label could reach 7.4
pixels, and on a narrow tile the transaction figures pushed the name out
completely, leaving something like `9.6(11.4%`. Names never go below 11 pixels
now. A tile spends its width on the name first, then the share, then the
volume, and a tile too narrow for a readable name carries no text at all. Its
colour identifies it, and hovering or tapping gives you the whole thing.
## Where it falls short
The app has not been audited by an external accessibility practitioner, and
automated checks catch roughly a third to a half of real barriers. Colour,
structure, focus order and overflow are covered well. Judgement calls, such as
whether a label reads clearly out of context, are not.
If something blocks you, [open an issue](https://github.com/bitcoinuniverseio/docs-inscribe/issues).
Say what you were doing and what you use to browse. That is more useful than a
rule number.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/admin-control-center =====
# Admin Control Center
The private operations surface: health, orders, indexers, and audit.
# Inscribe Control Center
The Inscribe Control Center is a restricted operational workspace at `/admin`.
It gives authorized operators one view of application health, protocol state,
orders, transactions, indexers, recovery actions, and audit history.
## What operators can see
- application, database, Bitcoin chain, worker, and indexer readiness;
- active, failed, and recoverable order totals;
- protocol deployment state and operation coverage;
- order and transaction search across supported workflows;
- service lag, last successful checks, and current error summaries;
- a complete classification of public state-changing routes; and
- the result, target, time, and correlation identifier for each admin action.
Status labels distinguish healthy, syncing, degraded, unavailable, policy-disabled,
and not-configured states. A successful HTTP response alone is not treated as
proof that a chain source or indexer is current.
The Control Center also compares the Bitcoin node and index heights. It reports
the index as syncing when the node is still rebuilding and sits behind the index,
instead of showing a false healthy state. A short index delay behind a current
node remains normal.
## Safe operations
The workspace exposes only actions that can run safely on the server. Operations
that require a wallet signature remain in the user workflow and cannot be bypassed
from the Control Center. Policy-disabled capabilities stay disabled.
Read-only and safe refresh actions can run directly. State-changing actions show
a preview before execution. High-risk recovery actions require a second explicit
confirmation. Every execution uses a unique action key and writes an audit record
before the underlying operation begins.
## Access and privacy
The unauthenticated route displays only the sign-in screen. The public application
navigation and workspace are not rendered behind it. Passwords are never included
in frontend assets or browser storage.
Successful sign-in creates a short-lived server-side session in a protected cookie.
Requests that change state also require a session-bound verification token. Sign-in
attempts are rate-limited, logout revokes the server session, and expired sessions
must authenticate again.
Audit summaries remove credential-like, wallet-secret, signed-transaction, and
capability fields before storage. Operators should still avoid placing unrelated
sensitive information in free-form fields.
## Operational expectations
The Control Center reports live production state. If a service is shown as
unavailable or not configured, the safe response is to inspect its health evidence
and runbook. Do not enable a protocol or retry a high-risk action simply to clear a
status label.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/agent-surfaces =====
# For agents and LLMs
Machine-readable surfaces: full-text corpus, JSONL, skill guidance, MCP tools, and how to cite provenance.
## Read this site without a browser
Every public page has a generated Markdown representation with the same content, headings, warnings, tables, captions, and links as the HTML. The generated artifacts come from the same source collection as the site, so they cannot drift.
- `/llms.txt` indexes the site for retrieval agents.
- `/llms-full.txt` holds the complete corpus in one document.
- `/corpus.jsonl` lists one JSON object per page and section with stable ids, provenance, and last-verification data.
- `/skill.md` describes the read-only Inscribe documentation tools and their safety boundaries in a form an agent can follow.
- `/learning-manifest.json` is the structured manifest behind the planner, the labs, and the recovery navigator: workflows, protocols, guides, recovery outcomes, and the source commits every fact came from.
- Every page supports `?format=markdown`, and the page footer offers "Copy as Markdown" and "View as Markdown".
## MCP tools
The existing documentation MCP server exposes deterministic, read-only Inscribe planning tools: plan an action, compare protocols, triage a recovery, explain a quote, fetch a walkthrough or practice scenario, and report learning health. Every answer carries the input as normalized by the schema, the result, assumptions, exclusion reasons, the three lifecycle states, the owning documentation route, and the source commits.
The tools never accept wallet secrets, never connect to wallets, and never create orders. They call the same engines the browser uses, so an agent and a reader get the same answer for the same question.
## Citing this site
Cite the page URL plus the documentation commit from the page footer. If a fact matters to money, prefer the in-app quote over any number published here: documentation teaches, the app decides.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-02
===== inscribe-docs/reference/fee-tiers =====
# Fee tiers
The tiers Inscribe offers, the accepted rate range, where the rates come from, how often they refresh, and every case where two tiers legitimately show the same number.
A reference table. For what the fee actually buys, read
[what a transaction costs](/docs-inscribe/concepts/what-it-costs/).
## The tiers
| Tier | Targets | Default? |
| --- | --- | --- |
| **Normal** | A place in the blocks mined over roughly the next half hour | Yes, and marked Recommended |
| **Fast** | A place in the next block, roughly ten minutes | No |
| **Custom** | Any rate you type, within the accepted range | No |
| **Sub 1** | Rates below 1 sat/vB. Marked Beta | No, and never becomes the default |
**The default is never the more expensive option.** Normal is what a form opens on.
## Accepted range
| Setting | Value |
| --- | --- |
| Minimum | 0.1 sat/vB |
| Maximum | 10,000 sat/vB |
| Refresh | Every 30 seconds |
A protocol can raise the floor above 0.1 or require whole satoshis, and the fee control uses
the protocol own minimum where it has one. So the rate you are charged is not always the
rate the quote returned.
## Where the rates come from
Universe-operated Bitcoin infrastructure, not a public provider. The upstream answers with
block targets, which map onto the tiers:
| Upstream target | Tier |
| --- | --- |
| Next block | Fast |
| About three blocks | Normal |
| Relay floor | The minimum |
## The waits are earned, not labelled
The wait shown on a tier is derived from the rate that tier actually quotes, not fixed in
advance.
- **Fast** always shows the next-block wait, because that is its target.
- **Normal** shows the half-hour wait **only while its rate is genuinely lower than Fast**.
When the two are equal it shows the next-block wait instead.
Bitcoin block times are random, so all of these are averages rather than promises.
## When two tiers show the same number
This is expected in three situations, and the app explains it on both tiers rather than
printing a shorter wait next to the higher-sounding option:
| Cause | What is happening |
| --- | --- |
| **Blocks have room** | The rate that gets you into the next block is the same rate that would have got you in within half an hour |
| **Whole-satoshi rounding** | A protocol requiring whole satoshis collapses two different quotes onto one rate |
| **A higher relay floor** | A protocol minimum lifts both tiers to the same number |
The note reads:
> Blocks have room right now, so Normal costs the same as Fast and confirms just as soon.
Two prices that are the same number are the same purchase. Paying more for one of them
would buy nothing.
## Sub 1
Rates under one satoshi per virtual byte are real rates that real miners sometimes accept.
They can take a long time, or never confirm at all.
The control is marked **Beta**, shows the exact rate you have chosen, and never becomes the
default.
Do not use it for a contested mint, or for anything where a delay costs you the outcome.
## Stale rates
If the rate source stops answering, the fee control shows **Cached fees** in place of the
refresh countdown. A stale quote is never presented as a live one.
On a network where a fabricated rate would be worse than no rate, Inscribe refuses to quote
and reports the service as unavailable rather than serving a fallback price.
## Size estimation
Some figures that shape the network fee line:
| Case | Cost in virtual bytes |
| --- | --- |
| Inscribing a child under a parent | About 101 extra virtual bytes, for spending and returning the parent |
| The service fee output | A real output, so it costs bytes, already included in the total |
The figure shown before you create the order is a preview. The order the backend builds
carries the authoritative price.
## Accessibility
Each tier is a button whose accessible name carries the tier, its rate in satoshis per
virtual byte, and its wait, so the price is available without reading the visual card. The
recommended tier says that it is recommended.
## Related
- [What a transaction costs](/docs-inscribe/concepts/what-it-costs/)
- [Recovery routes](/docs-inscribe/manage/recovery/#the-payment-is-stuck), when a rate turns
out to be too low
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/glossary =====
# Glossary
The terms used across this documentation and in the Inscribe interface, defined in the sense Inscribe uses them.
Terms as Inscribe uses them. Where a word means something narrower here than in general
usage, the narrower sense is the one given.
## Addresses and wallets
Payment address
The address holding your spendable bitcoin. It funds orders and pays network fees. Often starts bc1q or 3.
Ordinals address
The Taproot address holding your inscriptions, rune balances and token balances. Starts bc1p on mainnet. Its satoshis are carrying assets and are not spendable money.
Commit address
A one-time address generated for a single order. You pay it once; the order key spends it.
Destination address
Where an asset is being sent. Named on the confirmation screen so you can check it.
## Money
Network fee
What miners are paid. Your fee rate times the transaction size. A fee.
Service fee
A flat 1,500 satoshis for most actions, charged once per order. A fee. Fee-bumping and asset recovery charge nothing.
Inscription output, also Mint UTXO Value on screen
The satoshi your inscription sits on, plus its padding. Not a fee. It stays yours. Defaults to 546 satoshis.
sat/vB
Satoshis per virtual byte, the unit a fee rate is quoted in.
Dust threshold
The smallest output value the network will relay, which depends on the address type. 294 for P2WPKH, 330 for P2WSH and Taproot, 546 used as a safe fallback.
Padding
The satoshis in an inscription output beyond what the inscription strictly needs. Some can be reclaimed with Asset Recovery.
## Transactions
UTXO, unspent transaction output
A discrete parcel of bitcoin. Bitcoin spends an output whole, which is the reason asset safety exists at all.
Commit transaction
The first of the two transactions. Yours: your wallet builds and signs it. It funds the commit address.
Reveal transaction
The second. It spends the commit output and carries your content onto the chain. Signed by the order own key, which is why you sign only once.
RBF, replace-by-fee
Broadcasting a replacement of a stuck transaction at a higher fee rate. Only possible if the original signalled that it could be replaced.
CPFP, child-pays-for-parent
Spending an output of a stuck transaction at a rate high enough that mining both becomes worthwhile. The route when RBF is not available.
## Assets
Inscription
Content written into the witness of a Bitcoin transaction and tracked to a particular satoshi.
Parent and child
An inscription made under a parent inscription you own, so its membership of a collection is provable from the chain. Requires a second signature.
Delegate
An inscription pointing at another inscription content, so the bytes are stored once.
Etch
The Runes word for bringing a new rune into existence. What other protocols call a deploy.
Deploy
Creating a new token and fixing its ticker, supply and per-mint limit.
Mint
Claiming an amount of a token or rune that already exists.
## Classification and safety
Assets detected
An index positively reported an asset on this output. Never spent automatically.
No known risk
A complete, untruncated, sourced and dated scan classified this output as plain bitcoin. Spent first.
Unverified
The scan did not complete, was truncated, or could not answer. Still spendable, ranked after cleared outputs. Unknown is not the same as safe.
Unclassified
An asset the inventory recognises as present but cannot place into a protocol category. Shown rather than dropped.
## Data states
Live
The source is answering and current with the chain.
Live, currency unverified
Answering, but reports no height, so currency cannot be checked.
Tip not verified
Answering with a height, but the chain tip could not be read for comparison.
Behind
Answering with a height that trails the chain tip.
Unavailable
Not answering. Never presented as an authoritative empty result.
Partial
The portfolio header when at least one source did not answer.
## Release states
Released, ungated
Available, and covered by the release health and smoke checks.
Released
Available in principle. A deployment decides whether to switch it on.
Not released
Unfinished work present in the codebase. Do not rely on it.
Read-only in Inscribe
The protocol is recognised in your portfolio and in asset screening, but there is no workspace for creating it.
## Order states
Awaiting payment
Quoted, waiting for the commit address to be funded.
Creation in progress
Payment seen. Covers broadcast, confirmation and indexing.
Wallet visible
The indexer and your wallet agree the asset exists. Done.
Failed
Needs attention. See recovery routes.
## Related
- [What a transaction costs](/docs-inscribe/concepts/what-it-costs/)
- [Order states](/docs-inscribe/reference/order-states/)
- [Asset safety](/docs-inscribe/concepts/asset-safety/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/order-states =====
# Order states
The four states an Inscribe order shows you, what each one covers, why there is no cancelled or expired state, and what confirmations are required at each batch size.
An order shows you one of four states. They are deliberately coarse: the underlying machine
has more steps, and most of them are not decisions you can act on.
## The four states
| State | What it covers | Do you need to do anything? |
| --- | --- | --- |
| **Awaiting payment** | The order is quoted and waiting for the commit address to be funded | **Yes.** Pay it, or the order sits here |
| **Creation in progress** | Payment seen, reveal built, broadcast, confirmed, being indexed | No. This runs without you |
| **Wallet visible** | The indexer and your wallet both agree the asset exists | No. This is done |
| **Failed** | Something needs attention | **Yes.** See [recovery routes](/docs-inscribe/manage/recovery/) |
The full status line for the middle state says what it is waiting on:
> Creation in progress, waiting for chain, indexer, and wallet evidence.
## Why "in progress" outlasts your confirmation
Broadcast, confirmed and indexed are all still **Creation in progress**. The order only
reaches **Wallet visible** when the indexer and your wallet agree the asset exists.
Claiming success at broadcast would be right most of the time and wrong in exactly the cases
where being wrong costs you the most. A transaction that confirmed but was not credited by a
protocol index is the clearest example: the chain agrees, and you still do not have the
token.
## There is no cancelled or expired state
Inscribe orders do not have one.
The hour on the screen is the life of the **price quote**. When it passes, the quote is no
longer good and you should start a fresh order at a current price. What does not happen:
- the order is not deleted;
- the signing key is not erased;
- the commit address stops being checked.
The address keeps being checked on a slowing schedule, so a payment that arrives late is
still detected and reconciled.
A signing key is discarded in only two situations: after a confirmed successful spend, or
after an explicit recovery that hands control elsewhere. Never because a provider timed out,
a lookup returned nothing, a retry limit was reached, or an hour passed.
## Payment detection
| Property | Value |
| --- | --- |
| Check interval | Every 10 seconds |
| Confirmations needed for a standard single inscription | **Zero.** An unconfirmed payment is enough |
| Which payment is used if several arrive | The one matching the quote exactly, then the smallest that covers it |
Preferring the smallest sufficient payment is deliberate: taking the largest would swallow
an accidental overpayment that belongs to you.
## Confirmations required by batch size
Bulk jobs fan a payment out across many addresses first, and a fan-out that gets reorganised
would strand the whole job.
| Items | Confirmations before the job proceeds |
| --- | --- |
| Up to 22 | None |
| 23 to 500 | 1 |
| More than 500 | 2 |
Reveals are then broadcast in chunks of no more than **24**, because Bitcoin mempool refuses
a chain of more than 25 related unconfirmed transactions.
## Quote lifetimes
| Flow | Quote good for |
| --- | --- |
| Most flows | 1 hour |
| Gallery | 24 hours |
| A prepared parent-and-child reveal, waiting for your signature | 15 minutes |
## Underpayment and overpayment
**Underpaid.** The order records it and keeps checking. Top the same address up to the
quoted amount and the flow resumes.
**Overpaid.** The reveal adds an output returning the surplus to the funding address, where
the surplus is large enough to cover the extra bytes and still clear the dust threshold.
Where it is not, the surplus is added to your inscription output instead.
## Broadcast retries
A reveal that fails to broadcast is retried with backoff, from 30 seconds upward.
The exact signed transaction is written down before the first network call is made, so a
retry can only ever resend the same transaction. There is no version of the retry that
spends your money twice.
## Related
- [The life of an order](/docs-inscribe/concepts/order-lifecycle/)
- [Orders you started](/docs-inscribe/manage/pending-orders/)
- [Recovery routes](/docs-inscribe/manage/recovery/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/performance-and-media =====
# Performance and media
Load order, caching windows, and where media is served from.
# Speed and media delivery
Universe Inscribe loads the workspace shell first and fills each section as its data arrives. This page explains what you can expect and where the data and media come from.
## What loads first
- The app shell, navigation, and your current page appear before protocol data. Each page reserves its space while it loads, so content does not jump when lists and panels arrive.
- Scripts and styles are compressed at build time and cached by your browser for a year under unique file names. A new release never mixes old and new files.
- Production builds preload only the runtime and shared interface library needed by the first screen. Wallet and protocol workspaces continue loading when you open them, which keeps the initial page within its reviewed download budget.
- Icons, fonts, and logos are small files served from Inscribe itself, stored at the size they are shown.
## Protocol data
- Public token lists, indexer status, and fee reads may be reused for a short time (10 to 300 seconds depending on the read) so repeat views and other users get an instant answer. Every list shows the time window it covers.
- Wallet balances, portfolio reads, orders, and anything tied to your session are never cached by the browser or by shared caches.
- When an indexer is slow, Inscribe can serve the last good answer while it refreshes in the background. It never shows a failed read as an empty result.
## Inscription media
- Inscription images, text, HTML, audio, and video load from Universe-operated infrastructure. Inscribe does not depend on third-party explorers to show your assets.
- Thumbnails use small AVIF or WebP renders where the shared Universe media service has one. Otherwise the original bytes are shown, scaled to the tile.
- Video and audio in galleries do not download until you open them.
- Active content (HTML, scripts, SVG with scripts) always renders inside an isolated sandbox. Recursive inscriptions resolve their dependencies through the same Inscribe origin.
- The exact original bytes are never altered; derived previews are only used for display.
## Light, dark, and mobile
Every page works in light and dark themes and from 320 px phones to large desktops. Text in tables uses fixed-width digits so numbers stay aligned while they refresh.
Light and dark themes now read from the same role-based colour tokens. The old light-theme repaint sheet is gone, so changing theme updates a compact set of tokens instead of making the browser consider thousands of component overrides.
This was an intentional visual redesign, not a claim that the old appearance stayed unchanged. Contract tests and browser checks cover both themes across supported viewports, including text contrast, focus states, native controls, and layout stability.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/protocol-data-status =====
# Live protocol data status
Where live data comes from, what health means, and how order recovery works.
# Protocol data status and recovery
Universe Inscribe keeps protocol construction tools separate from live discovery data. A provider problem in one protocol does not disable unrelated pages, wallet access, or inscription workflows.
## What each state means
- **Healthy** means the configured source is reachable, on the correct network, structurally valid, and within its freshness limit.
- **Syncing** means a replacement index is being built and has not yet been promoted for production reads.
- **Stale** means the last verified generation is available but is too old to be represented as current.
- **Tip not verified** means the source answered and reported the block it reached, but the chain tip could not be read. Reads and new actions that depend on current data stay paused until the comparison is available.
- **Unavailable** means the source cannot currently provide trustworthy data. This state is never presented as an authoritative empty result.
- **Disabled by policy** means the protocol is intentionally unavailable because its production safety requirements have not been satisfied.
Empty results are shown only after a healthy source confirms that no records match the request. Retry controls repeat read-only requests and never replay mint, transfer, deploy, signing, or broadcast actions.
## Live data architecture
The production service uses independently monitored sources for OP-20, Drops and OP_DROP, ARC-20 and Atomicals, TAP on Dogecoin, BLOCK-20, ChainBloom, DUST-20, and other enabled explorers. Each source has its own liveness, readiness, freshness, network, schema, and checkpoint checks.
Bitcoin fee, transaction, address, and UTXO reads use the Universe-operated
Mempool service on the shared Indexers server. Inscription, content, Rune, and
BRC-20 reads use the private Ord service on that same server. Inscribe reaches
both services through persistent private tunnels, so node and indexer ports are
never exposed to the browser and public blockchain providers are not used as
fallbacks.
The Ord service reports the block height it has reached. `/api/health` carries
that height, the chain tip, and the difference between them for each source, so
the difference between "not answering," "answering without a readable chain
tip," and "still reading older blocks" is visible rather than inferred.
Browser fee, transaction, address, and UTXO requests stay on the Inscribe
origin. The API relays only reviewed read paths to the private Mempool service,
so wallet and payment screens never connect to an indexer or public explorer
directly.
Drops and OP_DROP additionally require two private, Universe-operated Bitcoin
Core processes to agree on the finalized block hash. If either verifier is
unavailable or disagrees, their readiness stays unavailable instead of falling
back to a public blockchain provider.
Their authoritative index also runs on a private, loopback-only MySQL 8.4 service.
Database migration is prepared beside the active service from a consistent
snapshot, verified for the complete table set and custody rules, and promoted
only with an exact release candidate. A database version label alone is never
treated as protocol readiness.
The Inscribe application database follows the same no-interruption rule. The
serving MariaDB database keeps accepting writes while a private MySQL 8.4
candidate is loaded and checked. Transactional change capture records the exact
events present in the snapshot and uses committed replay receipts, so a retry
cannot apply an acknowledged event twice. Traffic moves only after schema, row,
health, drain, and smoke checks pass.
Atomicals NFT and Realm browsing uses one unified generation so NFT, Realm, Subrealm, lookup, and resolver views agree at the same chain checkpoint. Drops and OP_DROP use one authoritative source for artifact and token state. BLOCK-20 reads are derived from a self-hosted Bitcoin Ordinals projection rather than an unbounded legacy worker.
## What you see while a source is catching up or down
The app does not reduce this to one word. When a source cannot answer:
- The banner names the source and says that everything which does not read it
is working normally. It does not claim the wait is short.
- "See what is affected" opens the service status panel. Each source shows its
state, the block it has reached against the chain tip, how many blocks behind
that leaves it, and the workspaces that read it. Sources that are answering
are listed too, so it is clear what is unaffected.
- A feature an operator switched off is listed separately from a source that is
down, because those are different problems with different fixes.
- Actions that write to the chain stay paused, and the reason names the source
and states that nothing already signed or broadcast is at risk. Reading,
drafting, and your wallet keep working.
When a source is rebuilding its index, the panel shows how fast it is reading
blocks, measured from the heights your browser has actually seen since you
opened the page, and what that pace implies for the rest. Until there is enough
measurement it says so rather than showing a completion time it cannot support.
## What the portfolio shows while a source is down
The portfolio reads several independent sources: the Bitcoin node for your
balance, the Ordinals index for inscriptions and Runes, and separate indexes
for Mezcal, SRC-20, OP_DROP and OP_RETURN names. One of them being down does
not empty the page; the rest still answer and what they report is still shown.
When a source does not answer, the portfolio names it above your holdings and
says that anything held there is missing from the page, that what is shown is
everything the sources that did answer reported, and that nothing you own has
changed. The header reads "Partial" rather than "Live" for as long as that is
true.
An empty portfolio is never presented as an answer while a source is silent.
The page says that nothing was found in the sources that answered and that this
is not a complete picture of what the address holds. "No assets found for this
address" appears only when every source answered.
This applies per source. If only the Ordinals index is behind, your Mezcal,
SRC-20 and OP_DROP balances are still real numbers from indexes that answered.
## Getting back to an order you left

Access to an order is a secret Inscribe keeps in the browser's memory and never
writes to storage. That is what stops another site reading it, and it means a
reload lets it go. Reopening an order asks your wallet to prove it owns the
order before any payment detail is shown, or accepts an encrypted recovery kit
if you saved one.
Home lists the orders this browser started under "Orders you started in this
browser", newest first, with the workflow, the order reference, and how long
ago it was recorded. Opening one takes you to its status page, where the
ownership check above runs. You can forget an entry at any time, and an order
that finishes drops off on its own.
The list is a set of references. It holds the order id, the workflow, and the
time this browser saw it. It never holds the order secret, an address, an
amount, or anything about your wallet, and it is not sent anywhere. It is kept
to the 50 most recent orders and to 30 days.
Because it cannot read an order without the secret, the list does not show a
status. It tells you the order exists and how to reach it; the status page,
after the ownership check, tells you where the order stands.
An order started before this list existed still appears, because its reference
was already in the browser. Those entries carry no time and say so rather than
showing an age that would be wrong.
## When a release lands while your tab is open
Every screen in Inscribe loads as its own file, and a release replaces those
files. A tab that has been open across a release asks for a file that is no
longer on the server, and the screen you clicked does not open.
Inscribe recognises that and says so, rather than reporting a crash: a new
version was released, reload to fetch it. A dropped connection produces the
same failure and the same fix, so the message covers both.
Nothing you started is lost by the reload. The orders this browser recorded are
listed on Home when it comes back, and your wallet reconnects the way it did
before. Reopening an order still asks your wallet to prove it owns the order,
as it does after any reload, because the order secret is only ever held in
memory.
## Safety gates
Some research protocols remain visible for documentation or controlled-network work while production actions stay disabled. Universe does not turn these features on merely to make a status page appear healthy. Mainnet writes require the protocol's network profile, independent authorization, authoritative index, transaction safety checks, and a verified readiness canary.
CAT-20 transaction features remain fail-closed when the required Fractal data and signing dependencies are unavailable. Market discovery reports that dependency state directly instead of returning a misleading empty market.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/release-evidence =====
# Release evidence
Immutable images, verified revisions, and browser route validation.
# Verified release artifacts
Inscribe releases use immutable backend and frontend container images. Before an artifact can be published, the release process verifies the exact source revision, the supported Node.js and Docker runtimes, production configuration, and the completed CI evidence for that same revision. Artifact builds run only on a qualified runner whose Docker engine matches the supported version.
If a required validation fails, no release artifact is published and no partial evidence is presented as a release. This keeps an incomplete build from being mistaken for a deployable version.
Release evidence includes image identities, dependency inventories, and checks that the production artifact matches the approved source. It is designed to make a release traceable without exposing credentials or customer data.
Production browser route validation builds with the same reviewed feature
profile as the release artifact. This ensures that production-enabled routes,
including Drops and OP-DROP, are tested in their enabled state before a release
is promoted.
Browser route validation also treats an already-dismissed consent choice as the
successful state. A consent control that disappears while the test is
interacting with it does not block release evidence, while a control that
remains visible after an interaction error still fails the validation.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/social-previews =====
# Social previews
Route-aware preview images and the noindex rules for private surfaces.
# Route-aware link previews
Universe Inscribe gives every public, shareable destination a designed large-card preview. The title, description, authoritative URL, visual family, and image identify the page being shared instead of repeating a generic Bitcoin logo.
## What a shared link includes
- The real section, protocol, tool, or public asset name.
- A concise description of the destination.
- An authoritative URL that identifies that page or asset.
- A 1200 × 630 image from the appropriate Universe Inscribe visual family.
- Matching Open Graph and X metadata for social and messaging clients.
Public token and asset pages use safe public identity data when it is available. Their card remains specific to the entity even when the public profile service is temporarily unavailable.
## Privacy
Portfolio, Watchlist, Activity, order, payment-recovery, wallet, and other user-specific views suppress social images and use `noindex,nofollow`. A preview never contains a wallet address, balance, session, account, order payload, or draft transaction.
## Stable previews and updates
An unchanged page keeps the same deterministic image URL. A material route, profile, or renderer change creates a new content-addressed URL so social caches can retrieve the new design without random cache busting.
The public preview check also tolerates brief network or gateway interruptions. It retries a timed-out request or a temporary gateway response before reporting a failure, while still reporting invalid metadata, privacy mistakes, unavailable pages, and incorrect images immediately.
## Sharing a page
Copy the full authoritative URL from the browser and paste it into the destination app. Public sections, tools, and supported public entity pages can be shared directly. Private surfaces intentionally display neutral or suppressed previews.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/reference/wallets =====
# Wallet matrix
The five wallets Inscribe connects to, what each supports, their known limitations, and the rule about which address is used for what.
Inscribe connects to five wallets. All five are production integrations, not previews.
## The matrix
| Wallet | Coverage | Addresses exposed | Known limitations |
| --- | --- | --- | --- |
| **Universe** | The Bitcoin Universe wallet | Payment and Ordinals | None recorded |
| **UniSat** | Ordinals, BRC-20, Runes | Payment and Taproot | A session is dropped rather than revived from memory if the extension cannot confirm a live active account |
| **Xverse** | Ordinals, Stamps, Runes | Payment and Ordinals, declared explicitly | None recorded |
| **OKX** | Multi-chain | Payment and Ordinals where the provider exposes them | Address availability depends on what the provider exposes |
| **Wizz** | Bitcoin, Ordinals, Atomicals, Runes | **One active address only** | Mobile support varies by version. An optional operation an installed version does not support fails rather than doing something else |
If Universe Wallet is not installed, its install action and the `/wallet` shortcut open the
reviewed browser-store listing.
## The two limitations worth planning around
**Wizz exposes a single active address.** Inscribe does not invent a second one to fill the
gap. A flow that genuinely needs two distinct addresses, one to pay from and one to receive
at, behaves differently here. If you want the payment and receiving roles separated, use a
wallet that exposes both.
**UniSat sessions are not revived from memory.** If the extension cannot confirm a live
active account, Inscribe drops the session rather than trusting a stored address. You
reconnect. The upside is that you never act against an address the wallet has not just
confirmed.
## How addresses are assigned
By address form. A Taproot address, one starting `bc1p` on mainnet, is treated as the
Ordinals address, because that is where inscriptions live.
When a wallet exposes only one address, that address is used for both jobs, and Inscribe
does not pretend otherwise.
The rule the product holds itself to:
> Payment addresses fund orders. Destination and recipient addresses receive assets. A
> wallet adapter must not silently substitute one for the other.
## How many signatures to expect
| Flow | Signatures |
| --- | --- |
| A typical inscription, deploy, mint or etch | **One.** The payment to the commit address |
| Parent and child | **Two.** The commit payment, then the reveal spending your parent |
| Bring your own satoshi | **Two.** Two addresses funded |
| ARC-20 | A direct transaction to sign, with no payment-address step |
| SRC-20 | Your wallet signs pre-built transactions |
| TAP transfer | Two steps by protocol design |
For the parent flow, the prepared transaction is good for **15 minutes**. If the window
lapses the order asks again rather than losing anything.
## What connecting does and does not do
Connecting shares your addresses. It does not authorise spending.
You do not need to connect at all to browse workspaces, read live protocol data, price an
action, inspect any address in **Explore**, or track addresses in **Watchlist**.
The wallet chooser keeps network, retry and diagnostic controls under **Connection
options**, so the first choice stays focused on picking a wallet.
## What your wallet controls that Inscribe cannot
When you send bitcoin from your wallet own send screen, **your wallet chooses which outputs
to spend**. Inscribe scans the paying address first and lists any outputs holding assets,
then gets out of the way.
It does not block you, because the wallet owns the selection and you may have a good reason.
Read [asset safety](/docs-inscribe/concepts/asset-safety/).
## Related
- [Wallets and the two addresses](/docs-inscribe/concepts/wallets-and-addresses/)
- [Your first inscription](/docs-inscribe/start/first-inscription/)
- [Asset safety](/docs-inscribe/concepts/asset-safety/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/safety/asset-safety =====
# Asset and UTXO safety
How Inscribe protects asset-bearing outputs, and the checks to run before every signature.
# Asset safety
Inscribe will not pay a fee with an output that holds your assets.
## Why this matters
Bitcoin spends an output whole. An output holding an inscription, a Rune balance
or a token balance looks the same as ordinary bitcoin to software that only
checks the amount. If a tool picks that output to cover a network fee, the asset
goes with it, and there is no way back.
This is not a rare edge case. Trust Wallet dropped inscription support in March
2026 and warned its users that bitcoin sent from an address holding inscribed
outputs could spend those outputs by accident.
## What Inscribe does
Every Inscribe flow that chooses funding outputs for you asks the Universe asset
index what each output holds before it picks anything.
- An output the index reports as holding an inscription, a Rune balance or a
token balance is never used to pay a fee.
- An output the index confirms is plain bitcoin is used first.
- An output the index cannot classify is used only after the confirmed ones.
This covers ChainBloom, Drop transfers, OP_DROP funding and settlement, OP_DROP
ownership proofs, Patina commits, and inscription transfers.
Nothing here stops you from spending an asset-bearing output on purpose. It
stops Inscribe from doing it on your behalf.
## When funding is short
If Inscribe holds outputs back and the remaining balance cannot cover the
action, it tells you how many outputs were held back, how many sats they hold,
and why. You are never told to add bitcoin you already have.
To free the balance, send plain bitcoin to the address, or lower the fee rate.
## Choosing outputs yourself
Two surfaces let you pick outputs directly and show the asset report for each
one before you sign:
- **Split UTXO** shows a full asset preflight report per output.
- **Custom transaction** lists your outputs with their asset classification.
## What Inscribe does not claim
Inscribe reports what the Universe asset index knows. Where the index has no
answer for an output, Inscribe says so rather than calling the output safe.
Coverage improves as the index does, and the flows above use confirmed outputs
ahead of unconfirmed ones automatically.
When you send bitcoin through your wallet's own send screen, your wallet chooses
the outputs, not Inscribe. Inscribe shows a warning where it can see a risk, but
it cannot change that selection.
### The warning before a wallet payment
Immediately before your wallet opens, Inscribe scans the address the payment
will come from and lists any outputs that hold assets:
> **The address you are paying from holds assets.** Your wallet chooses which
> outputs pay for this. If it spends one of these, the asset it carries goes
> with it, and Inscribe cannot bring it back. Pay from an address that holds
> only bitcoin, or pick the inputs yourself in your wallet before you approve.
It lists the outpoint and what each output carries. It does not stop you. The
wallet owns the selection, you may have a good reason to pay from that address,
and an app that blocked you would be wrong more often than it was right.
Only outputs the index positively identified appear. An output with an
incomplete, stale, or out-of-network scan is not listed, and is also never
picked automatically by the flows above.
## A note on addresses

An Ordinals wallet keeps two addresses: a payment address for spendable bitcoin
and a Taproot Ordinals address for inscriptions, Runes and token balances.
Inscribe reads both when it shows your holdings, and a transfer is signed from
the address that actually holds the balance you are sending.
The bitcoin balance card still reports the payment address on its own. Sats sitting
at an Ordinals address are not spendable from there, and adding them together
would tell you that you can spend money you cannot.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/safety/order-recovery =====
# Order recovery
What can interrupt an order, what each state means, and the exact next action for every one of them.
## Orders are recoverable states, not gambles
An order moves through known stages, and each stage has a documented recovery path. The [Recovery Navigator](/recovery/navigator/) walks you to the right one; this page is the reference behind it.
## The rules that never bend
1. **Never pay twice on a hunch.** An absent result is not a zero. Payment detection catches up after confirmations.
2. **Top up the difference, never repeat the total.** When an order shows an underpayment with a top-up action, pay exactly the displayed difference.
3. **A confirmed transaction is final.** No operator, no support agent, and no service can reverse one.
4. **Never publish a recovery capability.** The encrypted recovery kit stays on your disk. Nobody legitimate will ask for it.
5. **Do not act on stale data.** When the live status page reports a source as stale or unavailable, wait for healthy before paying or repairing.
## The states
- **Unpaid, quote current.** Pay the exact quoted total before the timer ends.
- **Quote expired before payment.** Request a fresh quote. The old amount is invalid.
- **Payment sent, not detected.** Wait one confirmation window and reload the order page. Save the transaction id.
- **Underpayment with a top-up action.** Pay the exact difference the order displays.
- **Underpayment without a repair action.** Stop. Gather evidence and open a support request.
- **Overpayment.** Let the order complete, then follow the refund path with your evidence.
- **Payment stuck unconfirmed.** Bump the fee with replace-by-fee if your wallet supports it, or wait. Do not broadcast a duplicate.
- **Your own transaction stuck.** Use the tx replace workspace to bump it.
- **Reveal failed.** Retry the reveal from the order page. The paid commit still belongs to this order.
- **Order access lost.** Check the browser order list first, then restore the order URL from your encrypted recovery kit.
- **Padding satoshis.** Recover them from the recover-sats workspace with the same wallet and network.
- **Signed to the wrong address.** A confirmed transaction cannot be reversed. If the destination was your own address elsewhere, recover it there. Otherwise the amount is lost, and the pre-sign checklist is the lesson.
## Evidence to keep
For anything you cannot resolve in the app, keep the order URL, the payment transaction id, the quoted and paid amounts, and the order page screenshots. The recovery and support paths all start from that evidence, and none of it is secret: none of it includes your seed phrase, keys, or recovery kit, which should never leave your device.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-02
===== inscribe-docs/start/before-you-spend =====
# Before you spend anything
The four ways people lose Bitcoin-native assets, what Inscribe does about each, and the two minutes of reading that prevent most of them.
Everything on this page is about one property of Bitcoin: **a transaction that confirms
cannot be undone.** No support request, no operator, and no part of Inscribe can reverse
one. That is what makes the minutes before you sign the ones that matter.
## 1. Paying a fee with an asset
**How it happens.** Bitcoin spends an output whole. An output holding an inscription or a
token balance looks exactly like ordinary bitcoin to software that only checks the amount.
Pick it to cover a fee and the asset goes with the change.
**What Inscribe does.** No automatic funding flow picks an output holding an inscription,
Rune or token balance. Outputs proven to be plain bitcoin are used first; outputs nothing
could be established about are used only after those; outputs with a detected asset are
not used at all.
**What it cannot do.** When you send from your wallet's own send screen, your wallet picks
the outputs. Inscribe warns you and lists what is at risk, then gets out of the way,
because it cannot change that selection.
**What you do.** Fund orders from an address holding only bitcoin where you can. If you
see the warning before your wallet opens, read it rather than clicking through it.
[Asset safety in full](/docs-inscribe/concepts/asset-safety/).
## 2. Confusing the two addresses
**How it happens.** Your wallet has a payment address for spendable bitcoin and a Taproot
Ordinals address for what you own. Sending an asset to the wrong one, or expecting to
spend the satoshis sitting under your inscriptions, both come from treating them as one
balance.
**What Inscribe does.** It reads both, keeps them apart, never adds the two balances
together, and signs each action from the address that actually holds what it moves.
**What you do.** Check the receiving address on the confirmation screen. It is named
there for this reason.
[Wallets and the two addresses](/docs-inscribe/concepts/wallets-and-addresses/).
## 3. Not reading the total
**How it happens.** A quote has three lines and only two of them are fees. People compare
the wrong number, or assume a bigger file costs the same as a small one.
**What Inscribe does.** It itemises the network fee, the service fee and the inscription
output, totals them, and shows that total before your wallet opens. The wallet is then
asked for exactly that amount.
**What you do.** Compare the amount in your wallet's send screen against the Total Cost
you just read. If they differ, reject it.
[What a transaction costs](/docs-inscribe/concepts/what-it-costs/).
## 4. Paying twice
**How it happens.** A payment does not seem to register, so it gets sent again. Now two
payments exist and only one is the order.
**What Inscribe does.** It watches the commit address every ten seconds and accepts an
unconfirmed payment, so the usual cause is impatience rather than a lost payment. If
several payments land, it uses the one matching the quote, or the smallest that covers it,
specifically so an accidental second payment is not swallowed. Overpayment is returned to
the address that funded the order where it is large enough to send back.
**What you do.** Never pay a second time to fix a first. Go to
[recovery routes](/docs-inscribe/manage/recovery/).
## Three things that are not emergencies
- **The status still says "in progress" after your transaction confirmed.** That is
correct. Inscribe waits for the indexer and your wallet to agree before it calls an
order done.
- **You closed the tab.** The work continues without your browser. Home lists the orders
this browser started.
- **The hour ran out.** That hour is the life of the price quote, not the life of the
order. Nothing is cancelled and no key is discarded.
## Two things that genuinely need action
- **Your payment is not confirming.** The fee rate is too low for current conditions. Use
**Fix My Payment** or **Bump Stuck TX**.
- **You sent less than the quote.** Top the same address up to the quoted amount.
## The one thing with no recovery route
A transaction you signed and broadcast that did what you told it to. If you deliberately
spent an asset-bearing output in the Advanced TX Builder, or approved a wallet send from
an address holding assets after being warned, the result is final. The fee is spent and
the asset has moved.
Everything else on this site has a route back. That one does not.
## Related
- [Your first inscription](/docs-inscribe/start/first-inscription/)
- [Recovery routes](/docs-inscribe/manage/recovery/)
- [Common problems](/docs-inscribe/troubleshooting/common-problems/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/start/first-inscription =====
# Your first inscription
A complete walkthrough of inscribing a file or a line of text, from connecting a wallet to seeing the result, with the wallet screen to expect and how to verify what happened.
**Who this is for.** Anyone who has never inscribed anything. No prior Ordinals knowledge
is assumed.
**Goal.** One inscription on Bitcoin mainnet, held at an address you control, that you can
verify independently.
## Before you start
| Requirement | Detail |
| --- | --- |
| Chain and network | Bitcoin mainnet. Real money |
| Protocol | Ordinals. Released, ungated, covered by the release health contract |
| Wallet | One of Universe, UniSat, Xverse, OKX, Wizz |
| Funds | Spendable bitcoin at your **payment address**. Budget a few thousand satoshis plus the network fee |
| Time | A few minutes to sign, then up to an hour or so for confirmation at a normal fee rate |
| Reversible? | **No.** Once you sign, the fee is spent whatever the outcome |
Read [what a transaction costs](/docs-inscribe/concepts/what-it-costs/) first if you have
not. You will be shown a total before you sign, and it helps to know what the three lines
mean.
### Safety considerations
- **Fund from an address holding only bitcoin** where you can. If the payment address also
holds inscriptions or token balances, your wallet picks which outputs to spend, and
Inscribe cannot override that choice. It will warn you before opening the wallet.
- **Check the content preview.** What the preview shows is what gets written. There is no
edit afterwards.
- **Do not pay twice.** If a payment seems not to register, go to
[recovery routes](/docs-inscribe/manage/recovery/) rather than sending again.
## Steps
**Open the Inscribe workspace.**
Go to [inscribe.bitcoinuniverse.io](https://inscribe.bitcoinuniverse.io) and open
**Inscribe** from the sidebar, or go straight to `/inscribe`. The command palette,
`Ctrl` + `K` (`Cmd` + `K` on macOS), reaches it by name.
The workspace opens on the **Text** sub-tab. The other sub-tabs are Files, Names,
Parent/Child, Delegate, Gallery, Stamps and Data Lab.
**Connect a wallet.**
Click **Connect** and pick your wallet. Your wallet asks for permission to share your
addresses; approve it. This is a read permission, not a spending one.
*Expected wallet screen:* a connection prompt naming the site and listing the accounts it
will share. No amount appears, because nothing is being spent yet.
Once connected, Inscribe holds two addresses from your wallet: a **payment address** for
spendable bitcoin and an **Ordinals address** for what you own. If your wallet exposes
only one address, that one does both jobs.
**Choose what to inscribe.**
*For text:* type or paste into the box on the **Text** tab. One line is fine.
*For a file:* switch to **Files** and drop a file in, or pick one. Accepted types are JPG,
JPEG, PNG, WEBP, GIF, SVG, TXT, HTML, JSON, MP3 and MP4. The maximum is **4 MB**, and the
file's extension has to match its actual type or it is rejected.
Larger files cost more, because the network fee is the fee rate times the size of the
transaction. Start small.
**Check the preview.**
The preview shows exactly what will be written to the chain. Read it now. After you sign,
this is what exists.
**Set the fee rate and the output size.**
Pick a fee tier. **Normal** is selected for you and is marked Recommended; it targets the
blocks mined over roughly the next half hour. **Fast** targets the next block. **Custom**
takes any rate you type.
If Normal and Fast show the same rate, that is not a bug: blocks have room, and the two
tiers are the same purchase. The app says so on both tiers.
Leave the inscription output at **546 sats** unless you have a reason not to. It is not a
fee: it is the satoshi your inscription will sit on, and you keep it.
**Read the confirmation screen.**
This is the last point at which the choice is still yours. It shows:
| Line | What it is |
| --- | --- |
| Operation Type | What you are about to do |
| Network Fee Rate | The rate you picked |
| Network Gas Fee | Rate times transaction size, paid to miners |
| Service Fee | A flat 1,500 sats |
| Mint UTXO Value | The 546 sats your inscription sits on, which stays yours |
| Total Cost | The amount your wallet will be asked to spend |
It also names the receiving address. Check it is yours.
If the address you are paying from holds assets, a warning appears here listing them. It
does not block you. Read [asset safety](/docs-inscribe/concepts/asset-safety/) if you see
it.
**Confirm and pay.**
Press **CONFIRM & PAY**. Inscribe creates the order and asks your wallet to send the
total to a one-time commit address it generated for this order alone.
*Expected wallet screen:* a normal send. One recipient, which is the commit address; the
amount, which is the total from the previous step; and the fee rate you chose. Compare the
amount against the Total Cost you just read. If it does not match, reject it.
**This is your only signature.** The second transaction, the one that actually writes your
content, is signed by the order's own key rather than by you.
**Wait.**
You land on the order status page. What happens next needs nothing from you:
- Universe checks the commit address every ten seconds. An unconfirmed payment is enough;
it does not wait for a confirmation.
- It builds and broadcasts the reveal transaction, which carries your content.
- A miner confirms the reveal.
- The indexer reads it and your wallet reports it.
The status stays **Creation in progress** through all of that, and only moves to **Wallet
visible** when the indexer and your wallet agree the inscription exists. That is
deliberate: a broadcast is not a result.
**You can close the tab.** The work continues without your browser. See
[orders you started](/docs-inscribe/manage/pending-orders/) for how to get back.
**Verify it.**
Three checks, from weakest to strongest:
1. The order page shows **Wallet visible** and gives you the reveal transaction id.
2. **Portfolio** lists the inscription under your connected wallet.
3. Paste your Ordinals address into **Explore**, or the transaction id into any Bitcoin
explorer, and confirm the output exists and is at your address.
The third is the one that does not depend on Inscribe being right.
## Expected result
An inscription held at your Ordinals address, on a 546-satoshi output, with a reveal
transaction id you can look up anywhere. Your payment address is lighter by the total you
approved.
## Common failure states
| What you see | What it means | What to do |
| --- | --- | --- |
| **Awaiting payment**, and you did pay | The payment has not appeared at the commit address yet, or it went somewhere else | Wait a few minutes. Then check the transaction actually went to the commit address. Do not pay again |
| Payment below the quote | You sent less than the total | Top the same address up to the quoted amount. The flow resumes |
| The hour ran out | The price quote expired | Start a new order at a current price. If you already paid, do not pay again, see recovery |
| The payment is not confirming | Your fee rate was too low for current conditions | Use **Fix My Payment** or **Bump Stuck TX**. See [recovery routes](/docs-inscribe/manage/recovery/) |
| A source is unavailable | An index the workspace reads is down or catching up | Reading and drafting keep working. Writes stay paused, and nothing already signed is at risk |
| The screen you clicked does not open | A release landed while your tab was open | Reload. Nothing you started is lost |
## Recovery route
If anything goes wrong after you have paid, the order is not lost and the signing key is
not discarded. Start at [recovery routes](/docs-inscribe/manage/recovery/), which covers
unpaid orders, underpayment, stuck payments, closed tabs and failed reveals.
## Related
- [What a transaction costs](/docs-inscribe/concepts/what-it-costs/)
- [The life of an order](/docs-inscribe/concepts/order-lifecycle/)
- [Inscribe a file](/docs-inscribe/create/inscribe-a-file/), with the per-protocol limits
- [Inscribe in a batch](/docs-inscribe/create/batch/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/start/what-inscribe-is =====
# What Inscribe is
What Universe Inscribe does, who it is for, how it relates to Core and the rest of Bitcoin Universe, and what it deliberately does not do.
Inscribe is one workspace for creating, minting, managing and recovering Bitcoin-native
assets, from a first inscription to advanced transaction construction.
## What you can do with it
- **Create inscriptions** from text or files, one at a time or in batches, with the full
cost laid out for review before you sign.
- **Deploy, mint and transfer tokens** across the protocols Inscribe implements: BRC-20,
SRC-20, TAP, BLOCK-20, DUST-20, OP-20, OP_DROP, ARC-20 and others.
- **Etch and mint runes**, and split a rune balance across outputs.
- **Register names**, including `.sats` and `.btc` domains through SRC-101 and OP Names.
- **See everything an address holds** in one portfolio that separates spendable bitcoin
from asset-bearing satoshis.
- **Build, split and repair transactions** with per-output asset classification before you
sign.
- **Recover satoshis** locked in inscription padding, and get back to orders your browser
started even after closing the tab.
The full list is in the [coverage matrix](/docs-inscribe/protocols/coverage/) and the
[workspace map](/docs-inscribe/reference/workspaces/).
## Who it is for
- **People making their first inscription.** Start at
[your first inscription](/docs-inscribe/start/first-inscription/).
- **People launching a token or a collection.** Start at
[deploy a token](/docs-inscribe/create/deploy-a-token/) or
[create a collection](/docs-inscribe/create/collections/).
- **People who already hold assets** and need to move, split or rescue them. Start at
[advanced transaction tools](/docs-inscribe/manage/advanced-transactions/).
You do not need to connect a wallet to explore the app, read live protocol data, or
understand what anything costs. A wallet is asked for only when an action needs a
signature.
## How it fits with the rest of Bitcoin Universe
Bitcoin Universe has a creation half and a trading half.
| Question | Inscribe | Core |
| --- | --- | --- |
| What it is for | Making assets | Discovering and trading them |
| This site covers | Yes | No, see the central platform |
**These are independent.** A protocol you can create in Inscribe may not be tradeable in
Core, and a protocol that trades in Core may have no creation workspace here. The coverage
matrix on this site describes creation only, and it never borrows marketplace availability
to imply something about creation. Of the 27 protocols with a creation surface, the
registry records marketplace availability ranging from enabled through read-only to
feature-gated, and none of that changes what you can make.
The central platform is at
[docs.bitcoinuniverse.io](https://docs.bitcoinuniverse.io).
## What the product promises
- **Your assets are not fee fuel.** No automatic funding flow picks an output holding an
inscription, Rune or token balance to pay a network fee.
[How that works](/docs-inscribe/concepts/asset-safety/).
- **A source being down is never shown as an empty wallet.** Every read names its source,
and the app tells you which source did not answer instead of showing you nothing.
[The six data states](/docs-inscribe/concepts/source-freshness/).
- **Costs are shown before the wallet opens.** Itemised, then totalled.
[Read a quote](/docs-inscribe/concepts/what-it-costs/).
- **Universe-operated infrastructure.** Blockchain reads come from Universe-owned nodes
and indexes, not public third-party APIs, so the data path is accountable end to end.
- **Verifiable releases.** Every production release is built from an exact commit with
recorded evidence, and the footer of every page names the build you are looking at.
[Release evidence](/docs-inscribe/about/release-evidence/).
## What it deliberately does not do
- **It does not claim success at broadcast.** An order stays "in progress" until the
indexer and your wallet agree the asset exists.
- **It does not treat unknown as safe.** An output whose contents could not be established
is reported as unverified, never as clear.
- **It does not fall back to public explorers.** If the private source cannot answer, the
app says so rather than quietly asking someone else.
- **It does not block you from spending your own assets on purpose.** One surface, the
Advanced TX Builder, lets you spend an asset-bearing output deliberately. It labels them
and leaves the choice to you.
- **It does not hold your assets.** Nothing is custodial. Your wallet signs what moves your
money, and the one key Inscribe holds exists for a single order and is scoped to
completing it.
## Language
The interface is available in English and Chinese. The Chinese catalogue does not yet
cover every string, and falls back to English where it does not.
## Related
- [Before you spend anything](/docs-inscribe/start/before-you-spend/)
- [Status and lifecycle](/docs-inscribe/start/status/)
- [Workspace map](/docs-inscribe/reference/workspaces/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/start/what-you-can-create =====
# What you can create
Inscribe puts Bitcoin creation in one place. Start with a guided plan, practice without spending, then make the real thing.
## Create on Bitcoin
Inscribe is the creation studio of the Bitcoin Universe ecosystem. From one app you can:
- **Inscribe text and files** onto satoshis, one at a time or in batches.
- **Create collections** with parents, delegates, and galleries.
- **Deploy, mint, and transfer tokens** across the protocols the app supports.
- **Etch Runes** and publish plain data with OP_RETURN.
- **Move assets** with transaction-level review before every signature.
## Three ways in
1. **Plan it.** The [Guided planner](/docs-inscribe/guided/) asks what you want to make and returns an evidence-backed plan: the workflow, the protocol, the stages, the costs, and the safety checks. Every recommendation names the rule that selected it.
2. **Practice it.** The [Practice Studio](/docs-inscribe/practice/) runs the real Inscribe interface against deterministic fixtures. No wallet, no network, no transactions: a simulation that cannot spend anything.
3. **Do it.** Every plan and every guide ends with a safe handoff into the live workspace, where the app still shows its own review and confirmation flow.
## Know before you sign
Two facts govern every workflow. First, Bitcoin transactions are irreversible: a confirmed payment cannot be undone by anyone. Second, a fee and your money are different things: the [cost anatomy](/docs-inscribe/create/what-it-costs/) separates the network fee, the service fee, and the output value that stays owned by you.
## If something goes wrong
The [Recovery Navigator](/recovery/navigator/) turns your situation into a diagnosis with a next action, and the [recovery guide](/safety/order-recovery/) holds the full detail. Neither will ever tell you to publish a secret or to trust anyone who claims they can reverse a confirmed transaction.
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-02
===== inscribe-docs/troubleshooting/common-problems =====
# Common problems
The problems people actually hit in Inscribe, what each one means, and the shortest route to a fix. Ordered by how often they come up.
If you have paid and something is wrong, go straight to
[recovery routes](/docs-inscribe/manage/recovery/). This page is the wider list.
**The rule that applies to most of these: do not pay again.**
## Payment and orders
### I paid but it still says awaiting payment
Wait two minutes. The commit address is checked every ten seconds and an unconfirmed
payment is enough, so a payment that is genuinely there usually appears quickly.
Then check on an explorer that your payment went to the commit address the order gave you.
A payment to a different address is a different problem.
[Full steps](/docs-inscribe/manage/recovery/#payment-not-detected).
### I sent less than the quote
Top the same commit address up to the quoted amount. The flow resumes on its own. Nothing
is cancelled.
### I sent more than the quote
The surplus comes back automatically in the reveal transaction, provided it is big enough
to cover the extra bytes and still clear the dust threshold. If it is not, it is added to
your inscription output, where you still own it.
### My transaction is not confirming
The fee rate was too low for conditions. Two tools:
- **Fix My Payment** at `/fix-payment`, when the stuck transaction is your payment to a
commit address.
- **Bump Stuck TX**, for any transaction of yours, comparing RBF against CPFP.
Neither charges a service fee.
### The hour ran out
That hour is the life of the price quote, not the order. If you have not paid, start a fresh
order at a current price. If you have paid, do not pay again: the address keeps being
checked and a late payment is still found.
### I closed the tab and cannot find my order
Go to Home. Orders this browser started are listed under "Orders you started in this
browser". Opening one asks your wallet to prove it owns the order.
[The four routes back](/docs-inscribe/manage/recovery/#you-lost-the-order).
### It has said "in progress" for a long time after confirming
That is correct behaviour, not a stall. Inscribe waits for the indexer and your wallet to
agree the asset exists before it calls an order done.
If the indexer is behind, the service status panel says so and gives you the height it has
reached against the chain tip.
## Money and fees
### Normal and Fast show the same price
Expected. Either blocks have room, or the protocol rounds to whole satoshis, or a protocol
minimum lifted both. Two prices that are the same number are the same purchase, and the app
says so on both tiers rather than selling one as faster.
### It says "Cached fees"
The rate source is not answering, so the number in front of you is not fresh. It is shown as
stale rather than presented as live. Wait for it to recover before committing to a rate that
matters.
### The total is more than I expected
Check which of the three lines grew. The network fee scales with the size of what you are
inscribing; the service fee is flat; the inscription output is not a fee at all and stays
yours.
[Read a quote](/docs-inscribe/concepts/what-it-costs/).
### Inscribe says I do not have enough bitcoin, but I do
Outputs holding assets were held back from fee funding. The message tells you how many
outputs were withheld and how many satoshis they hold.
Send plain bitcoin to your payment address, or lower the fee rate.
## Assets and wallets
### My portfolio looks empty or incomplete
Check the header. If it reads **Partial**, at least one source did not answer, and the page
names which one. Nothing you own has changed.
"No assets found for this address" appears only when every source answered.
### My wallet will not stay connected
If you use UniSat, sessions are dropped rather than revived when the extension cannot
confirm a live active account. Reconnect. This is deliberate: you never act against an
address the wallet has not just confirmed.
### A flow behaves oddly with Wizz
Wizz exposes a single active address. A flow that needs two distinct addresses behaves
differently, and Inscribe does not invent a second address to fill the gap.
### I got a warning that my address holds assets
Your wallet, not Inscribe, chooses which outputs pay for a wallet send. The warning lists
what is at risk and then lets you proceed.
Pay from an address holding only bitcoin, or pick the inputs yourself in your wallet before
approving.
## The app itself
### The screen I clicked will not open
A release landed while your tab was open, or your connection dropped. Both produce the same
failure and the same fix.
**Reload.** Nothing you started is lost. Your orders are listed on Home and your wallet
reconnects.
### A workspace is visible but refuses to act
Its release gate is off in this deployment. It is not a fault you can clear, and the
workspace stays visible on purpose so a switched-off feature does not look like a feature
that never existed.
[Which workspaces are gated](/docs-inscribe/start/status/).
### I got a 404 on Recover Sats or the Dogecoin BlockPad
Those are the only two surfaces that return the 404 page when their feature is switched off,
rather than loading and refusing. A 404 there is a switched-off feature, not a broken link.
### Text is too small, or contrast is poor
Settings carries display controls: High contrast, Large text, Reduced motion, Density,
Enhanced focus rings, Screenshot safe, and Colour-blind safe.
[Accessibility](/docs-inscribe/about/accessibility/).
## Things that are not problems
| What you see | Why it is fine |
| --- | --- |
| "Creation in progress" after confirmation | Inscribe waits for indexer and wallet evidence |
| Two fee tiers at the same price | They are the same purchase |
| An order with no age on Home | It predates the list, and says so rather than showing a wrong age |
| A workspace showing Degraded | Reads still work; the page names what is missing |
| An output marked Unclassified | Recognised as present but not placeable. Shown rather than dropped |
## Still stuck
[Open an issue](https://github.com/bitcoinuniverseio/docs-inscribe/issues). Say what you
were doing, what you expected, and what you saw. If it is an accessibility barrier, say what
you browse with; that is more useful than a rule number.
## Related
- [Recovery routes](/docs-inscribe/manage/recovery/)
- [Failure states](/docs-inscribe/troubleshooting/failure-states/)
- [Before you spend anything](/docs-inscribe/start/before-you-spend/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01
===== inscribe-docs/troubleshooting/failure-states =====
# Failure states
Every way Inscribe reports that something is wrong, what each state blocks, what keeps working, and how to tell a switched-off feature from a broken one.
A reference for reading what Inscribe is telling you. For fixes, see
[common problems](/docs-inscribe/troubleshooting/common-problems/).
## The distinction that matters most
Three different things look similar on screen and have entirely different fixes:
| It looks like | It actually is | What fixes it |
| --- | --- | --- |
| A workspace that will not act | Its release gate is off in this deployment | Nothing you can do. It is not broken |
| A workspace that will not act | Its data source is down or catching up | Waiting. The panel says how far behind |
| A workspace that will not act | The protocol is not released | Nothing. The work is unfinished |
Inscribe reports these separately rather than collapsing them into one word, because they
are different problems.
## Data source states
A source is in exactly one of six states:
| State | What it blocks |
| --- | --- |
| **Live** | Nothing |
| **Live, currency unverified** | Nothing directly, but how current it is cannot be checked |
| **Tip not verified** | Reads and new actions depending on current data, until the comparison is available |
| **Behind** | Depends on how far. The panel gives the height and the gap |
| **Unavailable** | Reads from that source. Never shown as an empty result |
| **Unknown** | Treated as not usable |
Separately: **switched off by the operator** is reported as its own thing, not as a source
being down.
## What a source outage does and does not stop
**Keeps working:**
- reading and drafting;
- your wallet connection;
- every workspace that does not read the affected source;
- anything already signed or broadcast, which is never at risk.
**Pauses:**
- actions that write to the chain in the affected workspace, with the reason naming the
source.
The banner names the source and says that everything which does not read it is working
normally. It does not claim the wait will be short.
**See what is affected** opens the service status panel: each source with its state, the
block it has reached against the chain tip, the gap, and the workspaces that read it.
Sources that are answering are listed too, so what is unaffected is clear.
## Portfolio failure states
| Header | Meaning |
| --- | --- |
| **Live** | Every source answered |
| **Partial** | At least one did not. The page names it and says what is missing |
An empty portfolio is never presented as an answer while a source is silent. "No assets
found for this address" appears only when every source answered.
## Order failure states
| State | Meaning | Action |
| --- | --- | --- |
| **Awaiting payment** past the hour | The quote expired. The order did not | Start fresh if unpaid. If paid, see recovery |
| Payment below the quote | Underpaid | Top up the same address |
| **Failed** | Needs attention | [Recovery routes](/docs-inscribe/manage/recovery/) |
| A reveal that will not broadcast | Retried automatically with backoff from 30 seconds | Nothing. The same signed transaction is resent, never a new one |
There is no cancelled or expired order state, and a signing key is never discarded because a
provider timed out, a lookup returned nothing, a retry limit was reached, or an hour passed.
## Application failure states
### A release landed under your tab
Every screen loads as its own file, and a release replaces those files. A tab open across a
release asks for a file that is no longer there.
Inscribe recognises this and says a new version was released, offering reload as the primary
action. A dropped connection produces the same failure and the same fix, so the message
covers both rather than guessing.
Nothing you started is lost by the reload.
### A 404 where you expected a workspace
Two surfaces return the 404 page when their feature is off rather than loading and refusing:
**Recover Sats** and the **Dogecoin BlockPad**. Everywhere else, a gated workspace loads.
## Protocol-specific failure behaviour
| Protocol | Behaviour |
| --- | --- |
| **CAT-20** | Transaction features stay fail-closed when Fractal data and signing dependencies are unavailable. Market discovery reports the dependency state instead of an empty market |
| **Drops and OP_DROP** | Require two independent verifiers to agree on the finalized block hash. Disagreement or unavailability keeps readiness unavailable rather than falling back to a public provider |
| **Research protocols** | Stay visible for documentation or controlled-network work while production actions stay disabled |
Mainnet writes require the protocol network profile, independent authorization, an
authoritative index, transaction safety checks, and a verified readiness canary. Universe
does not switch a protocol on to make a status page look healthy.
## Asset screening failure states
| What happens | Why |
| --- | --- |
| Funding stops with an error rather than returning outputs | The screening infrastructure could not answer. Failing closed is deliberate |
| An output is listed as **Unverified** | The scan did not complete, was truncated, or could not answer. Not the same as safe |
| A count is marked as a lower bound | A lookup hit a cap on items or groups. The limit is stated rather than a truncated list being shown as complete |
| You are told outputs were withheld | Asset-bearing outputs were kept out of fee funding. The message gives the count and the satoshis |
## Retry behaviour
Retry controls repeat read-only requests only. **They never replay a mint, transfer, deploy,
signing or broadcast action.**
That is why retrying is always safe from the interface: the actions that spend money are not
what a retry control touches.
## Related
- [Common problems](/docs-inscribe/troubleshooting/common-problems/)
- [Where the data comes from](/docs-inscribe/concepts/source-freshness/)
- [Order states](/docs-inscribe/reference/order-states/)
---
Source: bitcoinuniverseio/docs-inscribe@77304a4e9700 (2026-09-06T11:50:08.197Z)
Last verified: 2026-09-01