The most interesting technology opportunities rarely arrive with proof that they will work. At first, they usually look too expensive, too limited, or too early. They become obvious only after new products, workflows, and distribution are built around them.

This is where an asymmetric bet appears: a decision with bounded cost and risk, but knowledge and potential upside that can be many times larger. For a software company, that does not have to mean buying an asset or starting a multi-year project. It can mean two weeks spent on a narrow prototype that tests whether new infrastructure performs better than the current approach.

We see Bitcoin, Lightning, and AI agent payments as that kind of bet. An open payment network can move value between people, companies, and software. It does not automatically solve wallet security, the provider’s legal role, tax records, or control over what an agent is allowed to buy.

In this article, “bet” means an engineering and product strategy, not a recommendation to buy Bitcoin or any other asset.

An asymmetric bet is not blind speculation

A useful asymmetric bet has several testable properties:

  • the worst acceptable outcome is known in advance;
  • the first step can be taken without putting the core product at risk;
  • the experiment creates proprietary technical or market knowledge;
  • the output remains useful even if the initial thesis fails;
  • a positive result opens more future options than it closes.

Consider an internal agent with a small wallet, one approved API supplier, and a complete log. If the payment rail is not reliable enough, the loss is limited to the prototype effort. The team still learns about authorisation, retries, records, and operating cost. If it works, the same pattern can expand to more resources and agents.

That is the difference between following a trend and creating an option on the future.

Infrastructure revolutions first look like inferior versions of the existing system

Steam power did not transform every factory immediately. A historical study of US manufacturing found that steam-powered establishments between 1850 and 1880 had higher labour productivity than establishments using hand, animal, or water power, with a larger effect in larger plants. The authors estimate that steam diffusion accounted for 22 to 41 percent of labour-productivity growth, depending on establishment size.

Electricity brought the next shift. Its value was not limited to replacing a steam engine with an electric motor. Factories organised around central shafts and belts had to be redesigned so that machines could use individual motors. Research on electrification connects productivity with capital deepening and organisational change, while historical work explains why the new technology required a redesign of the manufacturing plant.

The same pattern applies to software. New infrastructure looks disappointing when it replaces only one step in an old workflow. The larger shift arrives when the team changes the process around it.

LLMs showed the direction in 2018 without delivering a finished product

OpenAI published the first GPT work in June 2018. The system combined a transformer with generative pre-training on unlabelled text and then adapted the model to individual tasks. Training took roughly one month on eight GPUs and used several thousand books, approximately 5 GB of text.

The model was not a dependable general assistant. OpenAI’s 2018 account described brittle generalisation and surprising behaviour outside the training distribution. It also contained an important signal: language-model improvement correlated with better results across downstream tasks, with clear room for more data and compute.

The asymmetric bet in 2018 was not “we know what ChatGPT will look like”. It was a belief that generative pre-training would become a general software component and that learning how to evaluate, integrate, and constrain models would be valuable.

Teams that developed that knowledge before mass-market LLM distribution did not need to predict the exact winning product. They had a useful advantage when the capability became broadly available.

AI agent payments are in a similarly uncertain, earlier phase today. Models can call tools and execute workflows. They lack a standard way to discover a service, accept a price under explicit policy, pay, prove delivery, and leave a record that finance can reconcile.

Security starts before the first transaction

On 30 July 2026, Coinkite published a security advisory for certain COLDCARD firmware versions. The issue affected the entropy used to generate seeds. The manufacturer published fixed releases and migration guidance, with one important limitation: updating firmware does not change a seed already generated by affected software.

A user covered by the advisory needs to follow the current manufacturer guidance, create a new seed on fixed firmware, verify a new address, and transfer funds carefully. A strong, unique BIP-39 passphrase adds an independent barrier, but it does not repair a weak seed or remove the need to migrate.

The incident does not show that every hardware wallet shares the same problem. Devices use different hardware, firmware, and key-generation paths. The useful lesson is broader:

  • the seed is the root of the security model;
  • firmware and the generation procedure have to be assessed together;
  • an update can prevent a new error but cannot retroactively change an existing key;
  • a seed and passphrase should never be entered into a website, chat, computer, or untrusted device;
  • a migration needs a test transaction, on-device verification, and enough time to proceed carefully.

Self-custody removes a custodian between the owner and the funds. It increases control and places more responsibility on key generation, backup, recovery, and operating procedures.

An open network changes the geography of integration

A conventional payment gateway connects a merchant to banks, card networks, local payment methods, chargebacks, risk controls, and regulatory processes. Merchant availability therefore depends on the country in which the business operates. The Stripe global availability list, for example, distinguishes the countries from which a full payments account can be opened even though a merchant in a supported country can charge customers globally.

Bitcoin works differently. An address and transaction signature do not depend on a local card-network integration. Lightning extends this model with faster and lower-cost payments outside the main blockchain while retaining final settlement anchored in Bitcoin.

This lets a software team integrate one protocol into a product used across countries. It does not detach the business from the location of the company, customer, or transaction. Tax, consumer protection, anti-money-laundering, sanctions, invoicing, and data-protection rules still depend on the service being provided.

An open protocol can remove the need for some intermediaries. It does not remove a company’s responsibility for what it builds and offers.

Non-custodial is an important architecture boundary, not a universal exemption

The technical difference between custodial and non-custodial systems is substantial.

A custodial system holds keys or funds for a user. It has to protect shared infrastructure, control employee access, handle account recovery, and maintain an accurate internal ledger. A compromise of the operator can directly expose assets belonging to many users.

In a non-custodial system, the user retains the keys and authorises each transaction. The software provider can reduce custody risk and the number of situations in which it can unilaterally move customer funds.

The legal conclusion cannot be derived only from where the private key is stored. The EU Markets in Crypto-Assets Regulation looks at the activities being provided, including custody, exchange, execution of orders, transfer of crypto-assets, operation of a trading platform, advice, and other defined services. Rules outside MiCA may also apply, depending on the product and flow of funds.

A sound product review therefore does not end with “do we hold the keys?” It maps the complete flow:

  1. who controls the key;
  2. who selects the recipient and amount;
  3. whether the system exchanges one asset for another;
  4. whether the operator can stop, redirect, or reverse an instruction;
  5. whether a service is professionally provided to another person;
  6. which records and data have to be retained;
  7. where the provider and users are located.

The regulatory role can be assessed only from that complete picture. Self-custody is a useful design choice, but it should not be marketed as a shortcut around the law.

MiCA provides a common framework while tax remains national

MiCA introduced a more consistent EU framework for crypto-asset issuers and service providers. It defines categories of services, authorisation conditions, organisational obligations, and rules for tokens that reference one official currency, known as e-money tokens.

For a serious product, this is a positive development. A company can define the role it intends to perform, design the system around that role and, where authorisation is required, use a European framework for cross-border services.

MiCA is not a tax code. EU institutions explicitly recognise that Member States take different approaches to taxing crypto-assets. DAC8 increases tax transparency and information exchange, but it does not turn every transaction into one harmonised tax model.

Two practical consequences follow:

  • paying with BTC may create a disposal event in addition to the invoice for the underlying product or service, depending on the jurisdiction and the payer’s status;
  • a stablecoin can reduce volatility against the euro or dollar, but it does not remove invoicing, VAT, bookkeeping, counterparty checks, or tax-reporting obligations.

“Barter” can be a useful shorthand, but it is not a universal legal classification for every jurisdiction and business flow. Before production launch, the treatment should be confirmed with legal and tax professionals in the relevant jurisdiction.

Stablecoins and Lightning can separate value from transport

Bitcoin is both an asset and an open settlement protocol. For a company that budgets in euros, its changing market price can make planning and accounting harder.

Stablecoins address part of this problem by referencing a currency. They do not become ordinary bank euros: they have an issuer, redemption terms, a technical protocol, operational risks, and a regulatory classification.

Taproot Assets demonstrates how other assets, including stablecoins, can be issued alongside Bitcoin and transferred through Lightning channels. Nodes can provide atomic conversion between BTC and another asset while Lightning remains the transport network.

This creates an interesting architecture. The sender and recipient can account in a stable unit while part of the route and liquidity depends on Bitcoin. A technically instant conversion does not automatically mean that no legally or financially relevant exchange occurred. The system still needs to record what the user sent, what the recipient received, who performed the conversion, the applicable rate, and the fee.

The benefit is not the disappearance of records. The benefit is the ability to generate those records directly from a structured payment flow.

An AI agent needs a budget and scoped authority, not the company’s main wallet

Machine-to-machine payments make sense when the transaction value is below the cost of manual administration. Examples include one API call, a data request, a short GPU job, temporary storage, or access to a digital resource.

L402 combines HTTP 402 Payment Required, a Lightning invoice, and a restrictable access token. An agent can request a resource, receive a price, pay the invoice, and attach cryptographic proof of payment to its next request. The server can validate access without a conventional user account and shared subscription database.

That is a useful payment primitive. A production architecture still needs additional boundaries:

  • a separate wallet or tightly scoped account for each agent or workflow;
  • daily and per-transaction limits;
  • allowlists for recipients, resource types, and currencies;
  • human approval above a defined threshold;
  • an idempotency key so a retry cannot pay twice;
  • price and terms validation before authorisation;
  • an immutable record of the request, decision, invoice, exchange rate, fee, and receipt;
  • immediate key revocation and a workflow kill switch;
  • reconciliation between the payment log and the canonical business ledger.

An agent can autonomously execute an approved microtransaction. The organisation still defines spending policy, accounting treatment, and risk limits.

A closed machine loop cannot become a blind spot

Agents can technically pay one another in satoshis without returning to fiat after every transaction. A closed loop can reduce conversion costs and support small payments that are uneconomical on card rails.

The company should not record only the point at which it eventually withdraws profit. Every exchange has a business purpose, counterparty, value, and proof of delivery. Those facts are necessary for cost and revenue controls before tax is considered.

The better architecture connects the payment rail to the audit trail from the beginning. If an agent buys 50,000 API calls, finance should be able to link the total cost to individual invoices, the workflow that approved them, and the result the company received.

Automated bookkeeping can make that obligation cheaper. It cannot declare it unnecessary.

Will prices eventually be expressed in satoshis?

Bitcoin is currently used more often as an asset and settlement layer than as an everyday unit of account. Lightning and programmable API payments can expand its use without showing a price in satoshis on every user interface.

If more suppliers, buyers, and machines retain and spend the same unit, the need for conversion gradually falls. A price expressed directly in satoshis then becomes more practical. This is a possible direction, not an assumption on which a current business model should depend.

It is more useful today to design systems that can support multiple accounting and settlement units. An agent can hold a budget expressed in euros, execute an approved payment over Lightning, and store evidence that finance can understand.

Where the next big bang could happen

The next major shift is unlikely to come from one larger model or one new token. A more credible candidate is the combination of capabilities that already exist:

  1. an agent understands a goal and can use tools;
  2. identity and permissions define what it may see and do;
  3. an open payment rail lets it buy a resource without manually onboarding every supplier;
  4. a policy engine limits the price, recipient, and total budget;
  5. an audit trail connects the decision, payment, and delivered result.

When these five layers come together, an API no longer needs to know every user in advance, create an account, and send a monthly invoice. It can publish machine-readable terms, return a price, and release a resource after verifiable payment. An agent can then buy a small unit of digital work within rules set by its organisation.

Bitcoin and Lightning are not the only possible rail for such a system. They are interesting because they are open, global, and programmable, while L402 already connects an HTTP request, invoice, and payment proof. Stablecoins and Taproot Assets can provide a more stable accounting unit where needed.

Our prediction for the next few years is not that companies will give agents access to the main treasury. We expect a narrower and more useful progression:

  • paid API calls without a conventional subscription;
  • agent wallets with small budgets and tightly scoped authority;
  • payment proof as part of a machine-to-machine protocol;
  • automatic linking of invoices, exchange rates, and workflow results;
  • digital-service markets where software can buy one small unit of work.

The thesis may be wrong. Liquidity cost, regulatory obligations, security incidents, or weaker reliability may preserve existing credits, subscriptions, and centralised accounts. That is why the first bet should be small and measurable.

The big bang becomes visible only when infrastructure moves from a demonstration into a dependable part of an everyday workflow.

Our view

Bitcoin and Lightning give software teams an open, global, and programmable payment layer. MiCA provides clearer boundaries for part of the EU market. Taproot Assets, stablecoins, and L402 broaden the space for products in which people and agents buy digital services without a card checkout for every microtransaction.

The asymmetry is not a guarantee of success. It appears when a small, controlled experiment today creates knowledge and technical options that would be expensive to recover later if the market grows.

The main opportunity is not a claim that the protocol removes regulation. The value lies in embedding payment, authorisation, and proof directly into a software workflow.

We would begin with a constrained use case: one resource, known recipients, a small budget, clear accounting treatment, and a complete record. Currencies, jurisdictions, and agent autonomy can expand after that foundation has been tested.

This approach leaves room for innovation while keeping the system within boundaries that can be explained to legal, finance, users, and engineering.

This article is a technical analysis, not individual legal or tax advice. If you are building a non-custodial product, a Lightning integration, or a controlled payment workflow for AI agents, talk to HILLS Lab.