# 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
An Inscribe order from quote to wallet Six stages in order. First, Inscribe quotes the job and gives you one address to pay. Second, you pay that address, which is your only wallet signature for a typical order. Third, Universe watches the address and sees the payment, accepting it from the mempool without waiting for a confirmation. Fourth, Universe signs and broadcasts the reveal transaction using a key held only for this order. Fifth, a miner confirms the reveal. Sixth, the indexer and your wallet agree the asset exists, which is the only point Inscribe calls the order done. You act only in the first two stages. The status shown is Awaiting payment for stages one and two, Creation in progress for stages three to five, and Wallet visible at stage six. Commit and reveal: two transactions, one signature from you 1 Quote One address, one amount YOU 2 Pay the commit Your wallet opens once YOU SIGN 3 Payment seen Checked every 10 seconds UNIVERSE 4 Reveal sent Signed with this order's own key UNIVERSE 5 Confirmed A miner includes the reveal BITCOIN 6 Wallet visible Indexer and wallet both agree PROOF WHAT THE STATUS SAYS Awaiting payment Creation in progress waiting for chain, indexer, and wallet evidence Wallet visible CLOSING THE TAB AFTER STAGE 2 does not lose the order. Stages 3 to 6 run on Universe infrastructure whether or not your browser is open. Home lists the orders this browser started, and reopening one asks your wallet to prove it owns the order before any payment detail is shown. THE HOUR ON THE SCREEN is the life of the price, not the life of the order. Once it passes, the quote is no longer good and you should start a fresh one. A payment that arrives late is still detected and reconciled rather than discarded, and the order's signing key is kept, not erased.
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
A payment address and an Ordinals address, and what each holds One wallet contains two addresses. The payment address holds spendable bitcoin and is what pays network fees and funds orders. The Ordinals address is a Taproot address that holds inscriptions, rune balances and token balances. Inscribe reads both, signs each action from the address that holds what it moves, and never adds the two balances together, because satoshis sitting at an Ordinals address are not spendable money. One wallet. Two addresses. Two jobs. Your wallet Payment address often starts bc1q or 3 Holds spendable bitcoin. This is the balance you can actually spend. It pays network fees and funds orders. USED FOR Paying the commit address. Covering fees. Ordinals address Taproot, starts bc1p Holds what you made and own. Inscriptions, rune balances, token balances. Its satoshis are carrying assets. USED FOR Receiving assets. Signing transfers of them. The two balances are never added together. Adding them would tell you that you can spend money you cannot.
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
What each satoshi in an Inscribe quote pays for A worked example of a 3,546 satoshi total, split into three parts. The network fee of 1,500 satoshis goes to miners and is the fee rate times the transaction size. The service fee of 1,500 satoshis is a flat charge for the order. The inscription output of 546 satoshis is not a fee: it is the satoshi your inscription sits on, and it stays in your wallet. Only the first two parts are fees. All three are paid as one amount to one address. A worked example: a small inscription at 10 sat/vB A reveal transaction of about 150 virtual bytes. Your numbers scale with size and rate. 1,500 sats 1,500 sats 546 42 percent 42 percent 16 percent Network fee Paid to miners. Your fee rate times the size of the transaction. A larger file costs more because it is bigger, not because Inscribe charges more for it. Service fee Paid to Universe. A flat 1,500 sats for most actions, charged once per order. Some flows differ and say so. Fee-bump and asset recovery charge nothing. Inscription output Stays yours. Your inscription lives on a satoshi, and that satoshi needs an output of its own. You own it after it confirms. These two are fees. They are spent. Not a fee. TOTAL YOU PAY One amount, to one address the order gives you. 3,546 sats
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

LineGoes toExample
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 Cost3,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

LineHow 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
  1. **Open `/inscribe` on the Text sub-tab and switch to bulk.** The destination must be Ordinals. Connect your wallet.
  2. **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.
  3. **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.
  4. **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.
  5. **Review the confirmation screen.** Check the item count, the total, and the receiving address. The total is what your wallet will be asked for.
  6. **Confirm and pay.** *Expected wallet screen:* one send, to one commit address, for the whole batch total. One signature covers the entire job.
  7. **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.
  8. **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
  1. **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.
  2. **Open `/inscribe` and select the Gallery sub-tab.** Connect your wallet. Upload or paste the manifest.
  3. **Check the item count and the preview.** Confirm the count matches what you intended before you look at any price.
  4. **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.
  5. **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.
  6. **Verify.** **Portfolio** should list the set. Check the count, then verify a sample of reveal transaction ids on an explorer.
## Steps: parent and child
  1. **Open `/inscribe` and select the Parent/Child sub-tab.** Connect the wallet holding the parent inscription.
  2. **Choose the parent** from the inscriptions your wallet holds, and add the child content.
  3. **Review the confirmation screen and pay the commit address.** *Expected wallet screen (first signature):* one send to the commit address for the total.
  4. **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.
  5. **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.
  1. **Open the workspace** for your protocol from the table above, and connect your wallet.
  2. **Browse the existing tokens** and confirm your ticker is not taken. This is the step people skip and regret.
  3. **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.
  4. **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.
  5. **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.
  6. **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.
  7. **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
  1. **Open `/runes`** (or `/mezcal`) and connect your wallet.
  2. **Browse existing runes** and confirm your name is free.
  3. **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.
  4. **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.
  5. **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.
  6. **Confirm and pay.** *Expected wallet screen:* one send to the commit address for the Total Cost shown. One signature.
  7. **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
  1. **Open `/inscribe` and select the Files sub-tab.** Connect your wallet if you have not. Nothing is spent by connecting.
  2. **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.
  3. **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.
  4. **Check the preview.** Confirm this is the file you meant, at the quality you meant. Read it properly; this is the last cheap moment.
  5. **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.
  6. **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.
  7. **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.
  8. **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
  1. **Open `/inscribe`.** It opens on the **Text** sub-tab. Connect your wallet.
  2. **Type or paste your text.** One line or many. The character count and the resulting size drive the network fee.
  3. **Pick the destination.** Ordinals unless you specifically want one of the others.
  4. **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.
  5. **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.
  6. **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.
  7. **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
  1. **Open the workspace** for your protocol and connect your wallet.
  2. **Find the token** in the workspace's token list, and check the supply remaining and the per-mint limit.
  3. **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.
  4. **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.
  5. **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**.
  6. **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.
  7. **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
  1. **Open the right workspace.** **Send Inscriptions** for an inscription or an output. The protocol own workspace for a token balance.
  2. **Connect the wallet holding the asset.** If the asset is at your Ordinals address, that is the account that needs to be active.
  3. **Choose what to send, and where.** Paste the destination. Check it. The confirmation screen names it again, and that is deliberate.
  4. **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.
  5. **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.
  6. **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.
  7. **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.
  8. **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.**
  1. **Wait two minutes.** The most common cause is impatience.
  2. **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.
  3. **Check the service status panel.** If the source that reads addresses is unavailable or behind, detection is delayed rather than broken.
  4. **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.
  1. **Enter the order ID** and prove ownership.
  2. **Review the diagnosis.** The tool reads the current state of your payment and says what is wrong with it.
  3. **Choose the repair** it offers for your case.
  4. **Set a fee rate that reflects current conditions**, not the one that failed.
  5. **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.**
  1. **Connect your wallet.**
  2. **Let it scan** for recoverable padding across your holdings.
  3. **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.
  4. **Select what to recover** and set a fee rate.
  5. **Sign.** *Expected wallet screen:* a transaction reclaiming the padding. Check that your inscription outputs are preserved in the outputs list.
  6. **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 ![The life of a commit-address order. You see the full cost, you pay the commit address once, Universe detects the payment and broadcasts the reveal, and the reveal confirms. Closing the tab after paying does not lose the order. An order with no payment inside one hour expires.](../../assets/order-lifecycle.svg) 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 ![One wallet, two addresses. A payment address holds spendable bitcoin and pays fees. An Ordinals address holds inscriptions, rune balances and token balances. Inscribe reads both, signs from whichever holds what it moves, and never adds the two together.](../../assets/two-addresses.svg) 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
  1. **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.
  2. **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.
  3. **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.
  4. **Check the preview.** The preview shows exactly what will be written to the chain. Read it now. After you sign, this is what exists.
  5. **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.
  6. **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.
  7. **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.
  8. **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.
  9. **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