Start With What Survives

A ten-year blockchain forecast can easily become a collection of today's most promising technologies. Execution gets faster. Proofs get cheaper. AI becomes more capable. Assets become more programmable. Connect those developments and a future architecture appears to follow.

Ten years is also enough time for the names to disappear. A protocol can be replaced, an implementation can fail on economics, and apparent demand can turn out to have been sustained by subsidies. Progress in several components does not establish that they converge on one system.

I would begin with a different question: what will still make cooperation difficult in 2036?

Independent parties will have different interests. Resources will remain scarce. Information will be incomplete. Systems will fail, and some participants will behave strategically. More capable software will still need authority to use someone else's resources. A digital record will still need a defensible connection to the physical or legal claim it represents.

The problem can remain while the best place to solve it changes. Verification may replace an intermediary; a better intermediary may make a distributed protocol unnecessary.

Imagine a procurement task in 2036. Software is authorized to buy data and compute within a fixed budget, with commercial-use rights and regional restrictions. Finding suppliers could be nearly effortless. Payment without delivery, duplicate charges, revoked authority, and missing acknowledgments still require defined behavior.

Blockchain Has to Earn Its Place

Databases maintain internal consistency. Platforms guarantee delivery and manage refunds. Audits constrain operators. Contracts assign rights and remedies. Those alternatives will improve too. A future blockchain system has to compete with their future capabilities rather than their historical limitations.

Its stronger case arises when independent parties need to rely on shared state but cannot accept one participant's unilateral control over the record or its rules. A transfer may need to remain linked to payment. Participants may need to establish for themselves whether an obligation was fulfilled, even if the original operator stops cooperating.

Shared state means more than everyone keeping a copy. It requires an agreement about which changes are valid, who may authorize them, and when the result becomes authoritative. Replication, verification, and consensus can make some of those agreements harder for one party to violate.

The guarantee depends on the actual system: validator independence, cryptographic assumptions, access to data, and governance. Distributed storage alone does not provide it. Nor does a protocol remove the people able to change its rules or the institutions supplying external facts.

Another possible advantage is continuity beyond a particular operator. Participants may retain access to evidence or assets when a provider leaves. That can reduce dependence, but exporting data is not equivalent to migrating a business relationship. Exit needs its own mechanism and explicit conditions.

I would evaluate adoption through the total cost of the relationship. Independent checking and limits on unilateral control must create enough value to cover consensus, governance, privacy protection, integration, and operation. Where an accepted operator already provides adequate guarantees, an additional consensus layer may have little purpose.

A business may need shared verification at only a few boundaries. Internal inventory can remain in a database, delivery disputes can remain contractual, and cross-institutional commitments can use a common protocol. Selective use makes both the guarantee and its cost easier to evaluate.

AI Moves the Constraint

On the construction side, cheaper implementation makes more designs testable. Engineers can compare execution models, inspect state access, generate candidate tests, and explore compilers or proof systems with less mechanical effort. Advances in formal methods and security analysis may follow, but claims of correctness still require evidence appropriate to the claim.

Faster construction also produces more assumptions to inspect. Five complete-looking implementations create five sets of failure paths, dependencies, and incentives. Tests can reproduce a mistaken contract with excellent consistency. Generating more of them does not recover a missing requirement.

AI can assist verification, but verification needs an external standard. Someone must establish the invariant, the failure model, and the evidence required to accept a change. If understanding and validation cannot keep pace with production, the result is complexity the organization depends on but cannot confidently own.

On the usage side, agents could increase the frequency of economic action. Software might purchase data, invoke paid services, and allocate compute within a delegated budget. Faster action also means faster propagation of authorization mistakes and retry errors. Precise boundaries and reliable outcome detection become more valuable.

That does not imply consensus for every action. Search, inference, and internal coordination usually have no reason to become shared transactions. Thousands of operations may culminate in one commitment or settlement event. Prepayment, netting, and conventional payment systems remain plausible choices.

AI may also strengthen integrated platforms. A provider can combine discovery, identity, permissions, payment, and dispute handling while absorbing complexity on the user's behalf. An open network has to offer a material benefit to compete with that service.

I expect authority and verification to matter more as autonomous action expands. The size of the open agent economy will depend on reliable tasks and customers willing to pay for them.

Capabilities That Can Outlast Their Implementations

Several capabilities belong in a ten-year technical map. Protocols, applications, and institutions will share responsibility for providing them.

Authority must be specific enough to constrain action. Purpose, amount, duration, and permitted counterparties matter. “Buy the best dataset” has to become conditions a system can check. A lower price cannot compensate for violating a confidentiality restriction.

Keys and accounts are vehicles for authority. Account abstraction and session permissions can limit delegation, but work already in flight is harder. A payment is submitted, the connection times out, and permission is revoked. Retrying can duplicate a charge; canceling can leave a completed order unaccounted for. The system has to establish the payment's status before proceeding. A login check cannot resolve that sequence.

State changes must also be inspectable. Participants need to know whether a transition followed the agreed rules and whether the state they rely on is authoritative. Re-execution, cryptographic proofs, and other explicit verification arrangements can provide different guarantees at different costs.

Verifiable computation offers a way to reduce repeated work, but the statement being proved matters. Correct execution of a bad specification or false input can still produce an unacceptable business result. Validity, zero knowledge, and data availability are distinct properties. A proof cannot silently stand in for all three. Ethereum's explanation of zero-knowledge proofs

Settlement must define completion. Money being debited, becoming usable by the recipient, becoming irreversible, and discharging a legal obligation may occur at different boundaries. Systems exchanging results need to understand those differences and agree on failure handling. Delivering a message is only the beginning of interoperability.

Verification also needs a deliberate disclosure boundary. A supplier may have to establish eligibility without publishing its entire customer base. Some facts must be public, others disclosed to authorized parties, and some may be established without revealing the underlying information. The privacy design must cover the actual observable signals, including timing and relationships.

Data, recovery, and exit belong together. A proof cannot replace the information required to reconstruct state. After a crash or provider failure, participants need to identify committed results, avoid repeating external actions, and continue or terminate work under defined conditions. An exit path that requires the departing provider's cooperation has a dependency worth stating explicitly.

Finally, rules must be able to evolve without making existing obligations unintelligible. An upgrade may repair a vulnerability or change a participant's rights. Who can initiate it, what notice is required, how historical evidence remains verifiable, and whether dissenting users can leave are architectural questions.

A Possible Architecture for 2036

From those requirements, I expect a system with more explicit divisions of responsibility and several distinct trust domains.

People and software express goals through applications. Authorization converts those goals into permitted actions. Execution systems perform the work and submit evidence where an outcome must become shared. Settlement establishes authoritative state and finality. Institutions handle custody, legal effect, and disputes that computation cannot decide.

The sequence does not need to live on one chain. Banks, enterprise platforms, and public networks may retain their own rules and connect through limited, explicit contracts. Their different interests and legal obligations provide a reason for multiple domains, independently of any preference for modular architecture.

Integration can still be the better choice for a particular workload. Connections impose latency, operational dependencies, and governance cost. A diagram with more interchangeable components may describe a system that is harder to recover and more expensive to use.

Where proof generation is economical, specialized executors could perform substantial work while many participants check results at lower cost. Where proving delay, expense, or concentration outweigh the benefit, re-execution or other arrangements can remain competitive. The degree of separation should follow the workload.

The common core should be restrained. Every rule placed there expands what participants must jointly understand, upgrade, and recover. A smaller core can reduce the common failure surface. Moving functionality outside it, however, moves complexity rather than deleting it. External availability and responsibility still belong in the argument for the whole system.

The same reasoning applies to ordering. Conflicting claims over one asset require a common resolution rule. Two independent data-analysis tasks may not require a shared global sequence. There is a reason to minimize mandatory coordination, but independence has to follow from state dependencies or enforced constraints. Splitting an application into services does not establish it.

Safety and continued service also need separate treatment. Delaying completion has different consequences from accepting an invalid result. A system may have to stop accepting changes during a failure to preserve its commitments. Users then need defined conditions for waiting, cancellation, or exit. A recovery mechanism that bypasses verification becomes an attack path. Speed, availability, and recovery authority must fit within the same security boundary.

Performance Includes What Happens Later

An executor may process many operations while evidence queues up, state awaits confirmation, or an external payment cannot be reconciled. The user has not received the promised outcome. A transaction count at one layer can describe a different kind of work from the count at another.

I would measure completion under explicit safety conditions: latency, total compute, storage, bandwidth, capital use, and behavior under failure. Shared-state contention, history growth, and queueing remain costs even when an isolated execution benchmark improves.

Recovery changes the comparison. A service can be cheap during normal operation because it omits information needed after the operator disappears. Another service pays a continuing cost to retain that information and may be cheaper over the full lifecycle. The first has deferred a cost, not necessarily eliminated it.

Comparable workloads, finality, availability, and fault conditions are prerequisites for a useful claim. The relevant direction is the cost of completing a trustworthy outcome, with the outcome and its guarantees defined. Giving throughput a new name would not accomplish that.

This is why high performance will remain important without making maximum single-chain TPS the organizing objective. Performance has to connect local speed to dependable completion, including the conditions under which progress stops and recovery begins.

Institutions Remain in the Architecture

Finance makes these boundaries particularly visible because money and assets already encode institutional relationships.

Businesses want less delay and reconciliation. Buyers and sellers want payment and delivery to constrain one another. Adoption also depends on legal acceptance and who carries the risk of failure.

Digital representation does not make instruments interchangeable. A stablecoin, a bank deposit, and a security can expose similar transfer interfaces while carrying different claims, redemption conditions, and default risks. Efficient token transfer says little about enforcing the claim during insolvency. A verified warehouse receipt does not remove the need to establish that the goods exist.

Monetary sovereignty, issuer responsibility, capital movement, consumer protection, and jurisdiction will continue to shape networks. Their detailed rules can change; technical compatibility does not automatically reconcile the underlying interests.

Current approaches in the United States, the EU, Hong Kong, and mainland China illustrate that divergence. The first three have distinct frameworks for payment stablecoins or crypto-assets. Mainland China prohibits specified virtual-currency activities and domestic asset-tokenization activities, with an exception for duly approved tokenization activities through designated financial infrastructure. These arrangements are evidence of institutional differences, not a forecast that regulation will converge. U.S. statutory text, ESMA's regulatory overview, Hong Kong's announcement, Mainland China's 2026 notice, reproduced on a government website

Institutional experiments also establish bounded claims. The BIS's discussion of trust in money and its prototype work combining commercial bank deposits with central bank reserves show why legal and technical design have to proceed together. They do not establish a universal production architecture. BIS, Anchoring trust in money, Official account of the cross-border payment prototype

Control can move to new locations too: agent interfaces, execution markets, proving hardware, or compliance gateways. To assess whether power is dispersed, I would examine who can block action, change fees, access information, and restrict exit. Counting base-layer nodes answers only part of that question.

Responsibility must remain legible across the task. Someone defines the objective, grants authority, accepts inputs, and maintains the rules. A successful execution proof cannot replace that chain when the failure concerns the decision or the underlying claim.

Evidence That Would Change My Mind

My expectation is that blockchain can become part of the infrastructure for cooperation across independent parties, especially where unilateral control is unacceptable and outcomes need independent inspection. It could be used more widely while appearing less often as the name of a product.

If institutions and centralized services keep solving the problem more cheaply, blockchain may remain concentrated in a smaller set of valuable applications. I would accept that outcome.

I would watch four kinds of evidence: sustained paid demand without subsidies; less reconciliation, waiting, and dispute cost between independent institutions; practical independent verification and provider exit; and lower total execution, verification, data, governance, and recovery costs under comparable business conditions.

Usage driven mainly by incentives would weaken the demand argument. Interoperability dependent on a few mandatory gateways would weaken the independence argument. Cheaper proofs accompanied by higher governance and recovery costs would weaken the economic argument. More agent activity counts as evidence only when real tasks complete reliably.

Those observations can guide engineering now. Does a new technology improve task completion, independent checking, or recovery? Replacing an implementation without improving any of them is not yet progress.

Cryptographic schemes need a path to replacement as well. NIST has released initial post-quantum standards and encourages migration preparation. That does not establish when quantum capabilities will threaten a deployed system. It does justify reducing a long-lived system's dependence on an irreplaceable scheme. NIST's post-quantum cryptography program

In ten years, today's protocol names may be unfamiliar. We will still need to establish who may act, what happened, why another party should accept it, and how failure can be repaired with responsibility intact.

Blockchain earns a place in that future if it can maintain those relationships at a better cost. That is the progress I would want its architecture to demonstrate.

Written from the perspective of October 5, 2026. Persistent constraints are distinguished from candidate implementations. The 2036 architecture is conditional; present-day roadmaps and experiments do not establish the forecast.