An app that connects to a wallet Anything that asks a user's wallet to pay, sign or prove something, rather than holding keys itself.
What is in it The three app reference designs, plus connecting, permissions, signing in, errors and the three charging patterns: one-off payments, micropayments and agent spending. Also covers what an app owes a user who wants to leave.
Let the user hold their own keys, and make the path to doing so the default rather than an advanced option. Say plainly when something is custodial. A service holding keys on a user's behalf is a legitimate product; describing it as self-custody is not. Costs money Build a product where the user's funds depend on your company continuing to exist. Every wallet should be recoverable without you. See Backups. Match the protection to the amount. A wallet holding coffee money and a wallet holding savings are different products, and pretending otherwise produces one that is wrong for both. See Wallet setups. Costs money Make the irreversible step unmistakable. A payment cannot be recalled, so the review screen is the last line of defence. Ask for as little as the product needs. The independent risk assessment of the wallet interface (BRC-151) warns how much a wallet can be asked for; the answer is to need less of it. See Connecting a wallet. Train people to tap approve. A prompt that appears constantly, is pre-ticked, or reappears until accepted teaches exactly the habit that gets someone robbed. Write for someone who has never heard of a UTXO and never needs to. Internal vocabulary belongs in advanced views and documentation. Meet WCAG 2.2 AA: contrast, touch targets, screen reader labels, and amounts that read aloud sensibly. See Accessibility. Costs trust Require an identity document, an email address or a phone number to hold money. Where a regulation requires it for a particular feature, gate that feature, not the wallet. Support the standards rather than a bespoke integration. Design your connect flow around "your wallet", not a brand. Costs trust Give every wallet an export the user holds themselves, and a send to a plain address that works without your servers. See Legacy compatibility. Invent a proprietary format for something a BRC already covers. A format only your product reads is a lock-in whether or not you meant it as one. Costs money Show the total a payment takes from the user, who it goes to, and that it cannot be undone, before they commit. Say what your product can see and what it stores. A wallet that phones a service on every balance check should say which service and what it learns. Costs money Name the limits. "This backup covers your keys but not your payment records" is the sentence that stops somebody losing money later. Describe a product as private, anonymous or instant without the qualifier that makes it true. Keep outputs from unrelated counterparties apart when selecting what to spend. Spending them together is the main remaining on-chain leak. See Coin selection. Costs trust Before revealing key linkage for a counterparty, tell the user it exposes every payment between them and that counterparty, past and future. See Wallet privacy. Collect what you do not need, and never attach a user's identity to routine payments for convenience. Write personal data on chain in the clear. There is no delete. Let users choose or self-host the services your wallet depends on, and support more than one. See Nodes and verification. Weld a product to one provider's endpoint. That is your product's lifespan as well as theirs. Keep showing onboarding hints to somebody on their hundredth payment. Teach each of the four at the moment it first applies: ownership when money first arrives, irreversibility on the first review screen, the backup when the balance is worth protecting, the network name wherever somebody pastes an address. Teach what the product can take care of for them, such as fees or key schemes. Every concept taught before it is needed is a reason to stop. Make the first thing a new user does end with them holding real money: received from a person, or spent on something they wanted anyway. Build a practice wallet or a simulated payment in place of a real first receive. It teaches the user that the real thing is somewhere else. Design for the person doing the introducing: a handle they can share, a payment request they can send, and a first payment that says who it came from. See Contacts. Get a new user from opening the app to holding money in one sitting, without leaving the app except to ask somebody to pay them. Give every setup step a way back. A mistake during setup should cost a tap, not the wallet. Ask the person, after a test, to explain to a friend what they just did. What they cannot explain did not land. Measure where people stop, step by step, and work on the worst step first. A whole-funnel number tells you there is a problem and not where it is. Design the "frightening moment" explicitly. A payment that looks stuck, an unexpected balance, an app asking for something alarming. One clear explanation at that moment can keep somebody who would otherwise leave. We suggest two causes to check first: being asked to choose a key scheme, and having nowhere to get any BSV. The first is yours to fix. See First use. Talk to the wallet through the connection standard rather than bundling one. The user keeps their keys where they already are, and your app works with wallets that did not exist when you shipped. Build a wallet inside your app because it is quicker. You inherit key custody, recovery and support, and the user now has one more set of keys to lose. Accept a pasted or scanned value without asking the user which kind it is. Detect it and say what you found. Support the peer-to-peer payment flow, where the payee's software supplies the output script and gets the transaction and its proof directly. It is the privacy-preserving default and it is how handles work. Costs trust Export the wallet backup in the wallet data format (BRC-38 and BRC-39), to a file the user holds. If your format is your own, say so plainly and publish it. Support restoring a backup written by other software, and report honestly what came across and what did not. Keep the only copy of a user's proofs on your server. That is custody by another name, whoever holds the keys. Verify Passes rather than issuing your own account. A person who has already proved who they are to somebody you trust should not have to do it again. Ask for the single field you need. A Pass can be shown selectively, and asking for all of it when you need one line is a design choice, not a protocol limit. Offer a plain export of contacts and labels, in a documented format, without a support request. Encode a handle rather than an address where you can. It is shorter, it survives being printed once, and it does not tie a person to one key forever. Support animated codes for anything that does not fit in one frame, such as a transaction with its proof going to an offline signer. Use upper case for codes made only of digits, capitals and $%+-./:. Those encode in a smaller, faster-scanning mode. Handles and addresses do not qualify. Use a transaction format that leaves out the input proofs. The receiver then has to ask a third party whether the transaction is real. Follow the fountain-coded air-gap transport (BRC-141) rather than a private encoding, so a user's existing signer works with your software. Exchange public keys and pending transactions in documented formats, and let a cosigner review and sign in whatever wallet they already use. List your dependencies somewhere a curious user can find them, and let the technical ones be changed. Let a user point at their own header source and their own broadcaster. Most will never touch the setting, and the option costs little. Ship a control labelled "button". A QR code built as an unlabelled image is not selectable at all, so it does not exist for a screen reader user. Name the thing and its effect: "QR code, double tap to copy the payment handle". Costs trust Make a wallet's permission prompt readable in full by a screen reader: who is asking, what for, and for how long. A grant the person could not hear is not consent. Put the recipient before the amount in the reading order of a review screen. It is the field most worth hearing first. Give every scan a typed or pasted equivalent. A user who cannot aim a camera still needs to pay. Pair colour with a word or a symbol, always. Sent and received, plus and minus, not just red and green. Put a countdown on a confirmation. Nothing here expires, so a timer is a difficulty you added. If a rate quote goes stale, refresh it rather than timing the person out. Make sure an amount reads aloud correctly. "12,500 sats" should be spoken as a number and a unit, which means it has to be text with a real unit beside it. Use fixed-width digits (tabular-nums), so a changing balance does not shift the layout under a magnified viewport. Offer at least one route that does not need handwriting: an encrypted file the user stores themselves, split shares held by people they trust, or a signing device. Let the words be read aloud in private, and let the confirmation step be completed with a screen reader. A test that only works by sight makes recovery impossible later. Write at a reading age of about twelve. Short sentences, common words, one idea each. Say what happened and what it means for the money. "The payment did not go through. Nothing left your wallet." beats an error code every time. Run the send and recovery flows with the screen reader on and the screen off. It takes an afternoon and finds problems an automated audit misses. Include people with disabilities in research, paid, rather than simulating them. Costs trust Preselect broad permissions, describe a permission as less than it is, or show a refused prompt again until the user gives in. All three teach people to tap Allow without reading. Costs trust Show the app's name from its manifest beside its verified domain in every prompt, and the domain alone when the app has no manifest. Write the description for each permission your app declares as what the user gets from it: "To save your reading position", not "Protocol access". Let the user approve some items in a grouped prompt and decline others, and let the app carry on with what was approved. Costs money Show an amount taken from the app's description text. Show the amount from the request itself, and warn if the two disagree. Show a waiting state in the app that tells the user their wallet is asking them something, and keep it until the wallet answers. Costs trust Cancel a wallet request because the user has not answered yet. A timeout turns a user who was reading into an error. Set an allowance to expire by default, and make a lasting allowance an explicit choice the user picks. Costs trust Cap an allowance per payment, per hour and per day as well as per month, where the wallet supports it, and show every cap in the same prompt. Costs trust Ask the user again when an amount is unusually high, the recipient is new, the payment pattern changes, an allowance that has ended would start again, or the app asks for a new protocol, basket, Pass field, the identity key or key linkage. Show the date a monthly allowance starts again beside what is left of it: "1,200 of 5,000 sats left, resets 1 December". After a refusal, say in one sentence what the app cannot do without the permission, and keep everything else working. Ask again only when the user next uses the feature that needs the permission, not on the next screen. Costs trust Make a revoke take effect at once, and say what stops working: "The Satoshi Vision can no longer charge you. It will ask again when you next open an article." Costs trust Ask for key linkage fresh each time, name who receives it and what they learn, and keep a local record of what was revealed to whom. Costs money Let an AI agent approve key linkage, share a Pass, or widen its own permissions. Use one button for a first visit and a return visit. There is no separate sign-up, because there is no account to create. Costs trust Ask for an email address or a password as part of signing in. If you need an email for receipts, ask for it afterwards, as its own optional step. Costs trust Sign users in with a key derived for your app. If your database leaks, the leaked keys can't be matched to the same person's activity elsewhere. Costs trust Use the root identity key as the account ID for a social network, game, shop or payment service. One breach then becomes a cross-app tracking event. Costs trust Request the wallet's root identity key without a reason you can state in the prompt. Approving a sign-in or a payment must never include it. Recognise a returning user without a wallet prompt where the wallet already holds your app's permission. Show a public key as the user's name. Use the name they gave you, or a plain label such as "Your account". Tell people before their first sign-in that the account belongs to their wallet: "Restore this wallet and your account comes back with it. A different wallet is a new account." Costs trust Say on sign-out that the app is still connected in the wallet, and where to disconnect it: "Signed out. Pixel Arcade is still listed in your wallet. Remove it there to stop it asking." Costs trust Call sign-out "Disconnect wallet". It does not touch the wallet's permissions, and the user will think it did. Ask for the narrowest field that answers the question: "over 18", not a date of birth. Say which Pass issuers you accept, and offer another way to qualify where the law allows. Make a Pass a condition of signing in when only one feature needs it. Ask at that feature. After the first sign-in, say in one line what your app received and what it cannot see: "Pixel Arcade can recognise you next time. It can't see your balance or your other apps." Default to satoshis, not BSV, for the bitcoin figure. Everyday amounts are hundreds or thousands of satoshis, and the decimal form is unreadable at that scale. Write "sats" or "satoshis" in words, and group digits in threes: 12,500 sats. Costs money Show long decimal BSV amounts in a consumer interface. "0.00012500 BSV" asks the reader to count zeros, and they will get it wrong. Adopt a satoshi glyph. None renders reliably, none is in common fonts, and your users have not seen any of them. Costs trust Use Bitcoin SV or BSV on screen: "Send BSV", "Your BSV balance", "Bitcoin SV address". Use one of the two consistently within a screen. Prefer "Bitcoin SV" where there is room and the reader may be new to it, "BSV" where space is tight or the term repeats in a list. Costs trust Write "bitcoin" alone on a screen where somebody is about to move money. Used precisely it is an umbrella covering several chains, so it is the one word that cannot tell a user which network they are on. See Bitcoin. Lead with local currency for anything a person chooses to buy, with the satoshi amount beside it: "£12.00 (24,000 sats)". Lead with satoshis for figures software decides or enforces, such as allowance limits, what is left of an allowance and agent budgets, with local currency beside them. Let the two be swapped in one tap, and remember the choice. Costs trust Say when a converted figure is an estimate, and roughly how fresh the rate is. A price that silently drifts is worse than one labelled approximate. Use tabular figures (tabular-nums in CSS) everywhere a figure appears, so digits line up in a column and a changing balance does not shift the layout. Format for the reader's locale. 1,200 and 1.200 and 1 200 are the same number to three different people and three different numbers to one of them. Costs trust Keep one bitcoin unit per screen. Mixing "0.0001 BSV" and "10,000 sats" in one view asks the user to do arithmetic to compare two things you wrote. Costs trust Abbreviate amounts in a financial context. "12.5k sats" saves four characters and introduces a rounding question. Costs trust Shorten a number with an ellipsis, ever. Reformat it or let it wrap. Leave the fee off the review screen and put it in the transaction details. If it is shown, show it in local currency: "Fee: less than 1p". Show the individual amount where it happens and the aggregate where the user is deciding something. "About 1p (20 sats)" on the article, "940 sats (about 47p) today" in the allowance summary. Round aggregates to a sensible precision in local currency. "About 24p today" is more useful than "£0.2384". Make sure an amount reads correctly aloud. A screen reader should say "twelve thousand five hundred satoshis", which means the unit needs to be text rather than an image or an unlabelled glyph. Never rely on colour alone to show direction. Pair the colour with a sign or a word. Costs trust Show the running total against the allowance wherever the spending is happening, not only in a settings screen. Costs trust Put a stop control next to that total. One action, no confirmation, effective immediately. Costs trust Renew an allowance that has ended without asking the user again. A limit that starts again each month within a live grant is normal, provided the reset date is shown beside what is left. Put the cost on the thing: "about 1p (20 sats)" on the article link, "5 sats per request" on the endpoint. Lead with local currency for anything a person chooses to buy, and with satoshis for anything software decides, with the other figure beside it. "About 1p" means something to a reader; "20 sats" means something to a developer. Round a per-use price up to something tidy because the real number looks odd. The real number is the product's best argument. Group by what the user was doing, not by transaction. "The Satoshi Vision, 14 articles, about 14p (280 sats)" is one row they understand. Let that row open into the individual payments, for the person who wants them and the accountant who needs them. Lead with the period total. "About 24p today" answers the question they actually have. Show a notification per payment. The first one is informative, the fortieth is why the feature gets switched off. Show the rate and the elapsed cost together, and update at a pace a person can read. A figure changing ten times a second is not information. Costs trust Make stopping obvious and instantaneous, and confirm that it stopped. "Stopped. You spent 340 sats." closes the loop. Costs trust Offer a ceiling before starting, not only an allowance. "Stop at 5,000 sats" is a different and more reassuring promise. Decide what happens when one payment in a hundred fails: retry, skip, or stop. Then tell the user which, once, rather than reporting each one. Costs trust Fail towards not charging. A user who got something free will forgive you; one charged twice will not. Costs money Make the handle the default and the address the fallback. Every payment that uses a handle is a payment that cannot go to the wrong network. Costs money Put the network name next to the address field, always, not only on error. "BSV address" is three words and it is the whole defence. Costs money Warn on every pasted address rather than trying to detect a bad one. You cannot detect it, and a warning that only fires sometimes teaches people it means something specific. Costs money Use "bitcoin address" as the field label. That is the word that cannot distinguish the networks, on the screen where the distinction is the whole point. Costs money Put the network on the confirmation, beside the recipient, in the same weight as the amount. Costs money Say plainly what cannot be undone, before the button: "Sent to the wrong network, this usually cannot be recovered." Costs money Offer a test payment for a first-time address above a threshold you choose, and ask the user to check with the recipient that it arrived. It costs a fraction of a penny and it is the only defence that proves the address is right. Costs trust Say what happened in plain words: which network it went to, that the money is not lost from the chain but is out of reach from here, and what recovery would require. Give them the transaction reference and the output, so somebody technical can help. Say "transaction failed". It did not fail. It succeeded somewhere else, and telling somebody it failed sends them looking for a refund that is not coming. Costs trust Promise recovery you cannot deliver. If it needs the other party's cooperation, say that is what it needs. Costs money Make the network selection impossible to leave at a default, and restate the chosen network on the confirmation. Treat a first withdrawal to a new address as a different flow from a repeat one. Costs money Fund an agent by deliberate top-up, as a human action. A standing instruction to refill is the thing that turns a bounded loss into an unbounded one. Costs money Hand an agent the user's identity key or their Passes. It can have its own identity and act as itself; it should never be able to prove it is the person. Show all four on one screen, as current values rather than settings. "412 of 5,000 sats, 18 payments today, 3 services, 22 days left" is a status, and a settings form is not. Costs money Enforce limits outside the agent, in the wallet or the service holding its keys. A limit the agent checks itself is a limit an injected instruction can argue with. Costs trust Require a human for anything outside the scope: a new payee, a larger amount, a wider permission. Send the person a notification for it, rather than adding it to a list they have to check. Group by purpose, not by payment. "Research assistant: 6 sources, 240 sats" is reviewable; forty rows are not. Costs trust Record what each payment was for at the moment it happens. Intent cannot be reconstructed afterwards. Costs trust Surface the unusual rather than the complete. A payee it has never paid, or a payment larger than its usual, belongs at the top; the routine belongs in a total. Costs trust Report agent spending only in a log. A log is for after somebody already suspects something. Costs trust Put one control that stops everything, visible wherever the agent is, with no confirmation step. Confirmations are for actions you might regret, and stopping is not one of them. Say what stopping means: no further payments, work in progress abandoned, funds stay where they are. A user who is not sure what the button does will not press it. Costs trust Name the agent and its purpose wherever its spending appears. "Example Assistant, buying search results" is a thing a person can consent to; "automated payments" is not. Report on a human schedule. A daily summary a person reads beats a real-time feed nobody watches. Costs trust Ask for broad wallet access in order to read a token balance. Ask for the basket. An app that wants everything in order to show one number is the reason permission screens get ignored. Costs trust Show provenance as a short human sentence before a trade or a transfer: "Issued by Example Studio, 3 owners since, unbroken." The full chain belongs behind that line, not in front of it. Costs trust Resolve the real-or-fake question for the user rather than printing an ID and hoping. Match against issuers they already trust, and say plainly when you cannot. Costs trust Show a token's picture at the size of a decision without the provenance beside it. The picture is the part that is trivial to fake. Costs trust Say what is being written on chain, that it cannot be edited later, and what it costs. The cost is a fraction of a penny, which is worth saying out loud because people expect otherwise. Costs money Treat the supply decision as final in the interface, because it is. A field labelled "Supply" with no warning is a trap. Costs trust Name the issuer wherever the balance appears, not only at acquisition. "120 GBP, issued by Example Trust" is the honest form. Costs trust Draw a stablecoin balance in the same type as a BSV balance with no distinction. One is a bearer asset and the other is a claim on a company. Choose by what you need enforced on chain rather than by what is popular. A loyalty point and a regulated instrument are not the same design problem, and the stricter family exists for the second. Mark free articles as plainly as paid ones on the front page, so the absence of a price is never mistaken for a missing label. Put a connect prompt, a sign-in button or a wallet logo on the front page. Nothing there costs money, so nothing there needs a wallet. Show enough of a paid article before the price for the reader to judge it: at least the headline, the standfirst and the opening paragraphs. Costs trust Name the price, in satoshis and local currency, on the same panel as the connect button. The reader should know what the first tap costs before the wallet opens. Costs trust Ask for a key made for this site only at connection, and nothing else: no identity key, no Pass, no spending grant. Treat "Not now" as an error. Keep the reader on the article they chose, with the free paragraphs still showing. Costs money Name the article being bought on the wallet's payment sheet, so the reader can see that the thing she tapped is the thing she is paying for. Open the rest of the article in place the moment the wallet reports the payment accepted, at the paragraph where the free part ended. Show the allowance offer before the reader has finished her first paid article, or on any free article. Treat "No thanks" as final for the visit. The reader goes on paying per article with a wallet prompt each time, and the card does not return until her next visit. Costs trust Give the allowance an end date in the request itself, and show that date on the wallet's sheet. When it ends, ask again and show what the last one was spent on. Show what the article just cost and what is left of today's allowance on the article itself, above the headline, every time the allowance pays for one. Mark articles the reader has already bought as read, without a price, so she never wonders whether opening one again will charge her. Costs money Charge for an article the reader has already bought, whether she returns to it on the same day or a month later. List what today's spending bought by article title, with the total first in local currency and the remaining allowance beneath it. Costs money Stop charging the moment the reader taps Stop, before any confirmation or animation, and say how much she spent today. Costs trust Say on the stopped state that the allowance still exists in the wallet, and where to remove it. Explain a used-up allowance on the article the reader was trying to open, with the free paragraphs still showing, and offer a one-time payment for that article. Raise the limit for the reader, or suggest a larger figure as the default. A new limit is a new request that she types or chooses. Costs money Show Try again on an article while the wallet reports its payment as still being sent. Let people browse every gig, date and price without connecting. Connecting is for buying and for seeing tickets already bought, not for looking. Name a wallet brand on the site's connect button or its explanation. The site works with any compatible wallet, and naming one tells everyone else they are in the wrong place. Costs trust Ask only for the sign-in key at this step. Payment, the age check and the ticket basket each wait for the screen where Anna first needs them. Treat "Not now" at this prompt as a failure. Put the Connect wallet button back, keep the gig page as it was, and say nothing louder than the button. Show the "what we can and can't see" line once, after the first sign-in only, on the page Anna was already on rather than a separate welcome screen. Costs trust Ask for a name or email straight after sign-in to make the header friendlier. "Your account" is enough until Anna chooses to add something. Try a silent sign-in on load when the site has seen this browser before, and fall back to the Connect wallet button only if the wallet does not answer without a prompt. Under the connect button, say in one line that the account follows the wallet, not the device: "Use the same wallet on any device to see your tickets. A different wallet starts a new account." Costs trust Offer to "find" Anna's account when a different wallet connects. The site cannot tell it is her, and guessing from anything else would link identities she kept apart. Show the age step only for gigs that have an age limit, and name the venue's rule as the reason: "The Corner Room is over 18 only", not "Verification required". Costs trust List on the site, before the wallet prompt opens, the one thing the site will receive and the things it will not, in the same words the wallet is about to use. Costs trust Ask for a date of birth and work out the age on the site. The site then holds a fact it never needed, and the wallet's field-level choice is wasted. Request the field with Example Tickets named as the verifier, and if the venue itself will receive the answer, name the venue in the request too, so the wallet's "Sent to" line is true. Costs trust Ask for the same single field, "over 18", at every age-restricted checkout, and never widen a later request because an earlier one was granted. Name the issuers the site accepts, and who chose them, on the screen that tells somebody they have no suitable Pass. Offer a way to buy that does not depend on a Pass where the venue allows one, so missing a Pass costs Anna a step at the door rather than the ticket. Send Anna to an issuer and empty her basket behind her. Keep the gig and the ticket she chose waiting for when she comes back. Word a refusal as Anna's decision and its one consequence for this gig, and leave every other part of the site, including other gigs, working as before. Reopen the wallet's Pass prompt automatically after a refusal, or on the next page load. The next request waits for Anna to press Ask my wallet again. Costs money Show on the review screen the same sats amount the wallet's prompt will show, and if the rate moves before Anna presses the button, update the figure on this screen first rather than letting the wallet show a different number. Name who receives the money and who the ticket is for in one line. Anna is paying the ticket site, for a venue, and both names belong on the screen. Say on the review screen what Anna can do with the ticket afterwards, give it away or not, refund it or not, before she pays rather than in the terms. Costs money Add a booking fee or any other charge after the review screen. If the product charges one, it is part of the price shown here. Ask for the tickets basket in the first purchase's prompt, as a separate item Anna can decline, and never at sign-in. Costs trust Ask for a spending allowance "to make the next purchase faster". A site people pay a few times a year should ask each time. Tell Anna where the ticket is, in her wallet, on the confirmation, so she does not wait for an email that is not coming. Write the gig name, venue, date and what the holder may do with the ticket into the token when it is issued, so any wallet can show it without asking the site. Let a picture of the ticket be enough to get in. The picture is the part anybody can copy; the door has to check that the person in front of it holds the ticket now. Label the site's own control Sign out, and put the one-line pointer to the wallet directly beneath it, so the two actions are read together. Costs trust Put a "Disconnect" button on the site that only clears the session. Anna would believe the site lost its access when the wallet still lists it. Say on sign-out that it applies to this device only, and that the ticket is unaffected, in one line on the page she lands on. Sign Anna straight back in on the next page load after she pressed Sign out. Wait until she presses Connect wallet again on this device. Treat a sign-in that suddenly prompts again as a returning user whose wallet was cleared or who removed the site, and show the ordinary connect flow without asking why. Costs trust Store the result of an age check, the gig and the date, and never the Pass or any field beyond the one asked for, and say so on the site's data page. Costs money Make a ticket valid at the door from the token alone, so it still works after Anna deletes her data or removes the site from her wallet. Costs trust Keep anything about Anna that this page does not list. If the site starts storing something new, the page changes the same day. Say on Scout's first screen, in one line, that the worst case is the amount Anna sends it. "Scout can't spend more than you give it" is the reassurance the whole design rests on. Costs trust Offer to connect Scout to Bitcoin SV Wallet with a spending permission as a quicker alternative. Two routes to the same task make the safer one look like the slow one. Show the services row as named services with their prices, never as a field where Anna types an address or a domain. Translate the budget into what it buys for this task: "10,000 sats is about 2,000 data requests, or 500 articles." The number only means something beside its use. Offer "no end date" as an option on this screen. A delegation with no end is the one nobody comes back to review. Request exactly the budget Anna set. If she changes the amount in Bitcoin SV Wallet, show the new figure as Scout's budget on the next screen rather than holding on to the old one. Costs trust Ask Anna to switch on a low-balance refill during funding. Topping up is a separate decision each time, made when she can see what the last budget bought. List on the review what will come to Anna for approval: "a new service", "anything over 100 sats", "going over 3,000 sats in a day". The approvals are part of the deal, not a surprise later. Name on the review the one device where approvals will arrive, and accept approvals only there. Say when and where the daily summary will arrive, and let Anna change the time on this screen. Disable Start Scout until the top-up has arrived, and say so beside the button: "Waiting for 10,000 sats from Bitcoin SV Wallet". Move the status strip into a settings page once setup is done. Anna checks on Scout from where its work is, and that is where the total and the pause belong. Show each purchase in the task view beside the step of the task it served, so "4 articles" reads as part of the research rather than a separate bill. Notify Anna's phone for payments inside the limits. She is not watching on purpose, and a buzz per article would teach her to silence Scout entirely. Costs money Show the amount and the payee from the payment Scout's wallet refused, and Scout's explanation separately, labelled as Scout's. If the explanation names a different amount, show both and say they disagree. Name every limit the request breaks: "New service" and "Over 100 sats a payment". Anna is deciding whether the limits were wrong or the request is. Costs money Put "Always allow" or "Add to Scout's services" on the approval screen. Widening Scout's scope from a notification is how one odd request becomes a standing permission. Costs money Let the assistant approve its own request, or accept an approval from anywhere other than Anna's own device. Show what the budget bought on the same screen that says it is spent. Anna decides whether to top up by judging the last budget, not by looking at a zero. Offer to finish the task with what Scout has already bought, as an equal choice beside topping up. Costs money Refuse a payment above the price shown on the limits screen, even when it is inside the per-payment limit, and send it to Anna like any other request outside scope. Costs trust Say plainly when a service kept the money: "Example Data was paid 15 sats and sent nothing back." Whether money moved is the first thing the errors pattern asks every failure to answer. Costs money Cap paid retries to one service at a fixed number per task, show that number on the limits screen, and stop using the service when it is reached. Each retry is another payment, and a loop of small failures is how an agent spends its budget on nothing. Put refused payments, approvals Anna gave, and any service that kept money without delivering at the top of the daily summary, above the total. Say "Nothing unusual today" when that is true. A summary that only ever lists problems leaves Anna unsure whether a quiet one means no problems or a missing section. Send a summary on a day Scout spent nothing and nothing changed. A daily message with no news is the fastest way to have the useful ones ignored. Mark every payment in the trail with the task it served. A payment that belongs to no task is itself something to flag. Show refused payments in the trail beside the ones that went through, marked "Refused, nothing sent". What Scout tried to buy is part of what it did. Costs trust Record Scout's reason with each payment at the moment it is made, and keep it unchangeable. A reason written afterwards is a story, not a record. Costs trust Present Scout's note in the same style as the amount and payee. The amount and payee come from the payment; the note comes from the agent, and the screen should show the difference. Put Pause Scout on any payment Anna has flagged, so she can stop it from the place she noticed the problem. Costs trust Offer "Get a refund" or "Dispute" on an agent payment. Scout cannot reverse a payment, and a button that implies it can will be pressed and will fail. Costs trust Show the exact time spending stopped, and whether a payment was already on its way at that moment: "The last payment, 20 sats to The Satoshi Vision at 14:32, went through before you paused." Costs money Make pausing take effect in Scout's wallet, not in the assistant. Spending stops even if the assistant is still running or has not noticed. Ask "Are you sure?" before pausing. Pausing costs nothing and can be undone; a question in front of it only slows down the person who is worried. Say how far the task got and what was already bought, so Anna can decide between resuming, finishing with what there is, and ending. Say what happened to any approval that was waiting: still waiting while paused, cancelled when revoked. Costs trust Let Scout's stop message argue for resuming. "I was nearly there" turns a safety control into a negotiation with the thing being stopped. Costs trust Say on the revoke screen that the money left in Scout's wallet stays there until Anna sends it back, and show the amount. Bundle revoking with deleting Scout's activity. Anna may end the job precisely because she wants to look at what happened. Costs money Offer only the wallet that funded Scout as the destination for what is left. A payee chosen at the end of a delegation is a payee nobody vetted. Close the job with the three numbers Anna will want to reconcile: what she sent, what Scout spent, and what came back.
