Scaling regulated openness

In the previous post, I wrote about the intersection between crypto and regulations. I ended by writing that I enjoy working in this domain, as it's a very interesting way to apply distributed systems. I also wrote that crypto has branches that stay within the confines of the law, as well as spheres of utility that lend themselves to dubious activities, and I'd rather not enable the latter. Discussing with Alla about this, she dubbed the former branches "regulated openness" and asked an interesting question:

What are the new ways for regulated openness to scale?

Ways to scale

One important vector for scaling regulated openness is making it ridiculously cheap and simple to use. This would enable entrepreneurs, businesses, or developers to be fearless in building with these kind of primitives, and they are the ones doing the scaling up and out. This is not a new way, but a well-worn approach. The steps to take in applying this approach, however, will be new, and I'll give some examples of such steps later.

It is not easy to lower the entry barrier. Using regulated openness involves very rudimentary building blocks that are neither simple nor cheap nor fast to build with, which deters developers.

Some of the rudimentary stuff

Two problematic building blocks are transactions and wallets.

There was a spur of activity on introducing intents as a friendlier API to replace transactions. But that direction seems to have become a deep rabbit hole. I am not an expert, and I'd be happy to be proven wrong here, but I don’t see an end in sight or a concrete product or use-case.

For wallets there was more progress but it's also marginal in my understanding. The user in 2025 still needs to cross a chasm and feel comfortable approving an action, whether it’s called “sign in” with email, social, or non-custodial wallet. It feels scary and important. Whenever I encounter having to sign something using an online wallet, a part in me resists.

We could argue that these two building blocks fit AI agents like a glove. I guess that’s right, actually. Agents are not important decision makers, however. And they may even generate a huge volume of transactions, but I don’t see how they can control anything above pennies in the next several years. I may be off and if so, then scaling regulated openness is going to be a lot easier than I anticipate with agents bearing most of the load.

Instead of transactions and wallets, I don’t know what the right levels of abstraction look like, as in this sketch above. Similarly to how the 2000s were too early for many internet businesses, today is too early to see exactly where technology trajectories will overlap to enable simpler use-cases that scale with ease in regulated, open finance.

The early 2000s were not ready for web2 businesses because the technology and society of that time lacked many supporting features and sophistication. Among the obstacles that come to my mind: online payment rails and mobile wallets didn't exist, browsers and client-side scripting languages were poorer and lacked standardization, laptops and end-user devices were very primitive in the 2000s, browser security was much poorer, the average internet consumer was illiterate in internet usage (by today's standards), and the available bandwidth and connectivity was nowhere near sufficient to provide good UX in online browsing or shopping.

A couple of interesting challenges

Like I wrote above, the general approach of lowering the entry barrier will entail new steps. I don't know those steps because they will be discovered in trying to solve new problems and build novel, interesting, and weird products. What follows are two starting points for such weird products, which I formulate in terms of challenges.

Walletless applications

One specific & very interesting open challenges for me is to envision and proof of concept a walletless application on top of a blockchain. I don’t mean that the product should work without a crypto wallet and should instead employ email or other login. None of that. The product should be completely open, no authentication whatsoever. The user opens it and may use it productively. Linking the product to a human or onchain account should be optional, deferred, and off the critical path of interactions.

How would such a product work exactly? The designer will need to think deeply through concrete alternatives to both the transactional model for interfacing with the server (the blockchain) and the wallet-based, reactive lifecycle of user experience.

There’s more than meets the eye to this challenge, however. Not all products are amenable to such an alternative UX. Excalidraw is a good example of a product that is amenable, and it's outside of the crypto domain, at least today. The user interacts with the application by drawing freely while their browser automatically saves progress without soliciting any explicit action or approval. It is highly non trivial because most blockchain-based applications, in contrast, assume interactions between the current user and other users on the underlying ledger (i.e., server). This assumption is backed-in for blockchain systems today. The notion of a user progressing on their own, using local-only data does not exist in blockchain applications.

The bottom line challenge is, to put it differently: What is the overlap between this segment of walletless applications and blockchain use-cases? This overlap will hint at the right levels of abstraction to unlock new experiences and scale regulated openness. To be more precise about walletless applications, as the sketch above shows, there may be wallets and transactions in the background of these applications, perhaps, but the user should not care about them.

Peer-to-peer (actually) applications

Another challenge which fits in the narrative of scaling regulated openness is that of building purely peer-to-peer applications.

A 10$ bill is peer-to-peer, but I argue that Bitcoin is not, nor Ethereum or any other blockchain today. I realize this may be a heretical stance, and moreover, there may be no practical reason for me to take this stance, because Bitcoin and Ethereum are as neutral as it gets, for all purposes the network is decentralized, and users rarely if ever encounter situations of censorship or extractive behavior. Still, the intermediary is there – the Bitcoin global ledger, or the Ethereum mainnet state machine – running on many other servers. The presence of this intermediating servers is the smoking gun clearly indicating these are not peer-to-peer systems.

Suppose I want to pay my barista. Even if I run my own Bitcoin miner or Ethereum validator, I still needs to “convince” hundreds or thousands of other machines in the world to accept and execute my payment. This payment only concerns me and my barista, we are the two peers – and yet, there’s all these other replicas in the world involved in my transaction, and they are not peers as far as this particular exchange goes.

Yes, these networks are decentralized, but they are not peer-to-peer. There is an extra party, namely, the replicated state machine living in numerous other servers around the world, anonymous or permissionless they may be, be they are there, monitoring and keeping a copy of my actions.

I agree Bitcoin miners are operating a peer-to-peer protocol. This protocol allows them to maintain each their individual copy of the Bitcoin ledger in a distributed and permissioneless way. But that is among themselves, not the servers and me (the client). My transaction (give 5 CHF to X) is that of a client that a server (a miner) receives and processes, and until I get the approval of that server (whether it is decentralized or not), my action is not done.

What would a system look like where no one else requires participation when I invoke a peer-to-peer transaction – no miner or validator – except for precisely the peers involved? There is also a slightly weaker form of this challenge: extra actors may be involved in transactions, but they remain off the hot path. I sketched a visual intuition of this in the drawing below.

Fin

The high level approach to scaling regulated openness I discussed here – lower the barrier – is not new, and it is also not specific to regulated openness: it would have similar effects on non-regulated sectors of the industry. I was wondering while drafting this whether there are methods or ideas for scaling access that are specific to the regulated domain, and there probably are, but have not encountered any in my experience so far. The search continues.

If anyone is interested in riffing on any of the two challenges above, please reach out, it would be cool to built a proof of concept and advance these ideas – even if they may prove to be dead ends.