Blockchain Toolkits

User journeys

BC-01. Give an app a wallet on another chain

Path: /workspace → Workspace Chat → proposal card

You do:

1. Open or create a project in Workspace Chat.
2. Describe the job in plain words — e.g. "members hold USDC on Base and can send it to each other".
3. Review the proposal card: it names the toolkit it matched (here EVM Wallet), and nothing is wired until you accept.
4. Accept it and let the build finish; the Motoko module and its hook are seeded into the app.
5. Deploy, sign in to the app, and open the wallet screen.

Result: Every signed-in person has their own address, derived from the subnet's threshold key, and a live balance read from the chain. Sends are signed by the canister, with no private key or browser extension anywhere.

BC-02. Take payment in ICP, ckUSDC or ckBTC

Path: /workspace → Workspace Chat → prompt "charge in ckUSDC"

You do:

1. Ask for crypto checkout in the prompt (ICP, ckUSDC, ckBTC or any ICRC-1 token).
2. Accept the ICP Payments proposal and deploy.
3. In the app, create an invoice; it gets its own deposit address.
4. The payer sends the amount to that address.
5. Check the invoice; the canister confirms it against the ledger and sweeps it to the treasury.

Result: Payments settle on-chain without a card processor. Each invoice shows paid or unpaid as the ledger reports it.

BC-03. Accept real Bitcoin

Path: /workspace → Workspace Chat → prompt naming Bitcoin

You do:

1. Decide the shape. Choose native BTC if it should stay Bitcoin on the Bitcoin network. Choose ckBTC if it should land in the app's ICP wallet (the Bitcoin & Ether Bridge).
2. Say which in the prompt, then accept the proposed toolkit.
3. Deploy; each signed-in person gets a bc1 address, or a deposit address for the bridge.
4. Send to it and refresh the balance.

Result: Real on-chain Bitcoin, read and sent through the Internet Computer's own Bitcoin API, with no wrapped token (native) or a 1:1 ckBTC credit (bridge).

BC-04. Inscribe an ordinal, send runes, move BRC-20

Path: /workspace → prompt "inscribe ordinals" / "send runes" → Ordinals, Runes & BRC-20

You do:

1. Accept the Ordinals proposal and deploy.
2. Fund the app's Bitcoin wallet, which pays fees; the Taproot vault holds the collectibles.
3. Inscribe content. The canister runs the commit and reveal transactions on Bitcoin itself.
4. Send an inscription, or send and mint runes by exact amount.
5. For BRC-20 balances and rune names, confirm the platform indexer key is set.

Result: Inscriptions and runes created and moved from the app's own vault. A fee is never taken from an output that carries an inscription or a rune. Without the indexer key, BRC-20 balances say not configured; they never read as zero.

BC-05. Let people use their own wallet

Path: /workspace → prompt naming the wallet (e.g. "connect Phantom", "sign in with Keplr")

You do:

1. Name the wallet or the chain's wallet in the prompt.
2. Accept the wallet kit proposal (Lane B).
3. Deploy. In the app, press Connect and approve in the wallet.
4. Sign a transaction; the wallet shows it and the person approves it there.

Result: The person keeps custody: they sign and pay the fee in their own wallet, and no key reaches the app. The app can pair this with a Lane A wallet when it also needs a treasury.

BC-06. Store files on Filecoin

Path: the deployed app → owner controls (Filecoin storage)

You do:

1. Accept Filecoin Wallet & Storage for the app and deploy.
2. As the owner, paste your Lighthouse API key. It is checked with Lighthouse before it is kept.
3. Set the storage policy: whether signed-in people may store files or only you, and the largest file allowed.
4. Store a file from the app, then open its deal status.

Result: The file is stored through Lighthouse on your own account, and its CID and deals are listed. Deals are labelled as reported by Lighthouse, because their ids do not resolve on-chain. The Filecoin wallet itself (f1 address, FIL sends, actor calls) works without any key.

BC-07. Run a container on decentralized compute with a spend ceiling

Path: the deployed app → owner controls (Compute)

You do:

1. Accept Decentralized Compute & AI and deploy.
2. Paste the key for your provider: Akash Console, Fluence, io.net IO Cloud, or Dispersed (Render's compute network).
3. Set an hourly USD ceiling, a live-deployment cap and the most hours a deployment may be booked for. Nothing deploys until the limits are set.
4. Browse offers with their prices, then deploy a container image.
5. Open its public address; refresh or stop it when done.

Result: A running deployment on your own provider account, booked for a bounded number of hours, so spending ends even if a stop never lands. On Akash, the ceiling becomes the bid limit, so the chain itself refuses a dearer bid.

BC-08. Chat on open-source models through IO Intelligence

Path: the deployed app → owner controls (IO Intelligence)

You do:

1. Paste an IO Intelligence API key.
2. Pick a model from the list (the list needs no key), and set the policy: the token cap per answer, the daily request cap, and whether signed-in people may ask or only you.
3. Ask a question from the app's chat screen.

Result: Answers from io.net-hosted open models on your account, stopped by the canister once a cap is reached.

BC-09. Trade Hyperliquid perpetuals from the treasury, with guardrails

Path: the deployed app → owner controls (Hyperliquid)

You do:

1. Accept Hyperliquid Trading and deploy; fund the treasury address with USDC on Hyperliquid.
2. Set guardrails: per-order and daily USD ceilings, allowed markets and maximum leverage.
3. Place a limit or market order; see positions and open orders.
4. Approve or reject any order you did not place yourself.

Result: Orders the canister enforces against your limits. Trading is off until guardrails exist, and orders you did not place wait for your approval.

BC-10. Take Lightning payments

Path: the deployed app → owner controls (Lightning)

You do:

1. Accept Lightning Payments and deploy.
2. Enter your LNbits URL and invoice / admin keys (your own instance, a hosted one, or demo.lnbits.com while building).
3. Set per-payment and daily limits for outgoing payments.
4. Anyone the app admits requests an invoice and sees it as a QR; it is watched until paid or expired.

Result: bolt11 invoices and owner-only payments within the limits the canister enforces. The Internet Computer has no native Lightning, so LNbits holds the channels.

BC-11. Move value between chains

Path: /workspace → prompt "bridge USDC from Base to Arbitrum" → Cross-Chain

You do:

1. Accept Cross-Chain along with the EVM Wallet.
2. Choose the route the job needs: native USDC via Circle CCTP; tokens and messages via Chainlink CCIP, including Solana and Aptos; or LayerZero, Wormhole, Axelar or Hyperlane.
3. Quote the fee, then send from the app's wallet.
4. Track delivery status until the destination confirms.

Result: Value or a message lands on the destination chain, sent from the app's threshold-key wallet with the protocol's own fee quote.

BC-12. Start a crypto app from the Crypto Workshop

Path: /crypto → a recipe or a chain page in the Chain Atlas → Start

You do:

1. Open the Crypto Workshop from the module switcher or go to /crypto.
2. Pick a recipe on the front door, or open a chain's page in the Chain Atlas.
3. Press Start and say what the app is for in your own words on the confirm sheet.
4. Let the workspace's generate lane build it, then open the project.

Result: An ordinary Kontext project whose brief named the chain and its toolkits as stated facts, so the engine keeps them; it appears under Your crypto apps and in the workspace.

BC-13. Add a chain to an app you already have

Path: /crypto → a chain's page → Add to an app

You do:

1. Open the chain's page in the Chain Atlas.
2. Choose Add to an app and pick the project.
3. Confirm; the update lane wires the named toolkit into that app.
4. Deploy the update.

Result: The same project gains the chain's module and hook through the update lane; nothing is copied and the app keeps its data if deployed as an upgrade.

BC-14. Store an app's provider keys from the Crypto Workshop

Path: /crypto → Your crypto apps → the app → Keys

You do:

1. Open the app's page under Your crypto apps.
2. Find the key the service needs (for example LNbits, Akash, Fluence, io.net, Dispersed, IO Intelligence, Lighthouse, toncenter or algod).
3. Paste it and save.
4. Read the status the app reports for that service.

Result: The key goes straight to the app's own owner-only setter, which checks it with the provider; the field clears and the browser keeps nothing, and a module that reports no status says "App does not report it".

BC-PLT-01. Let people upload photos and use each one by URL

Path: /workspace → prompt "members upload photos of their pets and we turn each one into a poster" → Kontext Files

You do:

1. Describe the job without naming a storage vendor, and accept the Kontext Files proposal.
2. Deploy, sign in to the app, and pick a photo on the upload screen.
3. The file is sent in 1.5 MB pieces and then finished.
4. Open the file from your list, or hand its URL to the vendor that makes the poster.

Result: The photo is stored in the app's own canister and served at an unlisted raw.icp0.io URL anyone holding it can open; a file over 50 MB is refused with "The file is larger than 50 MB."

BC-PLT-02. Receive Stripe events at the app's own URL

Path: /workspace → prompt "when stripe says payment succeeded, mark the booking paid" → Kontext Webhooks

You do:

1. Accept the Kontext Webhooks proposal and deploy.
2. As the owner, open the app's webhook settings and enable a source named stripe.
3. Copy the URL it shows and paste it into Stripe's webhook settings.
4. Trigger a payment; open the events list and see the event with its raw body.
5. The app's code acts on it and marks it handled.

Result: Events arrive at /webhooks/stripe/ on the app's canister and wait in a queue until acknowledged; a POST with a wrong token gets 404, and Stripe's own signature header is not checked.

BC-PLT-03. Give each family its own space with invite codes

Path: /workspace → prompt "multiple families share the app, each with their own lists and invite codes" → Kontext Workspaces

You do:

1. Accept the Kontext Workspaces proposal and deploy.
2. Sign in; with no workspace yet, the app offers create or join. Create one and name it.
3. As its owner, mint an invite code for the member role and send it to a relative.
4. The relative signs in, chooses join, and enters the code.
5. Open the members list to see both of you with your roles.

Result: Each family sees only its own rows; a second join attempt answers "You already belong to a workspace.", and a spent code answers "That invite has been used up."

BC-PLT-04. Change a member's role or remove them

Path: the deployed app → workspace members screen

You do:

1. Sign in as the workspace owner or an admin and open the members list.
2. Change a member to viewer so they can read but not write.
3. Remove a member who has left; a member can also leave on their own.

Result: The role change takes effect at once; ownership never changes here ("Ownership does not change here.") and the owner cannot be removed.

BC-PLT-05. See who approved a booking

Path: /workspace → prompt "keep an audit trail of who approved each booking" → Kontext Audit Trail

You do:

1. Accept the Kontext Audit Trail proposal and deploy.
2. Approve a booking in the app; the app records who, what and when.
3. Open the activity history and filter by the booking (for example booking:12) or by the action booking.approve.

Result: An append-only list, oldest first, that the owner sees in full, a workspace admin sees for their workspace, and anyone else sees only for their own actions.

BC-PLT-06. Download a table for the accountant

Path: /workspace → prompt "the owner can export the bookings to excel as a csv" → Kontext Export

You do:

1. Accept the Kontext Export proposal and let the build list the app's tables for export.
2. Deploy and sign in as the owner.
3. Open the export screen, pick the bookings table and choose CSV or JSON.

Result: A single bookings.csv (or bookings.json) is saved, assembled from 2,000-row pages; anyone who is not the owner or a workspace admin sees no tables.

BC-ICP-01. Give every member a token wallet

Path: /workspace → prompt "every member gets a crypto wallet on ICP to hold ICP and ckUSDC" → Kontext ICP Tokens

You do:

1. Accept the Kontext ICP Tokens proposal and deploy.
2. Sign in and open the wallet screen; copy your deposit address.
3. Send ICP to it from any ICP wallet.
4. Press refresh to read the balance from the ledger.
5. Send part of it to another principal or ICRC-1 account.

Result: The deposit appears as a received entry labelled "Detected on refresh", the send returns a block index, and a short balance says "Insufficient ICP: have …, need … including the fee."

BC-ICP-02. Add a token to the app's list

Path: the deployed app → wallet screen (owner)

You do:

1. Sign in as the owner and open the add-token picker.
2. Pick ckUSDC from the suggested ledgers, or paste any ledger's canister id.
3. Confirm; the canister asks the ledger for its name, symbol, decimals and fee.
4. Pause a token later if it should stop moving.

Result: The token joins the list with its own decimals; a canister that is not a ledger answers "Not an ICRC-1 ledger (…)", and a paused token refuses sends with "Token X is paused."

BC-ICP-03. Mint a membership NFT for each member

Path: /workspace → prompt "mint an nft for each member on our own canister" → Kontext ICP NFTs

You do:

1. Accept the Kontext ICP NFTs proposal and deploy.
2. As the owner, set the collection's name, symbol, description, logo and an optional supply cap.
3. Mint a token to a member's principal with a name, an image URL and attributes.
4. The member signs in and sees it under their tokens; they can transfer it.

Result: The app's canister is an ICRC-7 collection that ICRC-7 wallets and marketplaces can read; minting past the cap answers "The collection's supply cap of N is reached."

BC-ICP-04. Read what a person holds in another collection

Path: the deployed app → holdings screen

You do:

1. Sign in and open the screen that reads another collection.
2. Enter that collection's canister id (or the app supplies it).
3. The canister asks that collection which tokens you hold and their metadata.

Result: The list of your tokens there, with metadata; a collection that does not answer reports "Could not read collection …" rather than an empty list.

BC-ICP-05. Take payment in ckUSDC with an invoice

Path: /workspace → prompt "charge for tickets in ckUSDC with an invoice at checkout" → Kontext ICP Payments

You do:

1. Accept the Kontext ICP Payments proposal and deploy.
2. At checkout, the app creates an invoice for 12.5 ckUSDC with the order reference.
3. The payer sees the invoice's own deposit address (and its QR) and pays from any wallet.
4. Leave the screen open; it re-checks the invoice every 5 seconds.

Result: The invoice turns paid once the ledger shows the amount on its address, and the funds are swept to the treasury; an unpaid invoice turns expired after its time to live (one hour by default).

BC-ICP-06. Cancel or recheck an invoice

Path: the deployed app → invoices list

You do:

1. Open the invoices list and filter by status.
2. Press check on an open invoice to ask the ledger now.
3. Cancel an invoice that is no longer wanted.

Result: Only an open invoice can be cancelled ("Only an open invoice can be cancelled."); a paid invoice keeps its paid status even if the sweep to the treasury fails.

BC-ICP-07. Launch loyalty points as the app's own token

Path: /workspace → prompt "customers earn loyalty points and redeem them for store credit" → Kontext ICP Ledger

You do:

1. Accept the Kontext ICP Ledger proposal and deploy.
2. As the owner, set the token's name, symbol, fee and an optional supply cap.
3. Mint points to a customer's principal.
4. The customer signs in and sees their balance; they send points to a friend or burn them.

Result: A real ICRC-1 and ICRC-2 token served by the app's canister, readable by ICP wallets; minting past the cap answers "Minting N would pass the supply cap of M."

BC-ICP-08. Adjust the token and review its history

Path: the deployed app → owner controls (token)

You do:

1. As the owner, open the token settings.
2. Change the transfer fee, or set a supply cap.
3. Open the full history to see every mint, burn, transfer and approval.

Result: The new fee applies to the next transfer and is burned; a cap below what has already been minted is refused with "The cap cannot be below the N already minted."

BC-ICP-09. Set up a monthly renewal with one approval

Path: /workspace → prompt "members pay monthly in ckUSDC with auto-renew" → Kontext ICP Pull Payments

You do:

1. Accept the Kontext ICP Pull Payments proposal and deploy.
2. The member signs in and approves the app from their signed-in account for an amount (for example 30 ckUSDC), optionally until a date.
3. They check what they have approved on the allowance screen.
4. When a renewal is due, the app pulls the charge into its treasury.

Result: Each pull appears in the member's pull history; an allowance that is too small returns "The payer approved only N — ask them to approve more".

BC-ICP-10. Pay from an outside ICP wallet

Path: the deployed app → approval screen

You do:

1. Copy the app's canister id shown as the spender.
2. In your own ICP wallet, approve that canister id for an amount on the token's ledger.
3. Return to the app and check the allowance.

Result: The app can now pull up to the approved amount from that wallet's account; nothing moves until a charge is due.

BC-ICP-11. Accept Bitcoin that lands as ckBTC

Path: /workspace → prompt "fans can deposit bitcoin and hold it in the app" → Kontext Bitcoin & Ether Bridge

You do:

1. Accept the proposals (the Bitcoin & Ether Bridge together with ICP Tokens) and deploy.
2. Sign in and open the deposit screen; copy your Bitcoin address or scan its QR.
3. Send BTC to it from any Bitcoin wallet.
4. Press check deposit until the minter mints.

Result: Until the deposit is confirmed the check reports "N deposit(s) pending: X of Y confirmations."; after that it reports the ckBTC minted, which shows as ckBTC in the wallet.

BC-ICP-12. Withdraw ckBTC back to a Bitcoin address

Path: the deployed app → withdraw screen (Bitcoin)

You do:

1. Enter a Bitcoin address and an amount in BTC.
2. Review the estimated Bitcoin fee and minter fee.
3. Confirm; the canister approves the minter from your account and asks it to send.

Result: A ledger block index for the withdrawal; an amount under the minter's minimum answers "Amount too low — the minimum is N sats."

BC-ICP-13. Deposit Ether that lands as ckETH

Path: the deployed app → deposit screen (Ether)

You do:

1. Open the Ether deposit instructions.
2. Note the minter's helper contract on Ethereum and the two bytes32 arguments shown.
3. Call the helper contract's deposit from your Ethereum wallet with those arguments and the ETH amount.

Result: The minter mints ckETH to your app account when it sees the deposit, with no further step in the app; withdrawals go back out to a 0x address.

BC-ICP-14. Sign a hash with a person's threshold key

Path: /workspace → prompt "each user gets a signing key with a threshold key, no private key anywhere" → Kontext Threshold Key

You do:

1. Accept the Kontext Threshold Key proposal and deploy.
2. Sign in and read your public key for a purpose label (for example attestations).
3. Sign a 32-byte hash with that purpose.

Result: A compressed secp256k1 public key and a 64-byte r‖s signature, both hex; there is no private key to show or export, and a hash of the wrong length answers "An ECDSA message hash is exactly 32 bytes."

BC-ICP-15. Use the test key while building

Path: the deployed app → owner controls (threshold key)

You do:

1. As the owner, open the key settings and read the current key and signature count.
2. Switch to test_key_1 while trying things out.
3. Switch back to key_1 before anything of value is signed.

Result: Signatures on test_key_1 cost about 10 billion cycles instead of about 26.2 billion and must never be used for value; any other key name is refused.

BC-EVM-01. Read a balance, a contract or a receipt on any EVM chain

Path: /workspace → prompt "read any address balance on mantle network" → Kontext EVM Reader

You do:

1. Describe the screen and accept the EVM Reader proposal.
2. Deploy, sign in and pick a chain from the list the app shows.
3. Paste an address and read its balance.
4. Run a contract read, which returns the ABI-encoded answer as hex for the screen to decode.
5. Paste a transaction hash to read its receipt.

Result: Each answer comes from several public providers that had to agree (a disagreement shows "providers disagreed … try again" instead of a number), balances are shown by the chain's decimals, and a receipt reads as pending (null) until the transaction is mined.

BC-EVM-02. Add a chain the table does not have

Path: the deployed app → owner controls (EVM chain table)

You do:

1. Sign in as the owner.
2. Enter the chain id, name, native symbol and decimals.
3. Add one or more https RPC URLs and the explorer's transaction prefix.
4. Mark legacy fees if the chain has no EIP-1559 base fee, and save.

Result: The chain appears in the list for the Reader and the Wallet at once (Cross-Chain also needs a row in its own address book); a non-https URL or a missing name is refused, and anyone who is not the owner is told only the owner may change the table.

BC-EVM-03. Send a raw JSON-RPC request as the owner

Path: the deployed app → owner controls (EVM chain table)

You do:

1. Sign in as the owner.
2. Choose a chain and enter a JSON-RPC method such as eth_blockNumber.
3. Enter its parameters as a list and send.

Result: The answer comes back as JSON text through the same provider quorum (capped at 16,384 bytes), and a caller who is not the owner is refused with "Only the owner may send raw RPC requests."

BC-EVM-04. Give every member an address on EVM chains

Path: /workspace → prompt "members can send ETH on Arbitrum to each other" → Kontext EVM Wallet

You do:

1. Accept the EVM Wallet proposal and let the build finish.
2. Deploy, sign in and open the wallet screen.
3. Choose a chain and copy the address or scan its QR.
4. Send some of the chain's coin to it from another wallet.

Result: Each signed-in person has one address, the same on every chain in the table (shown with an xdc prefix on XDC), and the balance reads live from the chain.

BC-EVM-05. Send ETH or USDC from the app

Path: the deployed app → wallet screen (EVM)

You do:

1. Choose the chain and the coin or token to send.
2. Enter the recipient address and a human amount such as 0.05.
3. Press send.
4. Open the explorer link from the pending row and watch for the receipt.

Result: The canister prices the fee, signs with the threshold key and broadcasts; the send shows as pending with its hash until the receipt lands, and too little of the native coin for value plus gas is refused as "Insufficient … for the value plus gas".

BC-EVM-06. Hold MEOW on Z Chain

Path: /workspace → prompt "a z chain wallet so members can hold MEOW" → Kontext EVM Wallet

You do:

1. Accept the EVM Wallet proposal and deploy.
2. Sign in and open the wallet screen on Z Chain.
3. Copy the address and send it Z for gas and some MEOW.
4. Read the MEOW balance, and send MEOW to another address.

Result: The Z balance and the MEOW balance (by MEOW's own 18 decimals) are read from Z Chain, and a MEOW transfer is a pending hash with a zscan.live link until it is mined.

BC-EVM-07. Check and move an ERC-721 NFT

Path: /workspace → prompt "gate the app to wilder nft holders" → Kontext EVM Wallet

You do:

1. Accept the EVM Wallet proposal and deploy.
2. Sign in and enter the collection contract and a token id.
3. Read who owns the token and its metadata URI.
4. As the holder, transfer the token to another address.

Result: Ownership is read from the contract's own ownerOf, a token id that does not exist reads "No such token.", and the transfer is signed from the holder's address and stays pending until mined.

BC-EVM-08. Move USDC to another chain with Circle CCTP

Path: /workspace → prompt "let members bridge USDC to Base" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain (the EVM Wallet it sends from is mounted with it) and deploy.
2. Sign in and hold USDC plus a little of the source chain's coin for gas.
3. Choose the source and destination chains and the USDC amount.
4. Send, then watch the transfer row.

Result: The USDC is burned on the source and minted on the destination after Circle attests; the row moves from burning to attesting to minted and names the mint's hash, and a chain without CCTP (BNB Smart Chain) is refused before anything is signed.

BC-EVM-09. Send a Chainlink CCIP message to another EVM chain

Path: /workspace → prompt "send a ccip message from base to arbitrum when an order ships" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain and deploy.
2. Enter the receiver contract on the destination chain and the message as hex.
3. Quote the fee in the source chain's native coin.
4. Send, then open the transfer on ccip.chain.link.

Result: The message leaves from the app's wallet with the fee paid in the native coin; the row reads sent with the source hash, and delivery is checked on ccip.chain.link rather than inside the app.

BC-EVM-10. Send a CCIP message or tokens to Solana or Aptos

Path: /workspace → prompt "bridge a message to solana from base" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain (the Solana toolkit is proposed beside it) and deploy.
2. Choose Solana or Aptos as the destination.
3. For Solana, give the receiving program, its accounts and compute units, or for a token-only transfer leave the receiver empty, set compute units to 0 and name the receiving wallet.
4. For Aptos, give the 0x receiving address and the destination gas.
5. Quote the fee, then send.

Result: The router quotes and accepts the send in the source chain's native coin and the row reads sent with a ccip.chain.link link, while a lane the router does not serve is refused with "the lane may not be open".

BC-EVM-11. Send an OFT token with LayerZero

Path: /workspace → prompt "send our OFT token to arbitrum with layerzero" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain and deploy.
2. Enter the OFT contract, the destination chain, the amount and the recipient.
3. Read the quoted native fee.
4. Send, then watch the transfer row or open LayerZero Scan.

Result: An adapter OFT is approved first, the send pays the quoted fee, and the row stays INFLIGHT until LayerZero Scan reports the delivery status and the destination hash.

BC-EVM-12. Bridge a token through Wormhole

Path: /workspace → prompt "bridge tokens to avalanche with wormhole" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain and deploy.
2. Choose the source and destination chains, and a token (or none, for the native coin).
3. Enter the amount and send.
4. Watch the transfer row; it can also be followed on Wormholescan.

Result: The source leg is locked or wrapped and the row reads awaiting_vaa until the guardians sign; the app then redeems it on the destination by itself and the row reads redeemed with the destination hash, and a chain without the token bridge (Linea) is refused up front.

BC-EVM-13. Call a contract on another chain with Axelar

Path: /workspace → prompt "call our vault contract on polygon through axelar gmp" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain and deploy.
2. Get a gas quote for the route from Axelarscan.
3. Enter the destination contract and the payload as hex, and send with the quoted gas.
4. Watch the transfer row or open Axelarscan.

Result: The call goes out first and the gas is paid in a second transaction, so the row moves from called to gas_paid and then to Axelarscan's own status, with the destination hash once executed.

BC-EVM-14. Send a Hyperlane message to a contract on another chain

Path: /workspace → prompt "send a hyperlane message from base to arbitrum when an order ships" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain and deploy.
2. Enter the receiving contract (one that implements handle()) and the message body as hex.
3. Read the fee the source Mailbox quotes.
4. Send, then watch the transfer row.

Result: The row stays INFLIGHT with the message id until the destination chain's Mailbox itself reports the message delivered, and the explorer link finds it by message id.

BC-EVM-15. Show a live price from Chainlink or Pyth

Path: /workspace → prompt "show the ETH price from a Chainlink price feed" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain and deploy.
2. Sign in and choose the chain and the pair, such as ETH/USD.
3. Read the price and when it last updated.
4. Optionally read the Pyth price for the same asset and its age.

Result: The Chainlink answer is shown scaled by the feed's decimals with its update time, the Pyth price is shown with its age in seconds (it can be old), and a pair the book does not know is refused with a request for the feed's address.

BC-EVM-16. Resolve a ZNS name on Z Chain

Path: /workspace → prompt "resolve each member zns name to their address" → Kontext Cross-Chain

You do:

1. Accept Cross-Chain and deploy.
2. Sign in and enter a name such as wilder.frank.
3. Read the result.

Result: A registered name shows its owner, resolver, the address and text it points to and its domain NFT's URI; a name nobody holds shows as not registered, never as an empty owner.

BC-EVM-17. Turn on Hyperliquid trading with guardrails

Path: /workspace → prompt "trade perps on btc with a daily limit" → Kontext Hyperliquid Trading

You do:

1. Accept Hyperliquid Trading (it brings the EVM Wallet in owner scope) and deploy.
2. Sign in as the owner and open the guardrails form.
3. Set a per-order and a daily USD ceiling, the allowed markets such as BTC and ETH, and a maximum leverage.
4. Choose whether others' orders need your approval and the market-order slippage, then switch trading on.

Result: Trading is enabled only once both ceilings, at least one market and a leverage are set (otherwise the save is refused with what is missing), and everyone else sees trading as not enabled until then.

BC-EVM-18. Fund the trading account and read it

Path: the deployed app → owner controls (Hyperliquid)

You do:

1. Copy the trading account's address, which is the app's EVM treasury address.
2. Send USDC to it through Hyperliquid's Arbitrum bridge.
3. Wait for the account panel to refresh (it reads every 20 seconds).
4. Read the account value, withdrawable USDC, positions and open orders.

Result: The panel shows the account read from Hyperliquid's own API; before any deposit it shows an account value of 0, which means not funded rather than empty.

BC-EVM-19. Place a market or limit order

Path: the deployed app → trading screen (Hyperliquid)

You do:

1. Pick an allowed market and read its mid price.
2. Choose buy or sell, enter a size, and enter a price or choose market.
3. Place the order.
4. Watch it in the order history and open orders.

Result: The owner's order is placed at once and shows as resting or filled, and an order that breaks a guardrail (market not allowed, under $10, over the per-order or daily ceiling) is refused with the reason before anything is signed.

BC-EVM-20. Approve an order a member proposed

Path: /workspace → prompt "a hyperliquid bot that members can propose trades to" → Kontext Hyperliquid Trading

You do:

1. Build the app so signed-in members may propose orders, and deploy.
2. A member places an order, which shows as awaiting approval.
3. Sign in as the owner and open the order history.
4. Approve or reject the waiting order.

Result: An approved order is checked again against the guardrails and the day's total at that moment before it is placed, and a rejected one is kept in history as rejected.

BC-BTC-01. Give every member a native Bitcoin address

Path: /workspace → prompt "every member gets a bitcoin wallet and can send btc" → Kontext Bitcoin Wallet

You do:

1. Describe the app and say the bitcoin should stay native, not ckBTC.
2. Accept the Bitcoin Wallet proposal and let the build finish.
3. Deploy, sign in to the app and open the wallet screen.
4. Copy the bc1 address or scan its QR, and send it some bitcoin from another wallet.
5. Refresh the balance after the deposit has one confirmation.

Result: Each signed-in person has their own bc1q address derived from the threshold key, and the balance shows confirmed bitcoin read from the IC's Bitcoin API (unconfirmed deposits are not counted yet).

BC-BTC-02. Send bitcoin from the app

Path: the deployed app → wallet screen (Bitcoin)

You do:

1. Check the fee rate the screen shows in sat/vB.
2. Enter a bc1q or bc1p recipient address and an amount in BTC.
3. Press send.
4. Open the transaction on mempool.space from the history row.

Result: The canister selects coins, signs each input with the threshold key and broadcasts through the IC; history shows the txid as sent and it stays unconfirmed until the network confirms it, while an amount under 546 satoshis, a wrong-network address or too little confirmed bitcoin is refused before anything is signed.

BC-BTC-03. Choose native BTC or ckBTC

Path: /workspace → prompt "pay out in bitcoin" → Kontext Bitcoin Wallet

You do:

1. Decide whether the bitcoin should stay on the Bitcoin network or land in the app's ICP wallet as ckBTC.
2. For native bitcoin, use wallet or payout words such as "bitcoin wallet" or "pay out in bitcoin".
3. For ckBTC, use deposit words such as "deposit bitcoin"; the bridge is proposed with the ICP wallet.
4. Read the proposal card before accepting; when both fit, both are proposed side by side.

Result: The toolkit that is wired matches the shape asked for: a bc1 wallet on the Bitcoin network, or a ckBTC deposit address that credits the ICP wallet 1:1.

BC-BTC-04. Inscribe an ordinal from the app

Path: /workspace → prompt "members can inscribe ordinals from their own taproot wallet" → Kontext Ordinals, Runes & BRC-20

You do:

1. Accept the Ordinals proposal, then deploy and sign in.
2. Open the vault screen; note both addresses, the vault (bc1p) and the payment address (bc1q).
3. Send bitcoin to the payment address, since it pays every fee.
4. Choose a content type and the content (up to 60,000 bytes), then inscribe.
5. Watch the history row move from sent to pending to confirmed.

Result: The canister broadcasts a commit and a reveal on Bitcoin and returns the inscription id; the inscription appears in the vault once ord indexes it, and until then the vault view says some new outputs are not indexed yet.

BC-BTC-05. Send an inscription or runes to someone else

Path: the deployed app → vault screen (Ordinals)

You do:

1. Pick an inscription the vault holds, or a rune and an amount.
2. Enter the recipient's Taproot (bc1p) address.
3. Send, and leave the rune id empty to have it looked up by name.
4. Check the history row until it confirms.

Result: The inscription or runes move to the recipient with fees paid only from clean payment outputs; a non-Taproot address is refused, and a partial rune send without the platform indexer key says the indexer is not configured.

BC-BTC-06. Move BRC-20 tokens in two steps

Path: the deployed app → vault screen (BRC-20)

You do:

1. Enter the ticker (4 or 5 characters) and read its available, transferable and overall balance.
2. Inscribe a transfer for the amount; it is refused if the available balance does not cover it.
3. Wait for the reveal to confirm in history.
4. Send that transfer inscription to the recipient's Taproot address.

Result: The BRC-20 amount moves when the transfer inscription is sent; without UNISAT_API_KEY on the platform the balance and the transfer both say the indexer is not configured, never zero.

BC-BTC-07. Connect your LNbits wallet and set limits

Path: the deployed app → owner controls (Lightning)

You do:

1. In LNbits, open the wallet and copy its instance URL, invoice key and admin key.
2. Paste the URL and the invoice key; add the admin key only if the app should pay.
3. Save; both keys are checked against the instance before they are kept.
4. Set a per-payment limit and a daily limit in sats.

Result: The app shows the wallet as connected and able to pay; with no admin key it stays receive-only, and with no limits every payment is refused with "Payments are off until the owner sets a per-payment and a daily limit."

BC-BTC-08. Take a Lightning tip

Path: /workspace → prompt "add a lightning tip jar" → Kontext Lightning Payments

You do:

1. Accept the Lightning proposal and deploy, then connect your LNbits wallet as the owner.
2. As a visitor, sign in and ask for an invoice of an amount in sats.
3. Scan the QR, or copy the bolt11, into any Lightning wallet and pay it.
4. Watch the invoice in the list.

Result: The invoice turns paid once LNbits reports it paid, or expired if nobody pays before its expiry; until the owner connects a wallet the screen says Lightning is not set up.

BC-BTC-09. Pay a Lightning invoice as the owner

Path: the deployed app → owner controls (Lightning)

You do:

1. Paste a bolt11 invoice and decode it to see its amount, expiry and description.
2. Press pay.
3. If the entry shows unknown, refresh it before trying anything else.

Result: The payment goes through LNbits inside your limits; an invoice with no amount, an expired one, one over a limit, one the wallet cannot cover, or one already paid is refused by name before the admin key is used.

BC-BTC-10. Give members a Stacks wallet

Path: /workspace → prompt "members get a stacks wallet and can send stx" → Kontext Stacks Wallet

You do:

1. Accept the Stacks proposal and deploy.
2. Sign in and open the wallet screen to see your SP address and its QR.
3. Send STX to it from another wallet.
4. Refresh the balance.

Result: Each signed-in person has an SP address from the threshold key; before any STX arrives the wallet says it is not funded and cannot pay a fee yet, never that it is empty and ready.

BC-BTC-11. Send sBTC or another SIP-010 token

Path: the deployed app → wallet screen (Stacks tokens)

You do:

1. Pick the token (sBTC, ALEX, or a contract id) and check its balance.
2. Enter the recipient's SP address and an amount in the token's decimals.
3. Send.
4. Follow the history row until it leaves pending.

Result: The transfer is sent in deny mode with an exact post-condition naming the asset read from the contract, so the history shows success or abort_by_post_condition by name; a fee above the owner's cap is refused before signing.

BC-BTC-12. Call a Clarity contract from the app

Path: the deployed app → a screen built on a Clarity contract (Stacks)

You do:

1. Read contract state with a read-only function; the node answers for free.
2. Make a write call with the arguments and any post-conditions for what it may move.
3. Wait for the history row to settle.

Result: The call is signed by the canister and broadcast; if it tries to move an asset it did not declare it aborts on-chain instead, and the history says abort_by_post_condition or abort_by_response rather than success.

BC-CHN-01. Give every member a Solana wallet for USDC

Path: /workspace → prompt "members hold USDC on Solana and send it to each other" → Kontext Solana Wallet

You do:

1. Describe the job in Workspace Chat and accept the Kontext Solana Wallet proposal.
2. Deploy the app and sign in.
3. Open the wallet screen and copy your base58 address.
4. Send SOL for fees and USDC to that address from another wallet.
5. Enter a recipient's wallet address and an amount, then send USDC.

Result: The send returns a signature that shows as sent until the cluster reports confirmed or finalized; the recipient's token account is created if they never held USDC, and a USDC balance for someone who never held it shows an error rather than zero.

BC-CHN-02. Send LINK from Solana to Ethereum over CCIP

Path: the deployed app → wallet screen (Solana, CCIP)

You do:

1. Make sure the Solana address holds LINK and enough SOL for the fee.
2. Pick Ethereum as the destination and enter the receiving 0x address.
3. Enter the amount and read the fee quote in SOL.
4. Confirm the send.
5. Open the returned signature on ccip.chain.link to follow delivery.

Result: The canister approves and sends in one transaction; if SOL is under the fee plus 5,000 lamports or the LINK balance is short, it refuses with "Not funded" before anything is signed, and a mint with no CCIP pool is refused by name.

BC-CHN-03. Point the Solana wallet at Devnet for testing

Path: the deployed app → owner controls (Solana)

You do:

1. Sign in as the app owner.
2. Switch the cluster to Devnet.
3. Optionally enter your own https RPC endpoints; they must agree with each other.
4. Refresh the balance on the wallet screen.

Result: Reads and sends go to Devnet (or to your endpoints); a URL that is not https is refused, and non-owners are told only the owner may switch clusters.

BC-CHN-04. Pay contributors in USDC on Stellar

Path: /workspace → prompt "pay contributors in USDC on Stellar from a treasury wallet" → Kontext Stellar Wallet

You do:

1. Describe the job and accept the Kontext Stellar Wallet proposal.
2. Deploy and sign in as the owner, then copy the treasury's G… address.
3. Send at least 1 XLM to it so the account exists, then add USDC.
4. Pick USDC from the balance list, enter a contributor's G… address, an amount and an optional memo.
5. Send, then watch the payment in the history list.

Result: The payment shows as sent until Horizon reports it confirmed in a ledger; before the account holds 1 XLM, balances are an empty list and a send is refused as not funded yet.

BC-CHN-05. Open a new Stellar account with its first payment

Path: the deployed app → wallet screen (Stellar)

You do:

1. Enter the address of a Stellar account that has never been funded.
2. Enter an amount of XLM of at least 1.
3. Send.
4. Look the recipient up with the balance check for any address.

Result: The payment is submitted as a create-account and the new account appears with that XLM; less than 1 XLM, or an issued asset, to a missing account is refused with the reason.

BC-CHN-06. Hold ATOM and move it to Osmosis over IBC

Path: /workspace → prompt "members send atom and do ibc transfers to osmosis" → Kontext Cosmos Wallet

You do:

1. Accept the Kontext Cosmos Wallet proposal and deploy.
2. Sign in and open the wallet screen on Cosmos Hub; copy your cosmos1… address.
3. Send ATOM to it from another wallet so it can pay fees.
4. Start an IBC transfer on channel-141 to your osmo1… address with an amount.
5. Watch the transfer in the history list.

Result: The transfer shows as sent until the Hub reports it in a block as confirmed; before the address has received anything, the send is refused because it cannot pay a fee yet.

BC-CHN-07. Add a Cosmos chain the app does not know yet

Path: the deployed app → owner controls (Cosmos chains)

You do:

1. Sign in as the app owner.
2. Add a chain row with its chain id, bech32 prefix, fee denom, symbol, decimals, https REST host and minimum gas price.
3. Optionally make it the default chain.
4. Open the wallet screen and pick the new chain.

Result: Every signed-in person gets an address on the new chain from the same key; a REST host that is not https, or a row without a chain id, prefix, fee denom or gas price, is refused.

BC-CHN-08. Give each person a Sui address and send SUI

Path: /workspace → prompt "every member gets a sui wallet and can send sui" → Kontext Sui Wallet

You do:

1. Accept the Kontext Sui Wallet proposal and deploy.
2. Sign in and open the wallet screen; copy your 0x… address.
3. Send SUI to it from another wallet.
4. Enter a recipient's 0x… address and an amount, then send.

Result: The send returns a digest that shows as sent until the node reports success; a wallet with no SUI is refused as holding no SUI yet, and an amount that leaves no room for the 0.005 SUI gas budget is refused as not enough SUI.

BC-CHN-09. Use your own Sui node

Path: the deployed app → owner controls (Sui)

You do:

1. Sign in as the app owner.
2. Switch to testnet if you are testing.
3. Enter your own https JSON-RPC URL.
4. Refresh the balance on the wallet screen.

Result: Reads and sends go through your node; a URL that is not https is refused, and an empty URL returns to the publicnode default.

BC-CHN-10. Pay out in APT, including to people with no Aptos account yet

Path: /workspace → prompt "an aptos wallet that pays out apt to members" → Kontext Aptos Wallet

You do:

1. Accept the Kontext Aptos Wallet proposal and deploy.
2. Sign in, open the wallet screen and copy your 0x… address.
3. Send APT to it from another wallet.
4. Enter a recipient's 0x… address, even one that has never been used, and an amount.
5. Send and watch the history list.

Result: The send shows as pending until the node reports success, and the recipient's account is created by the transfer; a balance that cannot cover the amount plus the gas ceiling is refused as not enough APT before anything is signed.

BC-CHN-11. Send a CCIP message from Aptos to Base

Path: the deployed app → wallet screen (Aptos, CCIP)

You do:

1. Make sure the Aptos address holds APT.
2. Pick Base as the destination and enter the receiving contract's 0x address and the message data.
3. Read the fee quote in octas.
4. Send the message.
5. Follow it on ccip.chain.link with the returned hash.

Result: The router takes the message and the fee in APT; if the balance is under the fee plus the gas ceiling it is refused as not enough APT, and an empty message is refused because token transfers from Aptos are not built.

BC-CHN-12. Fund a NEAR implicit account and send NEAR

Path: /workspace → prompt "members get a near wallet and can send near to alice.near" → Kontext NEAR Wallet

You do:

1. Accept the Kontext NEAR Wallet proposal and deploy.
2. Sign in, open the wallet screen and copy your 64-character implicit account.
3. Send NEAR to it from another wallet; the transfer creates the account.
4. Enter alice.near (or another account) and an amount, then send.

Result: The transfer shows as pending until the node reports success; before the account has received NEAR its balance reads 0 and a send is refused as not funded yet.

BC-CHN-13. Call a NEAR contract with a deposit

Path: the deployed app → a screen that calls a contract (NEAR)

You do:

1. Enter the contract's account id and the method name.
2. Enter the arguments as JSON.
3. Set the gas (1 to 300 TGas) and any deposit in NEAR.
4. Submit the call and open it in the history list.

Result: The call is signed by the canister and shows as pending until the node reports success or failure; arguments that are not JSON, or gas outside 1 to 300 TGas, are refused before anything is signed.

BC-CHN-14. Pay out XRP with a destination tag

Path: /workspace → prompt "pay suppliers in xrp with a destination tag" → Kontext XRP Ledger Wallet

You do:

1. Accept the Kontext XRP Ledger Wallet proposal and deploy.
2. Sign in, open the wallet screen and copy your r-address.
3. Send at least the base reserve (1 XRP today) plus spending money to it from another wallet.
4. Enter the supplier's r-address, the amount, their destination tag and an optional memo.
5. Send and watch the payment in the history list.

Result: The payment shows as pending until the ledger validates it; before the wallet has received the reserve it reads 0 and a send is refused as not on the ledger yet.

BC-CHN-15. Create a new XRP Ledger account with a first payment

Path: the deployed app → wallet screen (XRP Ledger)

You do:

1. Enter an r-address that has never been funded.
2. Enter an amount of at least the base reserve.
3. Send.
4. Check the new address with the balance check for any address.

Result: The payment creates the account once validated; an amount below the reserve is refused before signing with the reserve named in drops.

BC-CHX-01. Open a Hedera account for each member

Path: /workspace → prompt "give every member an hbar wallet" → Kontext Hedera Account

You do:

1. Accept the Hedera proposal and deploy the app.
2. Sign in to the app and open the wallet screen.
3. Copy the alias shown (0.0.) and send some HBAR to it from any Hedera wallet.
4. Wait for the screen to re-check; the account id 0.0.N appears beside the alias.
5. Send HBAR to another account id, with an optional memo.

Result: The alias becomes a real Hedera account the moment HBAR reaches it, and the send shows as UNKNOWN until the node's receipt reports SUCCESS or names the failure; before funding, a send is refused with the alias to fund rather than attempted.

BC-CHX-02. Create a loyalty token on Hedera

Path: /workspace → prompt "create a hedera token for loyalty points" → Kontext Hedera Account

You do:

1. Accept the proposal and deploy; fund the account that will create the token with HBAR.
2. Create a fungible token with a name, symbol, decimals and initial supply.
3. Refresh the record until it shows SUCCESS and the new token id.
4. Mint more units later, or send units to a member's 0.0.N account.

Result: A new HTS token with the creating account as treasury and supply key; the token id is filled in from the mirror node on refresh, and a receiver with no association and no free automatic slot is refused as TOKEN_NOT_ASSOCIATED_TO_ACCOUNT.

BC-CHX-03. Mint NFTs on Hedera and give one away

Path: /workspace → prompt "mint nfts on hedera for event tickets" → Kontext Hedera Account

You do:

1. Accept the proposal, deploy and fund the account with HBAR.
2. Create an NFT collection (no decimals, no initial supply; set a maximum supply if the run is capped).
3. Mint serials, one metadata URI of up to 100 bytes per serial, up to ten at a time.
4. Send a serial to a member's 0.0.N account.
5. Open the NFT list to see what the account still holds.

Result: The serials exist on Hedera and move between accounts; more than ten per call or metadata over 100 bytes is refused before signing, with the reason.

BC-CHX-04. Record events on a Hedera Consensus Service topic

Path: /workspace → prompt "log each approval to an hcs topic" → Kontext Hedera Account

You do:

1. Accept the proposal, deploy and fund the account with HBAR.
2. Give the app the id of an existing topic (0.0.N).
3. Post a message of up to 1,024 bytes.
4. Open the topic view to read the latest messages, newest first.

Result: Each message is ordered and timestamped by Hedera and read back from the mirror node with its sequence number; a topic id that does not exist is reported as such.

BC-CHX-05. Pay members in ALGO

Path: /workspace → prompt "members get an algorand wallet and can send algo to each other" → Kontext Algorand Wallet

You do:

1. Accept the Algorand proposal and deploy.
2. Sign in, open the wallet screen and copy your address (or scan its QR code).
3. Fund it with ALGO from another wallet and wait for the balance to update.
4. Send an amount to another member's address, with an optional note.
5. Watch the history row move from pending to confirmed.

Result: ALGO leaves the canister-held address and the row shows confirmed with its round; a send that would dip under the 0.1 ALGO minimum balance is refused as Not funded before anything is signed.

BC-CHX-06. Accept USDC on Algorand

Path: /workspace → prompt "accept usdc on algorand" → Kontext Algorand Wallet

You do:

1. Accept the proposal and deploy; fund the address with a little more than 0.2 ALGO (the minimum balance, the opt-in and the fee).
2. Opt the address in to USDC (asset 31566704).
3. Share the address with the payer.
4. Refresh the balance to see the USDC holding.
5. Send USDC onward to another address that has also opted in.

Result: The account holds USDC once opted in; sending to an address that has not opted in is refused with the reason, because Algorand would reject it after taking the fee.

BC-CHX-07. Take USDT on TRON

Path: /workspace → prompt "customers pay in usdt on tron" → Kontext TRON Wallet

You do:

1. Accept the TRON proposal and deploy.
2. Sign in and open the wallet screen; the T address shows as not activated.
3. Send some TRX to it so it exists on TRON and can pay for energy.
4. Share the address with the payer and refresh the USDT balance after they pay.
5. Send USDT onward; the canister simulates it before signing.

Result: USDT arrives and can be moved from the canister-held address; a transfer the contract would revert, or one whose energy exceeds the owner's fee cap, is refused with the reason and no TRX is burned.

BC-CHX-08. Send TRX and follow it to confirmation

Path: /workspace → prompt "a trx wallet for each member" → Kontext TRON Wallet

You do:

1. Accept the proposal, deploy and fund your address with TRX.
2. Enter a recipient's T address and an amount.
3. Send, then watch the history row.
4. Open the Tronscan link on the row.

Result: The row moves from sent to included to confirmed once the block is solidified, or reads expired if no block took it; sending to an address that is not yet activated costs extra TRX to create it, and that is included in the funding check.

BC-CHX-09. Hold and send DOT on Asset Hub

Path: /workspace → prompt "a polkadot wallet so members can send dot" → Kontext Polkadot Wallet

You do:

1. Accept the Polkadot proposal and deploy.
2. Sign in and copy your address (it starts with 1).
3. Send at least 0.01 DOT to it from another wallet on Polkadot Asset Hub.
4. Send DOT to another address; the fee is quoted first.
5. Watch the history row go from sent to included to finalized.

Result: The transfer is validated by the node before submission and tracked to finalized by the account's nonce; the first transfer to an account that does not exist yet must be at least 0.01 DOT or it is refused with that reason.

BC-CHX-10. Pay out USDT on Polkadot

Path: /workspace → prompt "pay contributors in usdt on polkadot" → Kontext Polkadot Wallet

You do:

1. Accept the proposal and deploy; the owner controls whether the app is on mainnet or the Paseo testnet.
2. Fund the wallet with DOT for fees and with USDT (asset 1984).
3. Enter a recipient address and a USDT amount.
4. Send and follow the history row.

Result: USDT moves on Asset Hub with the fee paid in DOT; an amount that would leave the sender under USDT's minimum balance, or a first transfer below it, is refused with the reason before anything is signed.

BC-CHX-11. Accept ADA payments

Path: /workspace → prompt "let customers pay in ada" → Kontext Cardano Wallet

You do:

1. Accept the Cardano proposal and deploy.
2. Sign in and copy the addr1 address (or show its QR code to the payer).
3. Wait for the payment, then refresh the balance.
4. Send ADA onward to another address, at least the minimum output.
5. Follow the history row until it reads confirmed.

Result: The balance updates once ADA arrives and a send is confirmed after 10 confirmations; before the first deposit the screen says the address has never received ADA rather than showing an error, and an amount under the minimum output is refused with the minimum stated.

BC-CHX-12. Try a Cardano wallet on preprod first

Path: the deployed app → owner controls (Cardano)

You do:

1. As the owner, switch the Cardano network to testnet (preprod).
2. Copy the wallet's addr_test address and fund it with preprod test ADA.
3. Send test ADA to another preprod address and watch it confirm.
4. Switch back to mainnet when the flow works.

Result: The same wallet works on preprod with addr_test addresses and Cardanoscan's preprod explorer; an address for the other network is refused with which network it belongs to.

BC-CHX-13. Give each member a TON wallet

Path: /workspace → prompt "members get a ton wallet and can send toncoin" → Kontext TON Wallet

You do:

1. Accept the TON proposal and deploy.
2. Sign in and copy your UQ address; the wallet reads as not deployed.
3. Fund it with TON from another wallet.
4. Send TON to another address with a short comment.
5. Watch the history row move from sent to confirmed.

Result: The first send also deploys the wallet contract, and its fee is included in the funding check; sending to a bounceable address with no contract behind it is refused with the non-bounceable form to use, so the coins do not bounce.

BC-CHX-14. Pay out USDT on TON

Path: /workspace → prompt "pay creators in usdt on ton" → Kontext TON Wallet

You do:

1. Accept the proposal, deploy and fund the wallet with TON for fees.
2. Receive USDT into the wallet and refresh the jetton balance.
3. Enter a recipient and an amount and send.
4. Follow the history row until it reads confirmed.

Result: The USDT moves through the jetton contracts with 0.05 TON attached for their gas (the unused part returns); a wallet that holds none of the jetton, or too little, is refused before anything is signed.

BC-CHX-15. Send EGLD and ESDT tokens

Path: /workspace → prompt "members can send egld and esdt tokens" → Kontext MultiversX Wallet

You do:

1. Accept the MultiversX proposal and deploy.
2. Sign in and copy your erd1 address; it reads as not funded.
3. Send it some EGLD from another wallet so it can pay fees.
4. Send EGLD, or send USDC by its token identifier, to another erd1 address.
5. Watch the history row move from pending to success.

Result: The transfer is signed in the canister and tracked to success, fail or invalid as the API reports it; a transfer whose fee exceeds the owner's cap, or that the wallet cannot cover, is refused with the amounts stated.

BC-CHX-16. Call a MultiversX smart contract from the app

Path: /workspace → prompt "call our multiversx smart contract when a member claims" → Kontext MultiversX Wallet

You do:

1. Accept the proposal, deploy and fund the calling wallet with EGLD.
2. Give the app the contract's erd1 address and the function name.
3. Pass the arguments (numbers, text or hex) and any EGLD to attach.
4. Send the call and follow its history row.

Result: The gas is simulated before signing and the call runs on MultiversX; a call the contract would refuse comes back with the contract's own message and nothing is sent.

BC-STO-01. Give each member a Filecoin wallet and send FIL

Path: /workspace → prompt "members get a filecoin wallet and can send fil to each other" → Filecoin Wallet & Storage

You do:

1. Accept the Filecoin Wallet & Storage proposal and deploy the app.
2. Sign in and open the wallet screen; your f1 address and FIL balance appear.
3. Send some FIL to that address from another wallet, then refresh the balance.
4. Enter a recipient (f1, f410f, f0 or 0x address) and an amount, and send.
5. Watch the message in the history list until it settles.

Result: The message is signed by the canister and moves from pending to success or failed (exit N); an address that never received FIL shows as not funded and a send from it is refused before anything is signed.

BC-STO-02. Connect Lighthouse and back files up to Filecoin

Path: the deployed app → owner controls (Filecoin storage)

You do:

1. Paste your Lighthouse API key; the canister checks it with Lighthouse before keeping it.
2. Choose whether signed-in people may store files or only you, and set the largest file allowed (up to 1.8 MB).
3. Store a file from the app's upload screen.
4. Open the stored file's link and its deal status.

Result: The file gets a CID and a Lighthouse gateway link; its deal list stays empty (no deal yet) until Lighthouse makes deals over the following hours to days, and deals are labelled as reported by Lighthouse.

BC-STO-03. Let members store their own files on Filecoin

Path: the deployed app → file storage screen (Filecoin)

You do:

1. As the owner, connect Lighthouse and set the store policy to open for signed-in people.
2. A member signs in and opens the storage screen.
3. The member picks a file under the per-file cap and stores it.
4. The member opens their stored-files list and checks the deal status of the new CID.

Result: The file is stored on the owner's Lighthouse account and appears in the member's own list with its CID and gateway link (the owner sees every member's files); while the policy is closed, a member's store is refused with "Only the owner may store files on Filecoin in this app."

BC-STO-04. Archive a record permanently on Arweave

Path: /workspace → prompt "keep a permanent archive of signed contracts on arweave" → Arweave & AO

You do:

1. Accept the Arweave & AO proposal and deploy the app.
2. As the owner, open the archive screen and pick a file under 1.5 MB.
3. Store it; the app shows the new item id with its gateway link.
4. Open the link, then check the item's status later.

Result: The item is signed by the canister and served by the Turbo gateway at once, shows as bundled until arweave.net reports confirmations, and can be read by anyone by its id forever.

BC-STO-05. Store a larger file by funding Turbo credits

Path: the deployed app → owner controls (Arweave)

You do:

1. Open the Arweave owner screen and note the signing address and its credits.
2. Try to store a file larger than the free tier while credits are 0.
3. Read the refusal, which names the address to fund.
4. Buy Turbo credits for that Ethereum address at payment.ardrive.io.
5. Store the file again.

Result: With credits at 0 the upload is refused with the funding note rather than failing silently; once the address holds Turbo credits, the larger item uploads and gets its id.

BC-STO-06. Message an AO process and read its answer

Path: the deployed app → AO screen

You do:

1. Enter the AO process id and an Action, with any data and tags.
2. Dry-run it to read the process without committing anything.
3. Send it as a real message; the app shows the message id.
4. Ask for the message's result.

Result: The dry-run and the result come back from the compute unit as the process's Messages and Output; if the unit does not serve that process, the app says so by name ("not found in whitelist") and the owner can point it at another unit.

BC-STO-07. Keep app settings and a public log on Aleph

Path: /workspace → prompt "save the app's settings and an activity log on aleph cloud" → Aleph Cloud

You do:

1. Accept the Aleph Cloud proposal and deploy the app.
2. As the owner, save the settings screen; the app writes them as the aggregate key you chose.
3. Record an activity entry; the app appends it as a post of its type.
4. Reload the app and open the settings and the activity list.

Result: The settings come back from the aggregate and the entries from the account's posts, newest first; both were free to publish and each message shows processed or pending in the history.

BC-STO-08. Fund the account and store a file on Aleph

Path: the deployed app → owner controls (Aleph)

You do:

1. Open the Aleph owner screen and copy the account's 0x address.
2. Check the balance; with no ALEPH and no credits it shows as not funded.
3. Send ALEPH to that Ethereum address.
4. Store a file of up to 1.5 MB.
5. Open its link by hash.

Result: The file is stored and addressed by its sha256 and anyone can fetch it from the Aleph API; before funding, the store is refused by name and nothing is signed.

BC-STO-09. Run a function on Aleph compute

Path: the deployed app → owner controls (Aleph compute)

You do:

1. Store the code archive (a zip) through the app; note its hash.
2. Deploy it as a program with its entrypoint (for example main:app).
3. Wait for the allocation to show the node it was placed on.
4. Check what it costs, then open its address.

Result: The program answers HTTP at aleph.sh/vm/ followed by its hash once the scheduler places it, paid by the ALEPH held on the account; an account with no ALEPH or credits is refused before the message is signed.

BC-STO-10. Forget something the app published

Path: the deployed app → owner controls (Aleph history)

You do:

1. Open the list of what the app published.
2. Pick one or more messages to remove.
3. Give a reason, optionally, and forget them.
4. Refresh the status of the original message.

Result: A FORGET message signed by the same account is sent, and the original message's status reads forgotten once the network processes it.

BC-STO-11. Deploy a container on Akash under a price ceiling

Path: /workspace → prompt "let me deploy containers to akash from the app" → Decentralized Compute & AI

You do:

1. Accept the Decentralized Compute & AI proposal and deploy the app.
2. As the owner, paste your Akash Console API key; it is checked with Akash before it is kept.
3. Set the limits: an hourly ceiling, how many deployments may be live, and the longest booking in hours.
4. Browse Akash's GPU prices, then deploy a container image with its port and the hours to book.
5. Wait while it shows awaiting bids, then open its address once it is running.

Result: The canister leases the cheapest Akash bid at or under your ceiling and shows the deployment running with its public address; if no bid that cheap arrives within ten minutes, it is stopped with that reason.

BC-STO-12. Rent a GPU container on io.net

Path: the deployed app → owner controls (Compute, io.net)

You do:

1. Paste your io.net IO Cloud API key.
2. Open the io.net offers and pick a hardware type and a location.
3. Enter the container image, port, number of GPUs and hours.
4. Deploy and watch the status until it runs.

Result: The booking is priced first and refused by name if the hourly price is over your ceiling or no total can be read; otherwise it runs for the booked hours through io.net's own time limit and shows its public address.

BC-STO-13. Run a job on Render Network compute (Dispersed)

Path: the deployed app → owner controls (Compute, Dispersed)

You do:

1. Paste your Dispersed public key and secret key, one per line.
2. Browse the Dispersed offers for the number of GPUs you need.
3. Deploy a container image and port with the hours to book.
4. Refresh the deployment to see its node address.

Result: The job is accepted only when an offer sits at or under your ceiling, every request is signed inside the canister so the secret never leaves it, and a run found billing more than the ceiling is stopped on refresh.

BC-STO-14. Stop a deployment before its time runs out

Path: the deployed app → owner controls (Compute deployments)

You do:

1. Open the list of deployments.
2. Pick a live one and press stop.
3. Refresh the list.

Result: A Fluence VM is terminated by the canister and shows stopping; Akash, io.net and Dispersed are stopped through the stop relay and show stopped, and if the relay cannot be reached the app says so and the deployment still ends at its booked time.

BC-STO-15. Open IO Intelligence chat to members with a daily cap

Path: the deployed app → owner controls (IO Intelligence)

You do:

1. Pick a model from the IO Intelligence list, which needs no key.
2. Paste your IO Intelligence API key; it is checked with a one-token answer.
3. Set the policy: open to signed-in people, the token cap per answer, the daily request cap and the default model.
4. A member asks a question from the app's chat screen.

Result: The member gets an answer from the chosen open model on your io.net account, cut to your token cap; once the day's requests are used the app refuses with "This app has used today's N AI answers." (opening to members works in an app built with the user scope).

BC-KIT-01. Let members connect MetaMask and pay in USDC on Base

Path: /workspace → prompt "let members connect their metamask and pay in USDC on Base" → Kontext EVM Wallet Connect

You do:

1. Describe the job in Workspace Chat, naming the person's own wallet.
2. Review the proposal card and accept the EVM wallet kit; nothing is added to the app's backend.
3. Deploy, open the app and press the button for the wallet the page found.
4. Approve the connection in the wallet, then send the USDC and approve the transfer there.
5. Watch the transfer until its receipt is found, then open the explorer link.

Result: The person paid from their own wallet on Base and paid the gas; the hash shows as pending until the chain returns its receipt, and a browser with no wallet sees "No browser wallet was found" instead of a zero balance.

BC-KIT-02. Gate a members page on holding an NFT

Path: the deployed app → wallet screen (EVM)

You do:

1. Connect the wallet from the app.
2. Open the members page, which checks the connected address against the collection.
3. Read the result: it holds the NFT or it does not.

Result: ERC-721 counts the whole collection, ERC-1155 checks one token id, and a contract that is not an NFT is refused by name rather than read as "holds none".

BC-KIT-03. Take SOL and USDC from a Phantom wallet

Path: /workspace → prompt "connect their phantom wallet to pay in USDC" → Kontext Solana Wallet Connect

You do:

1. Name Phantom (or Solflare, Backpack) in the prompt and accept the Solana wallet kit.
2. Deploy and connect the wallet from the app.
3. Send USDC to the shop's address and approve it in the wallet.
4. Wait for the signature status to read confirmed.

Result: The payment is signed and paid for in the person's wallet; the recipient's token account is created if it was missing, and the transfer stays pending until the status is confirmed.

BC-KIT-04. Send SUI and show a person's Sui NFTs

Path: /workspace → prompt "a sui dapp where people connect their sui wallet and show their collectibles" → Kontext Sui Wallet Connect

You do:

1. Accept the Sui wallet kit and deploy.
2. Connect Slush, Suiet or Nightly from the app.
3. Open the gallery, which lists owned objects that carry a Display name and image.
4. Send one object to another address and approve it in the wallet.

Result: The gallery shows the person's own objects, and the transfer is checked against ownership first, then stays pending until its digest reads success or failed.

BC-KIT-05. Pay in APT or USDC from Petra

Path: /workspace → prompt "connect their petra wallet to pay for tickets" → Kontext Aptos Wallet Connect

You do:

1. Accept the Aptos wallet kit and deploy.
2. Connect Petra (or Nightly, OKX, Pontem) from the app.
3. Send APT or USDC and approve it in the wallet.
4. Watch the transaction status.

Result: The payment runs on whichever network the wallet is on, balances are read exactly through view functions, and the hash stays pending until it reads success or failed.

BC-KIT-06. Accept a Stellar payment through Freighter

Path: /workspace → prompt "let donors connect freighter and give in XLM or USDC" → Kontext Stellar Wallet Connect

You do:

1. Accept the Stellar wallet kit and deploy.
2. Connect Freighter from the app.
3. Enter an amount, an optional memo and the asset, then approve in Freighter.
4. Watch the payment status.

Result: The donor signs in Freighter and pays the fee; a recipient with no trustline for the asset, or a first XLM payment under 1 XLM to a new account, is refused by name before Freighter opens.

BC-KIT-07. Send XRP with a destination tag from GemWallet

Path: /workspace → prompt "connect gemwallet so customers pay in XRP with their destination tag" → Kontext XRP Ledger Wallet Connect

You do:

1. Accept the XRP Ledger wallet kit and deploy.
2. Connect GemWallet from the app.
3. Send XRP with the destination tag and approve in GemWallet.
4. Watch the payment status.

Result: GemWallet submits the payment the person approved; a first payment below the live base reserve, or a token to an account with no trustline, is refused by name first.

BC-KIT-08. Hand over an XRPL NFT in two steps

Path: the deployed app → wallet screen (XRP Ledger)

You do:

1. The holder connects GemWallet and chooses an NFT they hold.
2. The holder creates the transfer offer to the recipient's address and approves it.
3. The recipient connects their own GemWallet, finds the offer and accepts it.

Result: The NFT moves only when the recipient accepts, because the offer is a 0-XRP sell offer that only that recipient can take.

BC-KIT-09. Pay with a NEAR wallet picked in NEAR Connect

Path: /workspace → prompt "a near dapp where fans connect their near wallet and tip in USDC" → Kontext NEAR Wallet Connect

You do:

1. Accept the NEAR wallet kit and deploy.
2. Press connect; NEAR Connect's own selector lists HOT, Meteor, Intear, MyNearWallet and others.
3. Send USDC to a creator's account and approve it in the wallet.

Result: If the creator is not yet registered with the token contract, registration and the transfer go in one transaction; a hash stays pending until it reads success or failed.

BC-KIT-10. Take USDT on TRON from TronLink

Path: /workspace → prompt "connect tronlink and pay in USDT" → Kontext TRON Wallet Connect

You do:

1. Accept the TRON wallet kit and deploy.
2. Connect TronLink from the app.
3. Send USDT; the hook simulates the transfer and reads the energy and bandwidth cost first.
4. Approve it in TronLink and watch the status.

Result: The transfer is confirmed once solidified; a revert, or a burn beyond the TRX the person holds, is refused by name before TronLink opens.

BC-KIT-11. Move USDC from Noble to Osmosis over IBC with Keplr

Path: /workspace → prompt "connect keplr and move noble usdc to osmosis" → Kontext Cosmos Wallet Connect

You do:

1. Accept the Cosmos wallet kit and deploy.
2. Connect Keplr (or Leap) on Noble from the app.
3. Choose Osmosis as the destination and enter the amount.
4. Approve in the wallet after the live simulation passes.

Result: The IBC transfer runs over a channel read live; a refusal from the simulation, or a fee the account cannot pay, is named before the wallet opens.

BC-KIT-12. Upload a file permanently with Wander

Path: /workspace → prompt "let people connect wander and store their poems permanently on arweave" → Kontext Arweave Wallet Connect

You do:

1. Accept the Arweave wallet kit and deploy.
2. Connect Wander from the app.
3. Pick the file and approve the upload in the wallet.
4. Open the permanent link once it settles.

Result: The person signs the upload and it is posted to the Turbo bundler; an upload above the free tier is refused with the reason (the bundler wants Turbo credits) instead of failing silently.

BC-KIT-13. Pay in USDT on TON from Tonkeeper or Telegram Wallet

Path: /workspace → prompt "a telegram mini app wallet checkout: connect tonkeeper and pay in USDT" → Kontext TON Wallet Connect

You do:

1. Accept the TON wallet kit and deploy.
2. Press connect; TON Connect's own picker offers a QR code, a deep link, an extension or Telegram.
3. Send USDT and approve it in the wallet.
4. Watch the status, found by the message hash.

Result: The wallet connects because the platform serves the app's TON Connect manifest for its origin; 0.05 TON travels with the jetton for gas and the unused part comes back.

BC-KIT-14. Gate a Cardano community on a policy id

Path: /workspace → prompt "connect eternl or lace and let holders of our cardano nft in" → Kontext Cardano Wallet Connect

You do:

1. Accept the Cardano wallet kit and deploy.
2. Pick the wallet from the list of CIP-30 wallets the page found.
3. Open the members page, which checks holdings against the policy id.

Result: Holders are let in, and their NFTs show with the CIP-25 or CIP-68 name and image; the holdings are read through Kontext's Cardano service because the public indexer blocks browsers.

BC-KIT-15. Send DOT on Asset Hub from Talisman

Path: /workspace → prompt "connect talisman and send DOT or USDT" → Kontext Polkadot Wallet Connect

You do:

1. Accept the Polkadot wallet kit and deploy.
2. Connect Talisman (or SubWallet, Polkadot{.js}, Nova) and pick an account if several are shared.
3. Send DOT or USDT and approve it in the wallet.
4. Watch the status move from pending to included and finalized.

Result: The send is dry-run on the live runtime and validated by the node first, so a shortfall or an existential-deposit problem is named before anything is submitted.

BC-KIT-16. Build a Bitcoin ordinals gallery with Xverse or Unisat

Path: /workspace → prompt "a bitcoin nft gallery where people connect xverse or unisat and show their ordinals inscriptions" → Kontext Bitcoin Wallet Connect

You do:

1. Accept the Bitcoin wallet kit and deploy.
2. Connect Unisat, Xverse or Leather from the app.
3. Open the gallery, which lists the wallet's inscriptions.
4. Send one inscription to a Taproot address and approve it in the wallet.

Result: The wallet builds and broadcasts the transaction; Leather is refused for inscription sends by name, and an inscription not in the wallet is refused before the wallet opens.

BC-KIT-17. Send sBTC from a Stacks wallet

Path: /workspace → prompt "connect a stacks wallet and send sBTC" → Kontext Stacks Wallet Connect

You do:

1. Accept the Stacks wallet kit and deploy.
2. Connect Leather or Xverse from the app.
3. Send sBTC and approve it in the wallet.
4. Watch the status.

Result: The transfer goes as a contract call in deny mode with an exact post-condition, so it cannot move more than the screen said; an abort still spends the fee and says so.

BC-KIT-18. Send EGLD from the MultiversX Web Wallet

Path: /workspace → prompt "a multiversx dapp where users connect a multiversx wallet and send EGLD" → Kontext MultiversX Wallet Connect

You do:

1. Accept the MultiversX wallet kit and deploy.
2. Press connect and choose the Web Wallet (a popup) or the DeFi Wallet extension.
3. Enter the recipient, the amount and an optional note, then approve in the wallet.
4. Watch the status.

Result: The hook broadcasts the signed transaction and refuses one the wallet changed; status reads pending, success, fail or invalid with a reason.

How it works

• Selection. Each toolkit has phrases that propose it. Every phrase was probed against ordinary prose before it shipped: "the ripple effect" or "sui generis" propose nothing. A keyword only names what the module provides, so browser-extension names map to Lane B kits, never to Lane A modules. Proposals appear as cards; accepting one wires it.
• Seeding. One generic native mount adds the module to the app's Motoko backend, together with the canister methods and a hook. Chain modules pull in what they need (e.g. the EVM wallet implies the threshold key and the EVM reader).
• Signing (Lane A). The canister asks its subnet to sign: ECDSA for Bitcoin, EVM, TRON, Cosmos and Stacks; Schnorr (BIP-340 / Taproot) for Ordinals; Ed25519 for Solana, Sui, Aptos, NEAR, XRPL, Stellar, Hedera, Algorand, Polkadot, Cardano, TON and MultiversX. Filecoin uses secp256k1. Keys derive per app and per principal, so every person has their own address and the treasury is separate.
• Exactness. Each chain's serializer is pinned byte for byte to that chain's own SDK, and the Motoko is executed in the real moc interpreter against recorded vectors; a string check is not enough. Endpoints are live-read before they become defaults, and each is owner-configurable.
• Honest states. An unfunded address is a state, not an error: the module returns the address to fund. A missing key is not configured, and names the key. A network refusal is reported by the network's own name (BUSY, actNotFound…), never as an empty result.
• Two narrow platform services (ZA):
  • Bitcoin indexer route. Read-only BRC-20 balances and rune ids through the UniSat Open API, on one platform key. Hiro's ordinals and runes APIs answer 410 Gone.
  • Compute stop relay (POST /api/compute-relay/stop). A canister outcall can only send GET, POST and HEAD. Akash and io.net stop with DELETE, and Dispersed with PUT. The relay makes exactly that one call:
    • fixed URL templates only;
    • ids validated by shape;
    • only the provider's auth headers forwarded;
    • nothing stored or logged.
• Measured before relying on it:
  • The IC Bitcoin API returns txids in internal (reversed) byte order.
  • Akash runs about 613 blocks an hour.
  • Filecoin message CIDs match a live Lotus node.
  • Lighthouse deal ids do not resolve on-chain.
• Record. docs/engine/BLOCKCHAIN_TOOLKITS_PLAN.md holds the plan and a newest-first log of what each wave measured.

Measured facts, by network

Each line was checked against a live network, the chain's own SDK, or an executed test, and is recorded in docs/engine/BLOCKCHAIN_TOOLKITS_PLAN.md.

App platform and Internet Computer

• ICP mainnet, ckETH minter: minimum_withdrawal_amount exists only inside get_minter_info, not as its own method (read from the live minter's candid on 2026-09-26).
• ICP mainnet, ckETH minter: a deposit routed to a subaccount must go through deposit_with_subaccount_helper_contract_address (depositEth(bytes32, bytes32)); the older principal-only helper cannot route to a subaccount, and the live minter publishes both.
• ICP mainnet, ckBTC minter: the live NoNewUtxos reply also carries suspended_utxos, which the module's decode ignores.
• ICP mainnet, ckBTC and ckETH minters: both interfaces were checked against the live minters' candid:service metadata on 2026-09-26; a variant case the module does not declare would fail to decode, so they are re-read when a minter announces a change.
• ICRC-1 standard: the hooks' textual account encoding reproduces the standard's own example (k2t6j-…-6ae-6cc627i.1) and was cross-checked with Node's zlib.crc32.

Ethereum and EVM networks

• Internet Computer (EVM RPC canister): in its live candid, read 2026-09-26, request is deprecated in favour of multi_request, so the reader calls only multi_request.
• EVM networks (Wave 10a, 2026-09-27): each new default row was read live per provider URL with eth_chainId, the latest block, eth_maxPriorityFeePerGas, eth_gasPrice and a transfer eth_estimateGas. Of the explorers, 19 answered and 15 showed a real recent hash; four Etherscan-family sites answer 403 to a script.
• zkSync Era and Filecoin FEVM: honest providers quote different gas and fees. zkSync Era's transfer estimate was 143,601 against 143,196, and Filecoin's tip was 200,660 / 199,623 / 198,962. This is why fee quotes are reconciled to the highest within twice the lowest instead of requiring agreement.
• Not added as rows, after measurement:
  • Plasma, which had only one fully working public RPC;
  • Moonbeam, where every RPC that answered served a head 48 days old;
  • Fantom Opera, which migrated to Sonic.
• No live send has been measured on the rows added in Wave 10a. That needs a funded threshold address.
• Z Chain (9369): rpc.zchain.org answers eth_chainId 0x2499 and web3_clientVersion cdk-erigon v2.64, making it a Polygon CDK L2 of Ethereum. Blocks carry EIP-1559 fields with a base fee of 0, and zscan.live serves a working Blockscout v2 API.
• Z Chain: MEOW's symbol and 18 decimals were read from the MEOW contract itself (2026-09-27).
• Cross-Chain address book (2026-09-26): 88 entries on the eight chains were checked with eth_getCode plus an identifying view call, and 0 were wrong. Circle's, Axelar's and Wormhole's own address pages agree.
• Circle CCTP: TokenMessenger has no localDomain(), so its identity check is localMessageTransmitter().
• Wormhole (Linea): Linea has a Wormhole core contract (Wormhole chain id 38) and no token bridge.
• Pyth (Ethereum): the on-chain price read live was a month old. On-chain Pyth prices are pushed, so a screen must show their age.
• Hyperlane: the Mailbox address is different on every chain, and the domain id equals the chain id on all eight book chains. Ethereum's Mailbox answers localDomain() = 1 and quoted a dispatch to Base at 20,506,258,777,710 wei. XDC, Hedera and Z Chain have no Hyperlane registry entry.
• Chainlink CCIP directory (2026-09-27): 76 EVM chains, and exactly three non-EVM mainnets: Solana, Aptos and Canton. Canton was dropped, because the router's fee quoter returns InvalidChainFamilySelector for it.
• Chainlink CCIP (Ethereum router), measured live:
  • EVM to Aptos quoted 324,916,072,315,730 wei.
  • EVM to Solana (token-only) quoted 185,695,339,164,321 wei, against 189,379,653,578,301 wei to Base.
  • A receiver of 0x…01 is refused with Invalid32ByteAddress.
• Chainlink CCIP (Aptos router): type_and_version is "Router 1.6.0", and get_dest_chains names all eight book EVM chains. A "hello" message to Ethereum quoted 76,985,823 octas.
• Chainlink CCIP (Solana router): the Motoko-built data message simulates clean on mainnet, with get_fee 5,757,880 lamports and ccip_send using 116,177 compute units. A 1 LINK token send to Ethereum quoted 13,318,877 lamports and used 249,316 compute units, against 249,314 for the Chainlink SDK.
• Chainlink CCIP SDK: @chainlink/ccip-sdk 1.14.0 needs Node 24 or later. The EVM-side extra args were pinned against ethers instead, and confirmed by the Aptos router's live get_fee.
• ZNS (Z Chain): all seven ZNS contracts are verified on zscan.live. The subdomain hash keccak256(parent ‖ keccak256(label)) matches ZNSSubRegistrar.hashWithParent live. ZNSDomainToken.totalSupply() was 0 on 2026-09-27, so every name resolved as not registered.
• Hyperliquid (mainnet and testnet, 2026-09-28): an order signed by the module's bytes from a fresh key came back "User or API Wallet does not exist.", and a withdrawal came back "Must deposit before performing actions. User: ". So the exchange recovered the module's own address.
• Hyperliquid signing: a signature made over the other network's source value recovered to a stranger's address.
• Hyperliquid (SDK): the msgpack, action hashes and EIP-712 digests are executed in the Motoko interpreter against hyperliquid-python-sdk vectors, and the SDK's own signatures recover to the key's address.
• Hyperliquid (browser wallets): a browser wallet refuses the exchange's chainId-1337 typed data. This is why trading from a person's own wallet is not built.

Bitcoin and its layers

• Bitcoin (mainnet): the IC Bitcoin API returns a UTXO's txid in internal byte order. The bytes from bitcoin_get_utxos_query equal mempool.space's txid only when reversed. Every canister send made before fix ZA aedb1e8 (2026-09-28) referenced its inputs by reversed txids and could not have been valid; txidOfUtxo now reverses them.

• Bitcoin: the request shapes for bitcoin_get_balance, bitcoin_get_utxos, bitcoin_get_current_fee_percentiles and bitcoin_send_transaction were taken from the Bitcoin canister's live candid, read 2026-09-26.

• Bitcoin: RIPEMD-160, BIP-173 bech32 addresses and the BIP-143 native-P2WPKH sighash are executed in the real Motoko interpreter against the standards' own vectors. The BIP-143 digest is also recomputed by an independent JavaScript implementation in the test.

• Bitcoin (cost, as stated in the module): about 10B cycles for the UTXO read, 5B plus 20M per byte to broadcast, and about 26B cycles per input signature.

• Bitcoin (Taproot): ordinals encoders run in the real Motoko interpreter against vectors recorded from bitcoinjs-lib, @scure/btc-signer, micro-ordinals and runestone-lib: 23 checks. They cover:

  • the BIP-341 key-path address;
  • the key-path and BIP-143 digests;
  • the ord envelope in 520-byte pushes;
  • the commit under the NUMS key and its control block;
  • runestones.

  @noble's BIP-340 verifies a signature by the tweaked key against the output key the Motoko derived.

• Hiro's ordinals and runes APIs answered 410 Gone (2026-09-27), and ordinals.com's JSON API is disabled. Its recursive /r/ endpoints are open without a key, which is why inscriptions and runes per output are read from ord and BRC-20 balances and rune ids come from the UniSat Open API.

• ord (mainnet): /r/utxo carries runes as {"runes":{"NAME":{"amount","divisibility","symbol"}}}.

• Bitcoin (Taproot): an output key must lie on secp256k1. Coins sent to any other 32 bytes can never be spent, so such an address is refused.

• Lightning (LNbits): the module's API shapes were read from demo.lnbits.com's OpenAPI document on 2026-09-27.

• Lightning (demo.lnbits.com, LNbits 1.6.1rc2): checked live were invoice create, status, decode, wallet read, the pay refusal, and wrong-key and malformed-invoice replies. Those replies are the fixture the decoders run against in the Motoko interpreter: 32 checks.

• Lightning (LNbits): "Insufficient balance." comes back as HTTP 520 with status: "failed", not a 4xx. A definite refusal is therefore read from the body, and a transport error is not treated as one.

• Lightning: the paid path of an outgoing payment has not been observed live, because it needs a funded wallet. It is the one unverified leg.

• Stacks (mainnet): the node's middle fee tier read 0.166 STX for a plain transfer (2026-09-27), skewed by bots paying 1 to 2.5 STX per contract call. Confirmed transfers paid the 180 µSTX minimum the low tier gives, so the wallet uses the low tier.

• Stacks (mainnet): the live network answered NotEnoughFunds for a transaction built by the Motoko module and SignatureValidation for the same transaction with a flipped signature.

• Stacks: c32check addresses, every Clarity value kind, STX / FT / NFT post-conditions, payloads, the SIP-005 sighashes, the signed bytes and the txid match @stacks/transactions 7.x byte for byte, on mainnet and testnet. They are executed in the Motoko interpreter, and @noble verifies the SDK's signature.

Solana, Stellar, Cosmos, Sui, Aptos, NEAR, XRP Ledger

• Solana: the IC SOL RPC canister is tghme-zyaaa-aaaar-qarca-cai; its live candid was read 2026-09-26 and only the generic jsonRequest is used.
• Solana: the associated token address of a fixed owner and the USDC mint, and a 1 SOL transfer message, were matched byte for byte against @noble reference code.
• Solana: a CCIP data message built by the canister simulated clean on the mainnet router; get_fee returned 5,757,880 lamports and ccip_send used 116,177 compute units.
• Solana: a CCIP LINK → Ethereum token transfer (934-byte v0 message) matched @chainlink/ccip-sdk 1.14.0 and simulated clean on mainnet at 249,316 compute units; get_fee for 1 LINK was 13,318,877 lamports.
• Solana: the router's token registry for USDC sets supports_auto_derivation, which is why the USDC pool is refused and LINK is not.
• Solana: publicnode and dRPC do not implement getAssetsByOwner, and Helius and Ankr need a key, so NFT collection listing needs a DAS key.
• Stellar: https://horizon.stellar.org was read live on 2026-09-26 (accounts, /fee_stats, transactions, form-encoded POST /transactions, the 400 and 404 reply shapes).
• Stellar: five transaction envelopes (a memo'd XLM payment, a create-account, USDC, a 12-character asset, a muxed destination) match @stellar/stellar-base 13.1.0 byte for byte in 33 executed vectors.
• Stellar: @noble's Ed25519 verified stellar-base's signature over the hash the Motoko computed, which proves the IC's Ed25519 key signs what Stellar expects.
• Stellar: the public network id is sha256 of "Public Global Stellar Network ; September 2015" (7ac33997…a979), recomputed rather than pinned.
• Cosmos: each built-in chain id was read back from node_info on its publicnode REST host on 2026-09-26 (gaia v28.3.0, osmosis v31.1.0, celestia v9.0.4, juno v30.0.0, akash v2.1.0, dydx v9.7.1, sei pacific-1 v6.6.1).
• Cosmos: node minimum gas prices read live: Hub 0.005uatom, Celestia 0.002utia, Akash 0.0025uakt, dYdX 12500000000adydx, Osmosis base fee 0.03uosmo; Juno and Sei publish none, so the chain registry's fee token is used.
• Cosmos: the Hub ⇄ Osmosis IBC pair is channel-141 ⇄ channel-0, both open, each naming the other's chain id.
• Cosmos: a never-funded address answers 404 code 5 on /auth/accounts.
• Cosmos: 30 encoder vectors (addresses, SignDoc, TxRaw, tx hash, IBC body, low-s) match @cosmjs/proto-signing 0.32.
• Cosmos (wallet kit): CW-721 reads, gating and a simulated transfer_nft checked 38/38 on Juno; every public Stargaze REST endpoint tried was unreachable.
• Sui: the public Mysten fullnode has retired JSON-RPC ("Method not found … migrate to gRPC or GraphQL", measured 2026-09-26), so the wallet defaults to publicnode (mainnet chain 35834a8a, testnet 4c78adac, both read live).
• Sui: 17 vectors (whole transaction, intent hash, digest, serialized signature) match @mysten/sui 2.33.1 byte for byte, and @noble verifies the SDK's signature over the intent hash the Motoko computed.
• Sui: the pure-Motoko BLAKE2b-256 matches @noble on five inputs, including an exact 128-byte block and a two-block message.
• Sui (wallet kit): NFT holdings, gating by Move type and object transfers checked 28/28 as a real SuiNS owner.
• Aptos: the Aptos Labs fullnode rate-limits anonymous callers (40,000 CU per five minutes, hit on the first probe), so mainnet defaults to publicnode (chain id 1, ledger info read live 2026-09-26).
• Aptos: eight vectors match @aptos-labs/ts-sdk 7.3.0 byte for byte; the CCIP payload is pinned against the same SDK.
• Aptos: both network defaults (publicnode for mainnet, api.testnet.aptoslabs.com for testnet) were answered live when the network switch was added.
• Aptos: the CCIP router was read live (Router 1.6.0; get_dest_chains names 14 selectors including the eight EVM chains in the address book), and a live get_fee for a "hello" message to Ethereum returned 76,985,823 octas.
• Aptos (wallet kit): digital-asset holdings, collection gating and object transfers checked 28/28; a soulbound token is refused.
• NEAR: rpc.mainnet.near.org and rpc.testnet.near.org were read live on 2026-09-26 (chain ids "mainnet" and "testnet").
• NEAR: a missing access key comes back as an in-result error rather than a JSON-RPC error, and that is read as "not funded yet"; UNKNOWN_TRANSACTION was observed as the pending shape.
• NEAR: ten vectors (a Transfer and a FunctionCall transaction, the hash in hex and base58, the signed transaction) match near-api-js 7.3.1 byte for byte, and @noble verifies the SDK's signature over the hash the Motoko computed.
• NEAR (wallet kit): NEP-171 holdings, nft_supply_for_owner gating and nft_transfer with 1 yocto checked 28/28 as a Paras holder.
• XRP Ledger: xrplcluster.com was read live on 2026-09-26 (network id 0); s1.ripple.com reset the sandbox's connection twice, so it is not the default.
• XRP Ledger: actNotFound is the shape of an account that does not exist yet; the base reserve is read from server_state (1 XRP today).
• XRP Ledger: twelve vectors match xrpl.js 5.3.0 byte for byte, and @noble verifies the SDK's signature over the signing blob the Motoko built (XRPL's Ed25519 rule signs the whole blob, no hash).
• XRP Ledger (wallet kit): XLS-20 holdings, issuer and taxon gating and the offer / accept transfer checked 35/35 against a holder and an open offer found by scanning ledgers.

Hedera, Algorand, TRON, Polkadot, Cardano, TON, MultiversX

• Hedera mainnet: the consensus nodes node00.swirldslabs.com:443 (0.0.3) and node01-00-grpc.swirlds.com:443 (0.0.4) answered a plain HTTPS POST of a gRPC-web balance query, so the Internet Computer's HTTPS outcall reaches Hedera with no proxy.
• Hedera: grpc-web.myhbarwallet.com returned grpc-status 14 with no frame, so it is not a default.
• Hedera: a busy node answers BUSY (precheck 12) inside the reply, and a receipt 15 minutes old came back RECEIPT_NOT_FOUND (18), which is when the mirror node is asked instead.
• Hedera mirror node: it names an alias in base32 (upper case, no padding) of the key; the 0.0.<DER hex> form a wallet accepts is refused by the mirror (HTTP 400), and so is lower case.
• Hedera mirror node: an account created by an alias transfer has unlimited automatic token associations, so a fresh Kontext account receives HTS tokens with no association step; older accounts such as 0.0.98 show 0.
• Hedera mirror node: USDC on Hedera is token 0.0.456858 with 6 decimals.
• Hedera: transactions are pinned byte for byte to @hashgraph/sdk 2.81.0; Hedera signs the body bytes themselves (no hash), and the transaction hash is SHA-384 of the signed transaction.
• Hedera: token creation, minting, burning and NFTs are pinned to the SDK by test vectors but were not exercised on the live network, because a real token creation costs HBAR the build session did not hold.
• Algorand mainnet: a payment built by the Motoko against live params and posted to algod came back with the same transaction id the module computed and was refused only on authorisation; a flipped signature was refused as a bad signature, so the node decoded and verified it.
• Algorand mainnet: the test key's account turned out to be rekeyed (auth-addr set), so the module now reads auth-addr and refuses a rekeyed account by name before signing.
• Algorand: transactions are pinned to algosdk 3.x (canonical msgpack, "TX" prefix signed with no pre-hash); genesis, round and fee are read from /v2/transactions/params on every send.
• TRON (live node): a TRX transfer built by the Motoko against a live block, from an unfunded key, was broadcast; the node returned the same transaction id, passed the signature and stopped at "account … does not exist"; a flipped signature came back SIGERROR.
• TRON: TronGrid refuses a fourth request per second without an API key (HTTP 429), which is why PublicNode is tried first.
• TRON (live): the energy fee measured 100 sun (not the 210 or 420 older docs quote), so chain parameters and account resources are read on every send.
• TRON: /wallet/getblock {detail:false} returns about 0.5 KB, against 470 KB for getnowblock.
• TRON: an address that never received TRX does not exist on the network (getaccount answers {}).
• TRON: transactions are pinned to TronWeb 6.5.1 (signature as r ‖ s ‖ recovery id + 27).
• Polkadot: the relay chain (rpc.polkadot.io) holds about 238 thousand DOT against 1.7 billion on Asset Hub (statemint) and carries a migration pallet, which is why the wallet targets Asset Hub and never the relay endpoint.
• Polkadot Asset Hub: a Motoko-built transfer from an unfunded key was validated by the node as Invalid: Payment (format and signature accepted), and a flipped signature as Invalid: BadProof; a live fee quote of 8,808,355 planck is pinned.
• Polkadot Asset Hub: transactions are pinned to @polkadot/api against the live metadata (spec 2005000, transaction version 15).
• Paseo Asset Hub: it needs three extra extension bytes ahead of the era (transaction version 18); without them the runtime traps, and @polkadot/api's own v4 encoding traps it too.
• Cardano (live, through Koios): fees, minimum output and size limit are read from Koios epoch_params (measured at 44 × size + 155,381 lovelace; 4,310 × (160 + output size); 16,384 bytes), never pinned in code.
• Cardano (live node): a probe spending someone else's live output had its id computed by the node from the Motoko's bytes and our witness accepted (only the owner's missing witness was reported); a flipped signature added InvalidWitnessesUTXOW.
• Cardano (Koios): Koios omits an output's asset_list unless the request sets "_extended": true, so the wallet asks for it; without it an output holding tokens looked token-free.
• Cardano: transactions are pinned to @emurgo/cardano-serialization-lib (Conway-era CBOR).
• TON (tonapi wallet emulator): with the balance overridden, the emulator took a Motoko-built deploying transfer from a fresh key; the message hash matched, the account went from uninit to active and the contract emitted the outgoing message exactly. Both public emulators skip the signature check, so the signature is proven by the test vectors against @ton/ton, not by the network.
• TON mainnet: the test key's wallet is deployed with a zero balance and storage debt, so the network rejects every message to it before execution, which made it useless as a live judge.
• TON: the wallet v4R2 code is pinned by hash, and the Motoko re-serializes it to the same bytes as @ton/core.
• MultiversX mainnet: valid Motoko-built bytes drew "insufficient funds", and flipped bytes drew "invalid signature", so the network checked the signature over the module's bytes.
• MultiversX gateway: gas simulation via /transaction/cost needs a gas limit set (60M is used); without one the gateway answers "insufficient balance".
• MultiversX: the signed payload is the SDK's canonical JSON, matched byte for byte, with the BLAKE2b hash as the transaction id.

Storage and compute

• Filecoin (Glif, mainnet): the unsigned-message CID the module computes is the one GasEstimateMessageGas returns, and the signed-message CID is the one Lotus named when refusing a flipped signature.
• Filecoin (Glif): a valid signature from the module passes verification and reaches the nonce lookup ("actor not found"); a flipped byte fails with "signature verification failed".
• Filecoin: the encoders are pinned to @zondax/izari-filecoin 1.2 and @ipld/dag-cbor and executed in the Motoko interpreter (74 checks), covering every address protocol, 0x to f410f and masked 0xff… to f0, message CBOR and the signed-message envelope.
• Filecoin (Lighthouse): the deal ids Lighthouse reports do not resolve through the chain's StateMarketStorageDeal, StateGetClaim or StateGetAllocation, which is why deals are shown as reported by Lighthouse.
• Filecoin (Lighthouse): an upload with a real Lighthouse key was not yet verified live when the toolkit shipped (no key was in hand).
• Arweave (Turbo): POST upload.ardrive.io/v1/tx accepted a ~200-byte Ethereum-signed item from an address that had never paid (200, winc: "0"); turbo-gateway.com served it immediately while arweave.net returned 404 until the bundle settled.
• Arweave (Turbo): an unfunded account reads as "User Not Found" on the payment service, which the hook shows as not funded rather than as an error.
• AO (testnet units): cu.ao-testnet.xyz answers dryrun and result for a process it does not serve with {"error":"Process not found in whitelist"}, and mu.ao-testnet.xyz expects a signed item body.
• Arweave: the data-item layout was read from @dha-team/arbundles 1.0.4's source; seventeen vectors run in the Motoko interpreter against its output (deep hash, Avro tags, the raw item byte for byte, its id, an AO message item), and @noble recovers the SDK's signature to the same address.
• Aleph (api2.aleph.im): broadcast answers 200 processed, 202 pending and 422 InvalidMessageFormat, all three observed.
• Aleph: the network's own pulse writer publishes AGGREGATE messages with a 0.0 ALEPH and 0 credit balance, so aggregates and posts are free to publish; STORE is metered.
• Aleph: a stored file's hash was confirmed as the sha256 of its bytes by downloading a live 304-byte object and hashing it.
• Aleph: seventeen vectors from @aleph-sdk/message 1.10.0 run in the Motoko interpreter (the EIP-55 address, AGGREGATE / POST / STORE content and hashes byte for byte, the signed buffer, the envelope and the FORGET content), and @noble recovers the SDK's signature to the same address.
• Aleph compute: PROGRAM and INSTANCE item hashes are pinned against the SDK (7 vectors); the scheduler's allocation read and the price read were taken live.
• Aleph: both api2 and api3 answered as API servers.
• Akash: 1,000 blocks took 5,870 s, so an hour is 613 blocks; a USD ceiling becomes a maximum bid in uact per block at 1 ACT = $1, and bids in any denomination but uact are refused.
• Akash Console API: gpu-prices, pricing and placement-options answer without a key.
• IO Intelligence: the /models list answers without a key and listed 37 models.
• Fluence, io.net IO Cloud and Dispersed: none reads anything without a key.
• Fluence: the current API is CPU VMs only, and its old marketplace endpoints return 404.
• Render Network: rendering is a desktop app (Render Network Manager) behind whitelisting with no API a canister can drive; Render compute means Dispersed.
• Aethir: GPUs are booked through an application form, ATH and a web portal (bare metal for one week minimum), with no booking API.
• Compute: HMAC-SHA256 and the Dispersed signature run in the Motoko interpreter against Node's crypto (keys of 3, 64 and 105 bytes); the SDL is parsed by js-yaml; the reply readers run against live keyless replies.
• Compute: every authenticated success path (deploy, lease, stop and chat with a real key) was not yet verified live, because no provider key was in hand; io.net's CaaS hardware and price schemas are missing from its spec, so those readers are lenient and fail closed.

Wallet kits

• EVM: all 35 viem default RPCs answered eth_chainId and eth_getBalance and passed a browser CORS preflight; BSC's default (thirdweb) once omitted Access-Control-Allow-Origin on a POST, so BSC and Ethereum carry a probed fallback endpoint.
• EVM (Ethereum mainnet): BAYC #1's holder reads as holding, NameWrapper is detected as ERC-1155, and USDC is refused as not an NFT contract.
• Solana mainnet: api.mainnet-beta.solana.com answered 403 from the network the tests ran on, and publicnode refuses the indexed calls (getTokenAccountsByOwner, getTokenAccountBalance, getTokenSupply), so token balances are read from the token account itself with getAccountInfo.
• Solana mainnet: the Token-2022 program id was read off PYUSD's mint (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb).
• Solana mainnet: publicnode and dRPC do not implement getAssetsByOwner, and Helius and Ankr need a key, which is why wallet-wide NFT listing is not built.
• Aptos: the Aptos SDK fetches with credentials: 'include', so a wildcard CORS answer fails in a browser; the real API echoes the page's origin with Allow-Credentials. The SDK's getBalance returns a lossy number, so balances are read through view functions.
• Sui mainnet: the kit's balances, coin selection and transaction status were exercised against the live fullnodes; the pool uses the gRPC client because Sui's public JSON-RPC is retiring.
• Stellar mainnet: a key assumed unfunded was in fact funded, so tests use a random address confirmed 404 on Horizon each run.
• NEAR: tx with wait_until: FINAL hangs about 30 seconds on an unknown hash before erroring, while NONE answers at once, so an unknown hash reads as pending.
• TRON mainnet: getaccount answers an empty object for an account that was never activated; TronLink has no disconnect event, and an empty accountsChanged means the site was locked or revoked.
• Cosmos Hub: a refused simulation comes back as HTTP 500 carrying the chain's own {code, message}; with a bonded validator's real public key behind a fake Keplr, the Hub decoded every byte and refused only the fake signature (code 4), for sends and IBC.
• Arweave (arweave.net): the gateway answers "Transaction verification failed." alike for a well-signed unfunded transfer, a bad signature and a wrong id.
• TON: TON Connect SDK 4 lists an injected wallet only when its registry names that wallet's JS-bridge key; toncenter v3 reports a never-seen address as uninit, read as not existing; toncenter without a key allows one request a second, so reads are paced and retried.
• Cardano (mainnet, preprod, preview): Koios answers the CORS preflight but sends no Access-Control-Allow-Origin on the response, which is why reads go through Kontext's /api/cardano.
• Cardano mainnet: the hook's ADA and NFT sends, signed with a random key over a real holder's UTXOs, were refused by the node with only MissingVKeyWitnessesUTXOW and InvalidWitnessesUTXOW, meaning no fee, min-ADA, conservation, input or TTL fault.
• Polkadot Asset Hub: the live v16 metadata lists thirteen extensions for v4 and eighteen for v5; the hook's extrinsic signed with an unfunded key drew exactly Invalid: Payment, and one flipped bit drew BadProof.
• Bitcoin (mempool.space): /tx/:id/status answers "unconfirmed" for a txid nobody broadcast, so status uses /tx/:id.
• Bitcoin ordinals: Hiro's ordinals API answers 410 and ordinals.com's JSON API is disabled, but its recursive /r/ endpoints are open, so inscriptions are read from an address's outputs.
• Stacks mainnet: the node's middle fee tier read 0.166 STX for a plain transfer, skewed by bots (measured for the Stacks module), so the kit's balance check also uses the low estimate as the floor.

Benefits

• No private key anywhere. The app can sign for a chain without a seed phrase to lose or leak, and without a custodian.
• Both custody models. The app's own wallet and treasury (Lane A), or the person's own wallet (Lane B), in the same app.
• Guardrails are built in. Spend ceilings, caps and approvals are enforced by the canister. Trading and compute stay off until the owner sets limits.
• Owner keys stay put. They are checked on entry, stored on the app's canister and never returned. Anything missing says so by name.
• One prompt, many networks. 30+ chains, cross-chain protocols, permanent storage and decentralized GPU/CPU from the same build lane.

Who it's for

Primary: founders and builders creating apps that hold, charge, move or store value on-chain: marketplaces, loyalty tokens, NFT drops, crypto checkout, DePIN dashboards, trading desks and AI apps on open models. Also: communities whose members already have wallets (Lane B), and owners who want a treasury without a custodian (Lane A). Not: people looking for a standalone exchange or a personal wallet app for the Kontext platform itself. These toolkits live inside apps you build.