Workflows & Contracts

1BitClaw lets you draw a process — an order, an approval chain, an auction, a payroll run — and then have Bitcoin SV actually execute it. Every step is a real transaction. Nothing sits in a company database, nothing depends on 1BitClaw staying online, and nobody takes a cut. This handbook covers both halves of that: the workflow engine that runs the process, and the sCrypt contract library that gives individual steps teeth.

0.1What this is

Two features sit at the centre of 1BitClaw, and they're designed to be used together.

A workflow without contracts is still useful: it publishes records, sends payments, waits for events, notifies people. Adding a contract is what turns "the process says pay them" into "the money is locked and can only move if the conditions hold."

0.2Which reader are you

Three quite different people end up on this page, and they need different halves of it.

0.3Get a wallet — about sixty seconds

There is no signup. Your wallet is your account, and it's created in your own browser.

1. Open the Wallet page Go to 1bitclaw.com/wallet. You have two options.
2. Either generate a key, or connect an extension ✨ Generate new wallet (WIF) creates a private key locally — it is written to your browser's storage and never sent anywhere. Or connect Yours Wallet, a browser extension that keeps the key on its side and signs when asked. Both work; WIF mode unlocks a few advanced sCrypt spends that a generic extension can't sign for.
3. Put a little BSV in it Buy some on any exchange that lists BSV and send it to your address, or ask whoever invited you to send you a few thousand satoshis. Most single steps cost well under 100 satoshis in miner fees — a few dollars goes a very long way.
4. Back it up if you generated one A WIF key lives in one browser on one device. Clear your site data without a copy and the coins are gone, with nobody to appeal to. Export it and store it the way you'd store a password.

1.1Everything is a transaction

This is the one idea the rest of the page rests on. A 1BitClaw "record" — a published task, an approval, a workflow step, a contract deployment — is not a row in a database. It is an OP_RETURN output inside a real Bitcoin SV transaction, broadcast to real miners, mined into real blocks.

Three consequences follow, and they're the reason to bother with any of this:

• It's verifiable by strangers. Every record has a transaction id. Anyone can paste it into any BSV block explorer and see the same bytes you see. They don't have to trust 1BitClaw, or you.
• It survives us. If every 1BitClaw server vanished tonight, every board, task, contract and workflow would still be sitting in the blockchain, reconstructible by anyone with the format spec. The web app is a viewer over public data, not the owner of it.
• It costs what Bitcoin costs. Usually single-digit to a few dozen satoshis per step, paid to miners. Not to us.

1.2The Outbox gate

Nothing in 1BitClaw broadcasts behind your back. Every action that would touch the chain first becomes a draft in your Outbox, where you can read exactly what it will publish and what it will cost before anything happens.

There are exactly two ways a transaction gets broadcast, and both are your decision:

• You click Approve. The default. Nothing happens while you're away.
• A policy you signed approves it for you. Under ⚙ Policy you can pre-authorise narrow categories — "auto-approve anything under 200 sats", for example. The policy is yours, it's explicit, and it has a ceiling.

Headless workflows (2.14) are the third case, and they're the one to understand properly: you hand a signed definition to a runner, and the ceiling you sign into it is a hard cap the runner cannot exceed. More on that in 2.15.

1.3Anchors — how anything is ever found again

Blockchains are excellent at storing things and terrible at finding them. 1BitClaw's answer is an anchor: alongside the OP_RETURN, the transaction sends 1 satoshi to a special address derived from a topic name. Listing the history of that address lists every record ever filed under that topic.

You'll see anchor names all over the interface: #TASKBOARD, #MARKET, #WF, #SCRYPT, plus per-object ones like #wf_8f3ac21b for a specific workflow run. When a page says "scanning the chain," this is what it's doing.

1.40-conf vs confirmed

A transaction is broadcast the moment it's sent to miners, and confirmed once it's in a mined block — typically ten minutes later. On BSV the gap is usually uneventful, but the interface never blurs it: you always see which one you're looking at.

For anything that moves real money, workflows can require more than a REST API's word for it — see 🔐 Require SPV proof in 2.15.

1.5What it costs

Short version: a miner fee per step, plus whatever the step itself moves. No protocol cut.

Participants pay for their own steps when they execute them; you pay for yours. The compile estimate (2.12) splits this out before you commit, and the proof page (2.27) shows what it actually came to afterwards.

2.1What a workflow is

A workflow is a MindMap board compiled into an ordered list of transactions. You draw boxes and arrows; the compiler walks them and produces steps. Running it means those transactions actually get broadcast, in that order, each one waiting for whatever it's told to wait for.

The board is not a diagram of the process. It is the process — there's no second place where the "real" definition lives, and no export step. That's why the layout rules in 2.3 matter more than they'd normally seem to.

2.2Board modes — View, Build, Run

The same board shows you three different things depending on the mode in the top bar. Getting this wrong is the most common reason something "isn't there."

The top bar also carries the board name, save state, and the view tools (canvas / tree / flow — 2.7). On a phone it collapses to just the mode switcher.

2.3Build the board

Open MindMap, create a board, and add nodes. Each node gets a preset — the thing it does when the process reaches it. Then link the nodes in the order they should happen.

1. Add a node, give it a preset Pick from the node's preset list: 📋 Publish Task, 💸 Payment, ✅ Approval, ⛓ Contract Call, ⏳ Wait for Event, and so on. The full map is in 2.10.
2. Fill in the fields Amounts, addresses, deadlines. Most fields accept a template reference instead of a literal — {{ctx.winnerAddr}}, {{prev.txid12}} — so a later step can use a value an earlier step produced. This is how "pay whoever won" works without you knowing the winner in advance.
3. Link them in order Draw a depends_on link from each node to the one before it. Do this for every node, not just the ones that need to pass a value along.
4. Assign anyone who isn't you If a step belongs to someone else, set its actor (2.18). Unassigned steps are yours, and you pay for them.

2.4Node types

A node's type decides what it fundamentally is; its preset (2.10) decides what it does when the process reaches it. Types are colour-coded by category on the canvas, so a board's shape is readable before you read a word of it.

Hold ＋ Node for the type picker, or add plainly and change the type later. The type is not a commitment — but it does decide which inspector tabs appear (2.6), so picking honestly saves hunting.

2.5Link kinds — the arrows are not decoration

This is the part that most rewards five minutes of attention. There are seven link kinds and they compile into genuinely different behaviour. Each has its own colour on the canvas.

Add Cross-Link draws any of these between nodes that aren't parent and child, so a board's tree layout and its dependency graph don't have to be the same shape.

2.6The node inspector, tab by tab

Select a node and the right-hand panel opens. Tabs are grouped into three sections, and only the tabs that apply to this node's type appear.

📝 Content

🔗 Links

Every link into and out of this node, with its kind — the fastest way to check the wiring from 2.5 without tracing arrows by eye. Change a kind here and the canvas colour follows.

⚡ Automation

2.7Canvas, tree and phone

Three ways to look at the same board, switchable from the top bar.

• Canvas — the spatial view. Drag to arrange, scroll to pan, zoom indicator bottom-left, and a per-board saved viewport so you come back to where you left off. ⊡ Reset Position recentres a node you've dragged off somewhere silly; ✦ Detach → Root pulls a node out of its parent to stand alone.
• Tree — the same board as an indented list. Much faster for large boards, and the only sane way to verify ordering on a board with fifty nodes.
• 🗺 Flow — the compiled steps in actor lanes. Covered in 2.25.

On a phone the inspector becomes a bottom sheet you can drag up, with a ⛶ button for full screen. The mode switcher stays; everything else collapses. Boards are genuinely usable on a phone for reviewing and approving — less so for authoring a fifty-node process, which is what the tree view is for.

2.8The board itself — queue, snapshots, sharing, sync

Before we get to steps: a board is an object in its own right, and it has its own lifecycle. Editing it is free and local; publishing it is a deliberate act.

The queue

Edits accumulate in a pending-changes queue rather than writing to the chain as you type. The queue button in the toolbar shows how many changes are waiting. From the queue panel you can:

• 📸 Publish Snapshot → Outbox — write the board's current state on chain as one record.
• ⬆ Compile — turn the selected branch into steps (2.12).
• 📤 As Template — publish the board as a reusable template others can instantiate.

Public or private

Sharing and pulling changes

• 👥 Grant Access — hand a named address read or edit rights on this board. Grants are on-chain records, so access survives you closing the tab.
• 💳 Buy access — where a board is offered for sale, the purchase is a timelocked transaction rather than a promise.
• ✏️ Sync Edits / ⟳ Sync from Chain — pull collaborators' changes in. Live edits also travel over the relay so a shared board updates within a second, with the chain as the fallback.
• 🔗 Copy Board URL / 🔗 Copy Link — deep links to the board or one node, safe to paste anywhere.

2.9Attachments, images and location

Nodes carry more than text, and a few of those extras have process consequences.

2.10Step kinds

Every preset compiles down to one of these kinds. The Where column matters: a few flow-control kinds can only run in a headless workflow, because a browser tab has nowhere to put a "jump to step 7."

Money

People

Contracts

Waiting and flow control

2.11Start from a template

Nineteen ready-made processes ship with the app: MindMap → left rail → 📋 From Template…. Pick a card, optionally fill in participant addresses, and the board is created with every node, link and actor already wired.

Templates are the fastest way to learn the tool — instantiate one, open the compile dialog, and read the step table to see how it was put together. Some templates deliberately leave one field for you: a real deadline, your own receiving address, a document's hash. The compile dialog shows those as errors until you fill them in. That's expected, not a bug.

2.12Compile — read the estimate before you commit

Select the root node of your process and press ⬆ Compile. Nothing is published; you get an estimate.

What each part is telling you:

Actor

me means you execute and pay for it. An address means that person does — they'll get an invite, and their cost is not in your total.

Type

The step kind from 2.10.

Sats

What this step costs the actor who runs it: miner fee plus anchors plus any value it moves.

Estimated cost

Your total only. The line below it — "Other actors pay their own steps" — breaks out what each participant is signing up for.

The badges in the last column

2.13Simulate before you publish

The estimate tells you what a process would cost. Simulation tells you what it would do. Both are free.

2.14Two ways to run it

At the bottom of the compile dialog you choose where the process runs. This is the most consequential setting on the page.

Bundle mode is right for a short process you'll click through in one sitting. Headless is right for anything with a deadline, a counterparty, or a wait longer than your attention span — and for anything using flow control at all.

2.15Safety rails

The headless options in the compile dialog exist because "runs while you sleep" and "can spend my money" is a combination that needs boundaries. Every one of these is signed into the workflow definition itself — the runner honours them because the chain says so, not because it's being polite.

2.16The Run panel

Once a process is live, the Run panel is where you watch it. It's on the board, and it works for any participant — not just whoever published the run.

A step with several assigned actors shows progress as "2/3 actor(s)", so you can see who has and hasn't acted on a quorum step rather than one opaque status for the lot.

Controls

• ⏸ Pause / ▶ Resume — freeze the run, fix whatever needs fixing, carry on. Also available to anyone you named as an admin.
• ⛔ Kill — terminal. The run stops permanently and cannot be resumed. Owner only.
• ⟳ Refresh — re-scan the chain rather than trusting the cached view. Use it if something looks stale.
• ⋯ — occasional operator actions: add the run to a different runner, fund it, migrate it.

2.17Versions and supersedes

Processes change. Rather than editing a live run — which would break the guarantee that what's on chain is what's executing — you publish a new version.

In the compile dialog, ↗ New version of… marks the run you're replacing. The new definition records that it supersedes the old one, so anyone reading the chain sees the lineage instead of two unrelated processes that happen to look similar. The old run doesn't die on its own: kill it deliberately, or let it finish.

2.18Actors and invites

Any step can be assigned to someone who isn't you. They don't need a 1BitClaw account, they don't need to understand MindMap, and they never see the rest of your process unless you show them.

Who an actor can be

If you're the one who got the link

1. Open it You'll see what process it belongs to, which step is yours, what it costs you, and by when.
2. Connect or create a wallet See 0.3 — under a minute. You need enough for a miner fee, usually well under 100 satoshis.
3. Do the step Read what it's asking, check the cost, tap the button. Your wallet signs locally and broadcasts.
4. That's it You can close the tab. The process continues without you unless a later step is also yours.

2.19Context, extracts and roles

A process that can't carry information forward is just a checklist. Three mechanisms move data between steps.

Extracts — pull a value out of a step's result

Any step can declare extracts (+ Add extract in the step editor): "take the bidder's address out of the record this wait was waiting for, and call it winnerAddr." From then on any field can say {{ctx.winnerAddr}}. Extracts can also aggregate — counting matching records rather than taking the first.

Context schema — declare what a run expects

+ Add ctx key in the compile dialog declares the keys this workflow expects to exist, with their types. It turns "the payout silently resolved to an empty address" into an error at compile time. Worth doing for anything that pays out.

Roles — name the people once

🎭 Manage roles… keeps a named registry — "approver", "supplier", "arbiter" — that steps refer to instead of repeating raw addresses. Change who fills a role in one place and every step follows. Roles can also be resolved dynamically at run time from a contract's state or a task's winner (2.18).

2.20Waits and conditions

A wait step is the process standing still on purpose. It's how a workflow survives contact with the real world, where the bid hasn't arrived yet and the deadline is on Thursday.

2.21Signatures on a document

The ✍️ Signatures tab turns a document node into something people cryptographically sign, and a wait step into a gate that only opens on valid signatures.

1. Derive the hash 📎 From file hashes an attachment; ⌗ From note text hashes the node's body. The sha256 is what everyone signs — not the file itself, which never has to leave your machine.
2. Set the signers and the threshold On the wait step: the list of addresses, and how many of them are required. "Any 2 of these 3" is the common shape.
3. Signers open the board and sign Each signs the hash with their own key. The signature is an on-chain record; nobody hands anybody a private key.
4. 🔍 Verify signatures Checks every signature against the hash and the signer list. Only cryptographically valid signatures from distinct addresses count toward the threshold — a duplicate or a forgery never advances the process.

2.22Crowdfund, pledge and milestone nodes

Three node types exist specifically for raising money against staged delivery, with a 💰 DeFi inspector tab showing live state. 💰 New CF Board creates a board pre-wired for this.

Campaign and milestone ids wire themselves between nodes — you don't copy identifiers by hand. Insert a ⏳ Wait for Event with a quorum between the vote and the release if the tranche should only unlock once enough backers have actually voted.

2.23Script steps and the catalog

for developers

A ⚗ Script step runs a small sandboxed script over the run's context — the escape hatch for logic that Transform can't express. Its editor lives in the node's Edit tab rather than the Step tab, with a test input field so you can run it against a sample context before it goes anywhere near a real run.

📤 Publish to catalog shares a script on-chain so other boards can load it with Load instead of pasting source around.

2.24Branch, transform, loop

These four kinds make a workflow a program rather than a checklist. All of them are headless-only.

The context (ctx) is the run's shared memory: values extracted from earlier steps, form inputs, computed results. Anywhere a field accepts {{ctx.something}}, it's reading from there.

2.25Flow view, decision tables, BPMN export

The board is good for authoring and bad for explaining. Three other views exist for the moments when someone else has to understand or sign off on the process.

The decision table is a genuine alternative editor, not a read-only rendering: ▦ Use decision table instead converts a branch and you carry on editing there, with the same 🧪 Test cases button (2.13) applied to the whole grid.

2.26Triggers — a workflow as a standing service

Normally you publish a workflow and it runs once. A trigger makes it run every time a matching record appears — a new order, a new application, a new pledge — spawning a fresh run each time with that record's data already in context.

You define what to watch (a record type on an anchor), optionally what to extract from it into the run's context, and the runner does the rest. Triggers can be added to and removed from a live workflow without republishing it. It's the difference between "process this order" and "process orders."

2.27Proof and audit

Every run has a read-only page you can hand to anyone: a customer waiting on delivery, an auditor, a counterparty who wants to know what they agreed to.

Two things make this different from a PDF report:

• Independently checkable. Every transaction id links out to a public block explorer. Nobody has to take 1BitClaw's rendering on faith — or yours.
• Reconstructible without us. The page is a view over public chain data. Given the record formats, anyone could rebuild it from the blockchain alone.

The cost breakdown is worth pointing at when someone asks what a process cost: it separates the owner's spend, each participant's own spend, and any runner fee — and shows the protocol's cut, which is zero.

2.28Runners

A runner is the service that executes a headless workflow's eligible steps. You pick one when you publish.

Whichever you choose, the safety model is identical: the runner reads your signed definition from the chain, and your signed limits bound it. A paid runner has no more authority than a free one — it's just more likely to be awake.

2.29My Invites, the anchor explorer and Admin

Three utilities that don't belong to any one board.

🧭 My Processes / My Invites

Every workflow where you're the owner or an assigned actor, on one screen — including invites you were sent and never opened. If you suspect you're holding somebody's process up, this is where you find out. It's in the sidebar as My Processes, and as a modal from inside a board.

Anchor explorer

Scan any anchor address and read its raw records. This is the chain-level view under everything in 1.3 — useful when you want to check that a record really is where the interface claims, or to explore a topic no screen has a view for yet.

⚙ Admin

For boards you own:

• ⟳ Refresh from Chain — re-read this board and its grants from the chain, ignoring the local cache.
• 👥 Grant Access / 💾 Save Access Settings — the grant records from 2.8, managed in bulk.
• ⚠ Clear Local Cache — drops the browser's copy of the board. Safe if the board is published or privately synced; destructive if you have unpublished local edits, because that cache is the only place they exist. Check the queue is empty first.

2.30When it gets stuck

3.1What's in the library

The Contracts module is a browsable library of 126 sCrypt smart contracts, compiled and ready to deploy. sCrypt is a language that compiles to Bitcoin Script — so a "contract" here is not a program running on a virtual machine somewhere, it's a locking script on a real UTXO. Spending that UTXO requires satisfying the script, and miners enforce that. Nobody has to run the contract for it to be binding.

3.2Browse and read a contract

Open Contracts. Search or filter by category, pick one, and the right-hand pane shows what it does, what state it holds, and what methods it exposes.

Two parts of the detail pane are worth reading properly before you deploy anything:

• State — the fields the contract carries, with their sCrypt types. These are set at deploy time and updated by method calls. For a live instance, this pane shows the current decoded values, read out of the locking script.
• Methods — what can be called, and with what parameters. This is the contract's entire public surface. Anything not listed here cannot happen.

A verified ✓ mark means the shipped adapter matches its compiled artifact — the code you're about to deploy is the code the description is about. The 📚 Learn tab has walk-throughs for the common patterns if a contract's purpose isn't obvious from its state.

3.3Learn tracks and the community library

Two parts of the module exist purely to shorten the distance between "I opened this" and "I understand what I'm looking at."

• 📚 Learn — structured tracks rather than a wall of reference. Each lesson explains one pattern — what a stateful contract is, why an escrow needs an arbiter, how a commit–reveal scheme stops cheating — against the contracts actually in the library, so you can open the thing you just read about.
• 🌐 Community — contracts published by other people, discoverable by 🌐 Search Community. Anything here was imported and published by a third party, so read the state and methods yourself before deploying: verified ✓ means the adapter matches its artifact, not that a stranger's contract does what its description claims.

3.4Deploy an instance

Press ▶ Deploy. You fill in the constructor arguments and the initial state, and you get a draft in your Outbox — not a broadcast.

1. Fill the constructor Fields that are your own key fill themselves in. Amounts are in satoshis; deadlines are block heights unless the field says otherwise. Text fields on token contracts accept plain strings — CLAW becomes the right bytes for you.
2. Set the locked value How many satoshis the contract UTXO holds. For a contract that's only tracking state, 1 satoshi is correct. For an escrow or an auction, this is the money at stake.
3. Read the dry run It builds the locking script and round-trips the state through the decoder, so an encoding bug surfaces here rather than after you've paid. It also gives you the real cost estimate.
4. Send it to the Outbox ▶ Run on Mainnet → Outbox queues the draft. Approving it is a separate, deliberate act — the same gate as everything else in 1.2.

Once broadcast, the instance is live at that transaction id. That txid is how you and everyone else refer to it from then on: in a workflow's Contract node, in a condition, in a link you send someone.

3.5Filling the hard fields

Contract forms ask for things that aren't typeable from memory — a current block height, a sha256, an oracle's public key, a specific unspent output. Rather than sending you elsewhere, tricky fields carry a small helper button that fills them correctly.

Helpers only ever fill an input — they never submit anything, and the value stays editable. Field validation runs alongside: wrong hex lengths and malformed addresses are flagged before you can queue a deploy.

3.6Test before you spend

🧪 Test opens a sandbox. It runs in two modes and neither one broadcasts anything.

3.7Call a method

Open a live instance and pick a method. Fill in the parameters, and the call is queued to your Outbox like everything else. The transaction spends the current instance and creates the successor.

Some methods need more than parameters — a merkle proof, a block header, a signature from an oracle. The call panel says which, and refuses to build a transaction from placeholder data. If a method is marked intent-only, no automatic executor exists for it yet: 1BitClaw will record that you intend to call it, but the actual spending transaction is one you construct yourself. That's a real gap, and it's labelled rather than hidden.

The other buttons in the call panel

3.8Find your instances again

A contract instance is identified by a transaction id, and transaction ids are easy to lose. Four things find them for you.

• 🔍 Scan Chain (on a contract) — every live instance of this contract, whoever deployed it.
• 🔎 Scan My Contract Anchors — everything you ever deployed, across all contracts. The one to reach for when you've lost track entirely.
• 🔔 Activity feed — recent calls against instances you care about, with unread marking. Clicking a row opens that instance.
• ⏱ Timeline — one instance's full history: ⏮ First, ◀ Prev, Next ▶, Last ⏭ through every call ever made, with what changed at each step. Exportable as ⬇ CSV or ⬇ JSON, and 🔗 Link gives a shareable URL to a specific point in the history.

The timeline is the audit trail for a contract in the same way the proof page (2.27) is for a process — and equally re-derivable from the chain by anyone.

3.9Co-build — deploy a contract together

Some contracts need input from more than one person before they can exist: an escrow where both sides supply an address, a multi-party agreement where each party sets their own term. 🤝 Co-build opens a shared session over that deploy form.

1. Start a session and invite The initiator opens Co-build and sends invites — a link, or straight to a contact's address. The session is ephemeral and identified by a random id; it isn't published anywhere.
2. Everyone fills their own fields You see live presence dots, a coloured focus ring showing what each participant is editing, and a role badge. 📌 Fill mine completes the fields that are about you. Edits merge last-write-wins per field.
3. 🔒 Finalize, then everyone approves Finalizing freezes the field set and hashes it. Each participant's ✅ Approve recomputes that hash locally before signing — nobody approves a form they can't verify.
4. The initiator deploys Only once everyone has approved, and never automatically. It goes through the same Outbox gate as any other deploy. When it broadcasts, everybody's session opens the new instance.

📜 Copy proof exports the approved field set and its hash — evidence of what everyone agreed to, independent of the app. ✏️ Re-open unfreezes if something needs changing before deployment.

3.10Who may call what

Being able to see a contract doesn't mean being able to call its methods, and the app works this out from the contract's own state rather than from any permission list of ours.

This is why a workflow's contract_role actor works: "whoever the current highest bidder is" is a question the contract's state can answer, at the moment the step runs.

3.11Auto-execute conditions

Plenty of contract calls are things nobody needs to decide — "close the auction once the deadline passes," "refund once the campaign misses its goal." ⚡ Auto-execute when… publishes that rule on-chain so a keeper can fire it for you.

The banner is the important part, and it has four honest states:

Conditions are also checked for authorship: a condition is only registered if whoever funded the transaction is the party entitled to set it. A stray or spoofed condition on someone else's instance is ignored, not attempted.

3.12🤖 Automate — the other way to make it run itself

⚡ Auto-execute and 🤖 Automate solve the same problem from opposite ends, and the difference decides which one you want.

🤖 Automate on an instance hands it straight to Run Agent with the contract and instance already filled in. Use ⚡ when the rule is simple and you'd rather nobody had to run anything; use 🤖 when you want control over the thing doing the work.

3.13Import your own contract

for developers

You are not limited to the shipped 126. Tools → Import Contract takes a compiled sCrypt artifact.json — paste it or drop the file — and builds a working adapter in your browser.

# in the sCrypt boilerplate repo
npx scrypt-cli compile          # your Contract.ts → artifact.json

The import preview shows what was extracted: the locking script template, the state properties and their types, the ABI methods, and the action mapping. Once imported, the contract behaves exactly like a built-in one — deploy it, test it, call it, use it in a workflow. It's stored locally in your browser until you publish it.

3.14Build one without writing sCrypt

Between "use a shipped contract" and "write sCrypt" there's a third option: the 🛠 Write from scratch — F2 Script-DSL section on the Import tab, which builds a locking script directly. It has two modes.

The workflow is 🧪 Verify → 📦 Register → 🚀 Deploy / Live Test → optionally 📡 Publish as Template. Verification runs the spend offline before any of it costs anything. There's also a guided wizard for the classic first contract — 🎲 Generate my secret → → Open HashLock & Deploy — which is the shortest route from nothing to a working deployed contract you understand.

3.15Publish a template so others can use it

for developers

📤 Publish ships an imported adapter on-chain, so anyone can install and deploy it. The adapter code is gzipped, split into chunks and broadcast as records anchored under the contract library's topics — the same mechanism the app itself uses to distribute its own modules.

Alongside the code, a recipe record is published: a compact description of the contract's constructor fields, state and methods, so other people's clients can render a sensible deploy form without parsing the whole artifact. Once the transactions confirm, your contract shows up in Browse for everybody.

3.16Analyze a transaction

Tools → Analyze TX takes one transaction id or a whole list, and classifies each transaction's locking scripts without needing the relevant contract installed first. Useful for working out what an unfamiliar transaction actually is, auditing a batch, or finding the instance you've lost track of.

From a result you can jump straight into 🧪 Test → Call Method against the instance you just inspected, which is the fastest path from "what is this" to "can I do anything with it."

3.17My Assets

The My Assets tab collects what your wallet actually holds and controls: token balances, contract instances you deployed, ordinals, and positions in contracts you're a participant in. Sending and transferring happen here, as do the standard BSV-20 deploy-and-mint flows.

Like everything else, it's a view over the chain rather than a ledger we keep — which is why it can show you assets you acquired somewhere else entirely.

3.18🏭 Mint — tokens, media and collections

The Mint tab creates new assets rather than calling existing contracts. It covers two quite different things that share a screen.

Fungible tokens

Standard BSV-20 style deploy-and-mint: a ticker, a supply, a decimals setting. Once minted the balance shows up in My Assets and can be sent, listed, or used as a token_holder gate on a workflow step (2.18).

Inscriptions and media

Collections group inscriptions under one identity, with a collection page listing everything in it. Pick the collection at mint time and items land in it automatically; View in My Assets → takes you to what you just made.

3.19Send, transfer and list for sale

From My Assets, three things you can do with something you hold.

Every one of these is a draft first. Nothing leaves your wallet without an approval, and the fee estimate is shown before you approve.

3.20Positions, swaps and settlements

A few contracts in the library are financial instruments rather than plain state machines, and they get purpose-built panels.

• 📊 My Positions — every live instance you're a party to, in one table: which contract, current state, your role. On My Assets and on the welcome screen. This is the "what am I currently exposed to" view.
• AMM swap — pick a pool and a direction and you get a live quote before committing. 🔮 Attest fetches the oracle signature the pool needs, then 🚀 Queue swap → Outbox builds the real transaction.
• Forwards settlement — a forward can only settle against an attested price. The settle button stays disabled until you've pulled that attestation, which is the contract's rule showing through the UI rather than a loading state.

3.21Contracts inside workflows

This is where the two halves meet, and it's the point of the whole system.

1. Put a Contract node on the board Either attach an existing instance by its txid, or let a contract_deploy step create one as part of the process.
2. Add a Contract Call step that references it Pick the method. Parameters can come from the wallet, from an earlier step's output, or be computed — {{ctx.bidSats}}, "previous value plus 100", and so on.
3. Guard the transition with conditions The link into that step can carry conditions: contract state comparisons, block height, confirmation counts. The step stays blocked until they all pass.
4. Let the actor be a contract role Set the step's actor to contract_role and the person is resolved from the contract's live state at run time — the current bidder, the named arbiter, the owner.

That inspector is the debugging tool for this whole area. "Blocked" is never a mystery — it tells you the condition, the current value, and what it's waiting for.

3.22⚡ Batch — many calls, one transaction

Pro mode

When you need to call the same method on a lot of instances — settling forty positions, incrementing a hundred counters — Batch puts them in a single transaction instead of a hundred, which collapses the miner fee accordingly.

It only offers contract/method pairs that are batch-safe: the tool reads the registry of spend profiles and shows you only the ones whose state can be combined this way, marking which have a verified executor. A method that isn't safe to batch simply isn't in the list — the constraint is enforced, not advisory.

3.23Pro mode — source, disassembly, offline verify

for developers

Switching the shell to ⚡ Pro exposes the layer underneath the forms.

Offline verify is the fastest way to answer "would this spend actually validate" without spending anything, and it's the same answer the CLI gives — see 3.24.

3.24The contract-dev CLI

for developers

If you're writing contracts rather than using them, there's a command-line environment for the whole cycle. Everything is dry-run unless you pass --broadcast, and the signing key only ever comes from an environment variable — never a flag, never a file in the repo.

node contract-dev.mjs doctor              # check your environment
node contract-dev.mjs lint  MyContract   # pre-compile rules, method classification
node contract-dev.mjs build MyContract   # scryptc → artifact.json
node contract-dev.mjs gen   MyContract   # artifact → adapter
node contract-dev.mjs drift --check      # catch adapters that drifted from their artifact
node contract-dev.mjs verify MyContract
node contract-dev.mjs deploy MyContract  # add --broadcast to actually spend
node contract-dev.mjs call   MyContract methodName
node contract-dev.mjs status

drift --check is the one to wire into CI: it catches adapters that no longer match their compiled artifact, which is the failure mode that produces contracts that look fine and don't work.

4.1On-chain record types

You'll see these prefixes on block explorers, in the Outbox's inspector, and in the Pro-mode badges. They are the actual wire format — knowing them is what lets you verify a claim on this page rather than believe it.

4.2URLs and deep links

Every meaningful object has a link you can send someone. They resolve for anyone, signed in or not.

/e/<txid> is the one to remember: it takes any transaction id from this system and sends it to the right screen. It's what you paste when someone asks "what is this transaction."

4.3Glossary

Anchor

A Bitcoin address derived from a topic name. Sending 1 satoshi to it files a record under that topic; listing its history is how anything is ever found. See 1.3.

Actor / assignee

The person a step is delegated to. Can be a fixed address, a quorum group, or a role resolved at run time.

Board / node

The visual editor (MindMap) and one box in it. A node becomes one step when compiled.

Bundle

A workflow compiled into your own Outbox rather than published for a runner. Stops when your browser tab does.

Context (ctx)

A run's shared memory — values extracted from earlier steps, form inputs, computed results. Referenced as {{ctx.name}}.

Draft

A transaction that has been built and costed but not broadcast. Lives in your Outbox and costs nothing.

Headless / MM_WF

A workflow published on-chain to run unattended, executed by a runner instead of your clicks.

Instance

One live deployment of a contract — a specific UTXO carrying specific state, identified by the transaction that created it.

Intent-only

A contract method with no automatic transaction builder yet. 1BitClaw records that you meant to call it; you build the spend yourself.

Keeper

A service that watches published ⚡ conditions and executes the call when they turn true. See 3.11.

Liveness coin

A single satoshi a runner holds to declare itself alive. Spending it stops the role, from any device, within about a second.

0-conf

Broadcast and verified, but not yet in a mined block. Always shown as a distinct badge rather than blurred into "done".

Outbox

Your queue of drafts awaiting approval. The single gate every spend passes through.

Permissionless step

A contract call nobody in particular needs to sign for — "claim after the deadline". These can run automatically.

Participant-bound step

A call that needs one specific person's signature. These always route to that person and never run on their behalf.

Preset

What a node does — 💸 Payment, ✅ Approval, ⛓ Contract Call, and so on. Presets compile down to step kinds.

Recipe

A published description of a contract's deploy form and methods, so other clients can render it without parsing the full artifact.

Runner

The service executing a headless workflow's eligible steps. Free, paid, or your own.

sCrypt

The language these contracts are written in. It compiles to Bitcoin Script, so contracts are enforced by miners rather than by a platform.

SPV proof

Verifying a confirmation with a merkle proof against independently-fetched block headers, instead of trusting an API's word. Optional, recommended for money.

Step

One entry in a compiled workflow: a record, a payment, a contract call, or a wait.

Trigger

A rule that spawns a new run of a workflow every time a matching record appears.

WIF

Wallet Import Format — the encoded form of a private key. In WIF mode the key lives in your browser; in extension mode it lives in the extension.

wf-proof

The read-only, independently verifiable summary of a run: what happened, who paid, what it cost.

4.4FAQ

Do I need to understand Bitcoin to use this?

No. You need a wallet with a small balance and the willingness to read a cost estimate before clicking. Everything else — anchors, UTXOs, script — is machinery you can ignore until you're curious.

What does it cost?

A miner fee per step, typically single digits to a few dozen satoshis, plus whatever value the step itself moves. No protocol fee, no percentage, no subscription. See 1.5.

Can 1BitClaw take my money, freeze my process, or delete my data?

No, no, and no. Your key signs your transactions; a published workflow's limits are signed on-chain and bound every runner; and records are in the blockchain, where nobody can retract them. The flip side is in 0.3 — lose your key and nobody can help you either.

What happens if 1BitClaw disappears?

Your records stay on the chain, readable by anyone with the formats in 4.1. Running workflows would stop when their runners stopped, but nothing already executed is lost, and nothing is locked to us. Self-hostable versions of the runner, indexer and relay ship in the repository.

Does a workflow keep running when I close the tab?

Only if it's headless. A bundle compiled to your Outbox waits for you. See 2.14.

Can a runner spend more than I intended?

No. The payout ceiling is signed into the workflow definition, and the effective cap is the lower of yours and the runner's own. Anything above it pauses for your manual approval instead of broadcasting.

Someone sent me a link. Is it safe to open?

Opening it is safe — it's a read-only page until you connect a wallet. It shows you what's being asked and what it costs before anything is signed, and it can't move funds you don't approve. Check the amount before tapping the button, exactly as you would anywhere else.

Why is my step still "blocked"?

Select the node and read the inspector: it lists each condition with its live result and each parameter with its source. "Blocked" always has a stated reason.

Can I use my own contract?

Yes — import a compiled artifact.json (3.13), or publish it on-chain so others can use it too (3.15).

Is any of this reversible?

Before you approve a draft: entirely. After it's broadcast: no. That's why the Outbox exists as a separate, deliberate step rather than a confirmation dialog you learn to dismiss.

Is there an API?

The chain is the API. Anchors are public, record formats are documented, and snapshots are served over plain HTTP. Anything the web app can read, your own code can read the same way.