But more choice is not always a good thing.

Choice burdens users with unnecessary responsibility.

Users must discover, analyze and contextualize all of these potential choices and decision trees. It’s a high-cost for most people. One that I suspect most people don’t want to pay - especially considering it’s a job best suited for machines.

So how can we solve this problem? Let’s start by looking into the past for answers.

Web 1.0 was defined by search engines.

Web 2.0 was supercharged by social media.

Both underpinned by indexing and graphing i.e. mapping of the digital world.

So why would Web 3.0 be any different?

But instead of indexing information and graphing relationships….

We should be focused on contextualizing actions.

Discoverability

As stated previously blockchain APIs (smart contracts) are open and accessible by default - available 24/7 and ready to be acted on.

But in many regards the "choice" of what API to use depending on what outcome is desired has already been made. In a finite system there is best path or at the very least a handful of best paths that the user will ultimately choose from.

The difficult part is actually finding, contextualizing and than executing the right blockchain actions. And for most users finding and contextualizing actions is not the important part. It's a means to an end.

The critical part is the execution. The authorization of an action.

Discovery is no longer a job for humans. It's a job best suited for algorithms, computers and machine learning. Systems that can interpret "intents" and recommend a constrained collection of actions.

Users want outcomes. Not choices.

Contextualizing the World of Web3

Solving the discoverability (and potentially security) challenges of Web3 ultimately requires mapping, indexing and contextualizing onchain APIs.

Without awareness of what exists and how it functions, it's arguably not possible to scale the Web3 user experience - we can’t expect users of tomorrow to behave like the early adopters of today. In other words scouring telegram channels, scrolling through X for hours and staying up-to-date with niche podcasts is not the right approach to onboarding millions of users into Web 3.0.

If the successes of Web 1.0 taught us anything though it’s that users want simple.

They don’t want to be inundated with choices and information. Users want answers to their questions. And they want it now.

But Web 3.0 is different - users are not looking for information.

Users are looking to take action in the digital world.

It’s not about finding the best restaurant or learning about a hot new topic.

Web 3.0 is about updating bits and bytes. Taking action digitally.

Intent Engines

Similar to the "Web 1.0 Era of the Internet" where data required indexing to reach a critical mass, so too does Web 3.0, but instead of a cataloging the world’s information in search engines, we need intent engines to contextualize actions.

But what exactly is an intent engine?

Decision Trees

Blockchains are "finite" space systems.

An environment with measurable objects and knowable properties i.e. state mutators. They have no immediate side-effects outside of the “digital world” in which they live i.e. it’s a self-contained state machine.

And the objects in this finite space are inherently composable and group-able in sets. For the scientifically minded it’s perhaps even a perfect environment to apply set theory or more specifically informal/naive set theory.

https://en.wikipedia.org/wiki/Set_theory

Because of this unique blockchain properties, all potential actions can be cataloged and decision trees defined. Which is to say given State A an optimal route can be created to reach State Z.

But what does this look like in practice?.

For simplicity let’s use the USDC object as the starting point. A popular stablecoin.

There is a finite amount of “actions” that can be taken with USDC, especially when we start to add constraints. So let’s constrain the USDC decision tree to only objects that can be contained within a “USDC Money Market” set. In other words, all the protocol objects should have similar features: depositing, withdrawing and yield generation.

For now our “USDC Money Market” set will be limited to Compound, Aave and Morpho on a single chain. Each offering unique “yield rates” for USDC.

And quickly we can see their is an “optimal” path if you consider all protocols equal. Or at-least similar enough, where it’s worthwhile to draw comparisons between them.

So what?

This information can already be discovered in applications like DeFi Llama or many of the other yield aggregators that exist in the Web3 space.

And you’re correct in saying that, but that information is constructed in a way for humans to consume, which is exactly what we want to avoid. It puts the onus on the user to regularly check those interfaces and afterwards craft the necessary transactions to enter the new position, which might include exiting another position and thus interacting with multiple interfaces -- a far from an ideal user experience.

Instead of requiring users individually traversing decision trees, what we want is machines traversing these decisions trees with the users “intent” and “constraints” in mind and recommending actions.

Surfacing the best opportunities at the click of a button.

I have mad ❤️ for applications like 🦙 DeFi Llama.

They make being a power user in the DeFi space even possible -- all for free!

Without these type of applications, the blockchain would be an even harder and more treacherous place to navigate.

But I do question how scalable this experience is for “regular” users?

• How many people will regularly check these “discovery” applications?

• What are the chances they run comprehensive cost and risk analysis?

• Is it even possible for them to contextualize and reason about all the choices?

I think the answer to those question is “never” and “no” - most users don’t have the desire to uncover new opportunities and also take the time to enter those positions.

It’s too much. And besides, it’s a better job for 🤖 machines anyways.

Action Snapshots

Perhaps by now I’ve sold you on the idea of “Intent Engines” and the need for a machine readable standard for traversing decision trees in the world of Web3.

But we still have a problem.

How do we get users from Point A to Point Z?

Remember a few moments ago where I was like “Yeahhh, science bitch!” and talked about blockchains being a finite space system with measurable objects and knowable properties?

While that’s important.

So let’s break that down a bit before building it back up into something useful.

• Blockchains are a finite space system i.e everything within them is measurable.

• Smart contracts (and the related state) are the objects occupying that space.

• Functions on these smart contracts are the knowable properties.

As an aside, but worth mentioning is this finite space system is a uni-directional state machine. In other words no takesies-backsies. We have a single agreed upon history.

Soooo, what can take away from this?

All decision trees in this given “finite” space system can be observed and “actions” can be encoded/dispatched to predictably and reliably update these objects.

O.K. enough already, I hear you thinking. That’s just a bunch of technical mumbo jumbo.

What point am I really trying to make?

It’s possible to build a “crypto super app” that takes advantage of these properties and verticalizes the user experience. To drastically reduce the amount of friction when interacting with blockchain protocols - specifically Open Finance.

Examples are good, so let’s start there.

Let’s assume a user has USDC deposited in Aave, but a better position is in Morpho.

As of today, what’s required for users to make this switch between protocols?

1. Discover the opportunity by visiting a DeFi yield dashboard.

2. Run a cost analysis in terms of gas and expected deposit length.

3. Go to the Aave application interface and withdraw the funds.

4. Wait for the transaction to be confirmed

5. Possibly bridge the USDC to a different chain with the higher yield opportunity.

6. Wait for the funds to arrive on the new chain.

7. Go to the Morpho application interface and deposit the funds.

In short, it’s a bad user experience and to be quite honest not something you would expect when interacting with a “world computer” in 2024- it’s clunky. Fragmented.

We want simple. Elegant.

An interface where only the most important decisions are shown to users.

Everything else (unless requested) is unimportant.

Intent Engine Building Blocks

At the core of an "Intent Engines" is machine-readable language for traversing Web3 decision trees and generating action snapshots. A simple, but effective method for mapping blockchains, smart contracts and functions, in a way that can automatically generate user interfaces and help guide users towards an optimal path.

Here is very low fidelity, pseudo-code example of what a “Money Market Set” ready to be consumed by an Intent Engine could look like.

https://gist.github.com/kamescg/b1981cca0e5057c6c3a685069a498494

Not all too dissimilar from Uniswap Token Lists.

The set includes Aave and Morpho objects, which contain instructions for how to retrieve data related to the objects, and how to take action on the objects.

Let’s talk about those objects.

Blockchain Object & Required Fields

What’s required to add a blockchain object to a set?

First let’s identify what we need to automatically generate action snapshots.

• We need to observe past and current state about the object i.e. data.

• We need to be able to interact with those objects i.e. actions.

Pretty basic stuff, right?

We’re not going for complicated. We’re going for good.

Data

A blockchain object should contain a data field that list the various ways to request data about the object’s current and historical state.

For example a “money market” object will contain predictable metadata structures: apy, historical apy, utilization, tvl, volatility, etc…

"data": [
  {
    "type": "apy-historical",
    "source": "api",
    "action": "read",
    "description": "Current APY for an asset.",
    "url": "https://.../$chainId/$token",
    "inputs": [
      {
        "name": "chainId",
        "type": "number"
      },
      {
        "name": "token",
        "type": "address"
      }
    ]
  },
  {
    "type": "apy",
    "source": "onchain",
    "description": "Current APY for an asset.",
    "chains": {
      "1": "0x0000000000000000000000000000000000000000",
      "10": "0x0000000000000000000000000000000000000000"
    },
    "functionSignature": "apy(address)",
    "inputs": [
      {
        "name": "asset",
        "type": "address"
      }
    ]
  },
  {
    "type": "utilization",
    "source": "api",
    "action": "read",
    "description": "Current utilization rate for an asset.",
    "chains": {
        "1": "0x0000000000000000000000000000000000000000",
        "10": "0x0000000000000000000000000000000000000000"
      },
      "functionSignature": "utilization(address)",
      "inputs": [
        {
          "name": "asset",
          "type": "address"
        }
      ]
  }
],

And important to note is the object doesn’t care how this data is consumed (that’s a job for the Intent Engine and users constraints) but rather only the data is exposed in accordance/relation with the set it’s contained within.

In other words “Money Market” set objects will likely to contain different data fetching instruction say from “Liquidity Provision” set objects. Different sets of objects. Different data concerns. Different modeling requirements. Different decision trees.

Actions

Once we’re able to observe the “state” of an object. It’s time to take action.

Thankfully that’s the easy part.

Every public smart contract contract function can be represented as an application binary interface a.k.a ABI object. Which as luck would have it, are instructions for how to interact with a blockchain object.

"actions": [
  {
    "type": "exit",
    "name": "Withdraw",
    "description": "Withdraw tokens from the Aave money market.",
    "chains": {
      "1": "0x0000000000000000000000000000000000000000",
      "10": "0x0000000000000000000000000000000000000000"
    },
    "functionSignature": "withdraw(address,uint256)",
    "inputs": [
      {
        "name": "asset",
        "type": "address"
      },
      {
        "name": "amount",
        "type": "uint256"
      }
    ],
    "details": [
      {
        "name": "asset",
        "label": "Asset",
        "description": "The asset to be deposited"
      },
      {
        "name": "amount",
        "label": "Amount",
        "description": "The amount to be deposited"
      }
    ]
  },
]

The ABI tells us how to encode an action and update the objects state.

And the best part?

We can compose these actions together, so all the necessary state mutations can happen in a single blockchain transaction*.* Removing the need for the user to visit multiple interfaces or even being concerned with the underlying architectures.

Automatically Generated User Interfaces

So what can we do with a complete map of the Web universe?

We can use our map of the “finite space system” to automatically generate directions for users to follow. To help them safely traverse this open and free, but often dangerous landscape. All without getting lost in a sea of choices or encountering the modern day pirates.

Will taking this approach be easy? No, probably not. It will require carefully constructed abstractions. A delicate balance between simple and complex. And lots of data processing and modeling.

Will it be worth it? Yes, probably. We can’t expect the next generation users to manage onchain wealth bouncing around between different chains, applications and protocols.

People want outcomes. Not choices.

Conclusion

The current blockchain user experience is kinda broken.

Browser based dApps were a necessary evolution in the world of Web3, but now it seem to be a limiting factor to bringing blockchain technology to the masses. Introducing too much friction and complexity into the process - for even the most sophisticated of users.

We’re not taking full advantage of a blockchains inherit properties.

Instead we’re asking humans to perform tasks best suited for machines.

And perhaps scaling the Web3 user experience means asking what worked in the past?

And what worked in the past was indexing the world’s information and graphing online relationships i.e. Web 1.0 search engines and Web 2.0 social media platforms. To make information on-demand and relationships move at the speed of light.

Why would we not expect this same strategy to work for Web 3.0?

But instead of indexing information and graphing relationships, the next frontier is contextualizing “actions” in the ever evolving World Wide Web3.

So, the question remains.

Are dApp interface and wallet browsers (smartphone or extension) the best way to onboard millions of users onchain? Or is there something better waiting for us in the future?

But something about the current Bitcoin ETF narrative has my spidey senses tingling.

I get it. The whole thing is exciting. Suddenly “large institutions” have a way to play the crypto game. You might even say the “herd” is coming and they’re right on the horizon.

https://twitter.com/RyanSAdams/status/1743294090886697058

But nothing is ever “just” good.

And that’s kind of the scary part. Everyone is hyping up ETFs like there the best thing since the invention of blockchains. It’s all sunshine and unicorns. But, that can’t be true.

Actions have consequences - even if we don’t always think about them.

The Other Side of the Token

For the sake of argument let’s make a bear case for cryptocurrency ETFs.

And ask ourselves, what’s really at stake here?

Control.

But before we begin, let’s put on our conspiracy theorists hats.

We won’t keep them on long though. Promise.

Have you watched Mr.Robot? If not you should!

It’s a show about a genius computer hacker. And in this fictional story is a company called E-Corp a.k.a. Evil Corporation. Think of it like the IRL Blackrock. They dominant the financial markets. They’re the “big boys'“ in the game.

And In this made up world world exists a “decentralized” cryptocurrency call eCoin. But in reality this cryptocurrency is not very decentralized. It’s a ruse. A fallacy.

A misrepresentation.

Who controls the network? The validators? The liquid staking derivatives?

You guessed it! Evil Corporation.

It’s anything but decentralized. The network is captured.

How?

The big boys have big boy toys. Deep pockets. Far reaching tentacles. And they’re sophisticated. And if we’re being honest the “little” guy has no way of competing.

Left unchecked the obvious winner is always going to be the E-Corps of the world.

It’s a simple as that.

Reality is Crazier than Fiction

Which begs the question…

• Why are we so happy about this fictional story becoming reality?

• Why are willingly handing over the decentralized networks to the baddies?

• Why are we not practicing adversarial thinking?

• Why are we inviting a wolf, so plainly dressed as a sheep, into our homes?

• Why are we selling out to the banksters, without even a fight?

Why isn’t the cryptocurrency cypherpunk community rallying, or at the very least, making a ruckus about the unfolding situation?

I can’t be the only one who thinks it’s a little strange that the only news about the upcoming Bitcoin ETF is all positive. Why no dissenting voices?

Ask yourself, isn’t a little odd that the new cryptocurrency regulations are coming into effect at exactly the same time Bitcoin ETFs are being approved by the SEC?

Even if it’s just a coincidence it’s worth examining.

So examine we shall.

The Silent Takeover

We live in interesting times. The world can admittedly be a dangerous place.

And for better or worse we do live in a surveillance state.

Global governments, and corporations, want to know what you’re doing. At all times. Often times under the pretext of security. And fine, that’s a reasonable argument.

But where is the line drawn? Do the people get a say? Are their ulterior motives?

Bitcoin, while a public ledger, is still pseudo-annonymous. You don’t really know what account is owned by which person or organization. And since we’ve established we live in surveillance state, that’s going to be a problem for the maintainers of this status quo.

Bitcoin can’t happen. The cypherpunks can’t win the day. It’s not allowed.

But what if that’s not the real reason? What if “surveillance” is a means to an ends?

Not for security, even though may be a benefit at certain times… for certain people.

But what if it’s about power and control?

And let’s be real, that’s not a wild thought or idea. History, time and time again, has shown us that “governments” and “corporations” have ulterior motives and will take extreme measures to reach their goals.

What… WW2 ended and that was last time humans wanted to dominate the world?

I don’t think so.

These sophisticated players simply evolved. Adapted to the modern world. You don’t need to control populations at gunpoint anymore. That’s what the IMF (International Monetary Fund) is for.

O.K… hold on! We’ve gone full conspiracy theorist now. Perhaps even a little extreme?

Maybe. Maybe not. But at the end of the day we’re just asking questions and trying to see the world as it is, not the world as we want it to be.

The banking system is a black hole for power. It’s inevitable.

Money makes the world go round. It’s not Democracy. Sorry.

And what does power attract? People who want to harness it and hopefully even use it for good. But power can also be used for bad i.e. domination and control.

I don’t know about you, but when I think of the “banker” archetype, the words good and trustworthy don’t always come to mind first. And why would they?

Money is a power game. Being good and trustworthy isn’t always a winning strategy.

It begs the question are the people sitting atop these modern power structures actually serving the commonwealth? Yes, probably some. But probably many who are not.

And those are the ones I am worried about.

The players who’s motives, tactics and justifications are opaque. Why? Because being blind to half the chessboard is a losing strategy.

The Game - A Doomsday Scenario

Hopefully by now I’ve made the case for why it’s important to examine both sides of the Bitcoin ETF token. And perhaps even inspired you to ask a few questions yourself.

And while I think my case, made via allegory and a reminder to always question arguments from authority was fairly strong, it will probably be even better to paint a picture of a potential doomsday scenario.

Bitcoin will be captured.

Being King isn’t always great 🎯 it’s a target on your back. And who wants that seat?

The financial institutions.

In the coming years their will be a coordinated attack to control, subvert or destroy the Bitcoin network. With a much higher chance for control or subversion. Destruction is an outdated strategy - one for unsophisticated players. It disrupts the game too much.

Besides the financial institutions already have battle tested weapons - surveillance.

And it’s already happening.

By now you’re probably aware of the US regulations requiring users to report the name, social security number and address of a sender when they receive $10k or more in cryptocurrency transactions.

https://twitter.com/mdtrade/status/1743670200371667328

It’s analogous to the current rules requiring people to report $10k+ cash transactions.

These new rules benefit the institutions. They already have the resources required to abide be these new rules. Ultimately incentivizing all cryptocurrency transactions to flow through centralized exchanges or financial instruments like exchanged traded funds.

And that’s exactly what will happen.

The Bitcoin cypherpunk dream will die with launch of Bitcoin ETFs.

It won’t be instant. It will take time. But that’s o.k, because it will happen. And the big boys play are fine with playing games on a much longer time horizon.

2024 will be the year for creating the cryptocurrency surveillance machine.

In 2025 law breakers will be punished and “precedent” setting legal cases established.

And 2026 is when we see a dramatic influx to non-custodial cryptocurrency solutions.

Do I hope this prediction is wrong? Yes, of course.

But it’s foolish not to assume it’s not in the world of possibilities.

Why pay the cost of destruction, when control is just as effective?

The bankster way.

Conclusion

There is two sides two every token. A yin and a yang. Good and bad.

It’s important examine both sides of the token.

The Bitcoin ETF is exciting.

And perhaps even not as “gloom and doom” as I’ve painted it out to be, but it also has the potential to a be trojan horse - a problem that’s hard to see coming.

And if we honestly examine the situation, it’s filled with odd storylines and even more peculiar coincidences. Everything from the collapse of FTX and Sam Bankman-Fried’s relationship with the US government, too the recently enacted rules and regulations surrounding cryptocurrency transactions.

You can’t help but ask what’s really happening behind the scenes?

That's a question I've been asking myself a lot recently.

And if not what remains?

What new systems need to be designed and developed?

Where Are We Today?

I have mixed feeling about "Account Abstraction" i.e ERC-4337.

Ultimately I do believe it was a net positive for the ecosystem. Most notably it brought into focus the importance of smart accounts for the advancement of the Ethereum ecosystem.

But I believe there is still much left to explore and uncover in regards to the potential of smart accounts and what can considered as a Smart Wallet.

The major frontiers I see before us (Ethereum community) are as follows:

1. Delegated Authority

2. Smart Transactions

3. Transaction Firewalls

4. Account Recovery

5. Self-Sovereign Identity

Before diving into these frontiers I want to take a moment to contextualize where I think we stand today. As stated above, I have mixed feelings towards Account Abstraction, primarily because I don't think it was a "10x improvement" to the user experience it was herald as being.

ERC-4337 was an incremental, albeit important, steps towards enshrining smart accounts.

But it didn't drastically change or improve the smart contract wallet experience. Many features within ERC-4337 existed before in projects like Safe and Argent.

The most notable UX improvement arising from Account Abstraction was a Paymaster marketplace. And a clear commitment by the Ethereum community to prevent vendor lock-in for critical Web3 infrastructure i.e. wallets.

But Paymasters don't fundamentally change the smart account experience for non-trivial use cases. Sure it might improve the "embedded wallet" experience, where the concept of a wallet needs to be abstracted away from the incoming user, but when it comes to more serious use cases, especially in regards to Open Finance (a.k.a DeFi) it doesn't move the needle in any serious capacity.

And to illustrate this point, at the time of writing the “value” provided by these paymasters is still very limited.

While UserOperations might be significant (especially on Polygon which I am also inherently suspicious of) the gas paid by Paymasters is still very small when viewed across chains. In other words, there is relatively low-demand for using non-native assets (ETH and MATIC) to pay for gas costs of a transaction.

So if Account Abstraction isn't the 10x improvement we need... what is?

The Path Towards the Perfect Smart Wallet

Smart Accounts and in-turn Smart Wallets are the future.

The benefits are clear.

But why?

Programmability. And an optimized user experience.

Smart Accounts are the obvious path forward, because it becomes possible to build new "abstractions" on top of the core wallet experience. We (the developers) can encapsulate complex patterns that an average user is simply unable to craft and ultimately help unlock the full potential of decentralized systems without compromising on the core tenets of self-custody and self-sovereignty.

But what are the patterns worth capturing?

Delegated Authority:
Ability to authorize leaf accounts to act on behalf of a root account.

Smart Transactions:
Ability to craft rules, conditions and outcome based transactions.

Transaction Firewalls:
Ability to outsource transaction verification/execution to a third-party without losing custody or ownership of a smart account.

Account Recovery:
Ability to recover from a compromised account and/or lost private key.

Self-Sovereign Identity:
Ability to control and manage a digital identity without a centralized authority.

Why these frontiers?

These frontiers represent a “10x improvement” to the core wallet experience.

What’s Next in the Smart Wallet Space?

The might be a bold prediction and maybe even controversial but…

I am of the opinion that today’s standard wallet experience is fundamentally broken.

In so far that it’s the non-optimal route for onboarding millions of users onchain.

For a number of different reasons (security, user experience, discoverability, etc..) interacting primarily with blockchains using a browser based interface is a technological dead-end. Or at the very least a market segment that will be dominated by MetaMask and it’s UNIX like approach to modularity and upgradability via Snaps.

But simply put.

Smartphone wallet browsers and browser extension wallets are not the way forward for *truly* onboarding a billion users into the World of Web3.

I get it - right now you’re probably asking yourself “What’s my evidence that supports this assertion?” and to be completely fair that’s exactly what you should be asking.

And I’ll be honest with you.

I don’t have a mountain of evidence. Or anything I can point to specifically that leads me to this belief. But what I do have is the unshakable belief that we not have crossed the finish line yet.

There is more to uncover. More patterns to discover. More optimizations to make.

More experiences to make better.

And perhaps one of the best way to do this is to re-imagine “What is a Smart Wallet?”

The “iPhone Moment” for Web3

You’re probably familiar (or at-least aware) of the following quote from Steve Jobs.

“Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.”

It’s a great quote. It opens up your mind. Forces you think outside of the box.

Leading you down a path to ask questions that no one else is asking.

That mentality is missing from the Web3 ecosystem.

We want to give users an overwhelming amount of choices. We want them to navigate a confusing trail of terminology. We want them to play in a dark forest with dangerous predators.

Sure, it was the right place to start. But it’s the wrong place to end up in.

Conclusion

Today’s wallet and blockchain experience is broken if what we want is mass adoption.

ERC-4337 is not the “revolutionary” upgrade it was herald as being.

What we need is Smart Wallets with a verticalized user experience.

And that user experience will be underpinned by the following features:

1. Delegated Authority

2. Smart Transactions

3. Transaction Firewalls

4. Account Recovery

5. Self-Sovereign Identity

A collection of features that improve the core user experience, increase operational security, and introduces features (elegantly) that users didn’t even know they wanted or needed.

https://twitter.com/0xgaut/status/1742281435674009617

Here are some predictions on how this could directly affect popular DeFi protocols like Uniswap, PoolTogether, Aave, Curve, Compound, and other emerging technologies in the next 3-5 years.

1. Uniswap: Automated Liquidity Provisioning

Uniswap could integrate intents to allow users to set conditions for automated liquidity provisioning. For instance, users could set an intent like "Provide liquidity when the pool's volume is high and fees are above 0.3%." This would make liquidity provision more dynamic and responsive to market conditions.

2. PoolTogether: Smart Lottery Participation

PoolTogether could use intents to automate lottery participation based on user-defined criteria. Users could set intents like "Automatically enter the lottery if the prize pool exceeds $1 million," allowing them to capitalize on high-reward opportunities without constant monitoring.

3. Aave: Dynamic Lending and Borrowing

Aave could leverage intents to offer dynamic lending and borrowing rates. Users could set intents such as "Lend my assets when the interest rate is above 5%" or "Borrow only when rates are below 2%," making the lending and borrowing experience more flexible and profitable.

4. Curve: Intelligent Stablecoin Swaps

Curve specializes in stablecoin swaps with low slippage. Intents could automate this process by setting conditions like "Swap USDC for DAI when the price difference is greater than 0.1%," allowing users to take advantage of arbitrage opportunities automatically.

5. Compound: Automated Collateral Management

Compound could integrate intents to manage collateral ratios automatically. Users could set an intent like "Add more collateral if my loan-to-value ratio exceeds 70%," thus preventing liquidations during market volatility.

6. Layer 2 Solutions: Cost-Efficient Transactions

With the rise of Layer 2 solutions like Optimism and zk-Rollups, intents could be used to automatically move assets between Layer 1 and Layer 2 based on transaction costs. An intent like "Execute transactions on Layer 2 if gas fees on Layer 1 exceed $50" could save users a significant amount in fees.

7. NFT Marketplaces: Smart Bidding

NFT marketplaces could use intents to automate the bidding process. Users could set an intent like "Bid on NFT X if the price falls below $Y," allowing them to acquire valuable NFTs without having to monitor auctions constantly.

Conclusion

The integration of intents is poised to make DeFi more accessible, efficient, and personalized.

Over the next 3-5 years, we can expect these technologies to become deeply ingrained in popular DeFi protocols, offering a user experience that is not just revolutionary but also incredibly empowering.

The future of DeFi is bright, and it's being shaped by the innovative use of intents.

In the realm of Ethereum, the act of signing transactions is a cornerstone operation.

However, when it comes to multi-signature wallets like Gnosis Safe, the process becomes intricate and demands a deeper understanding of various signature types and methods.

This article aims to provide an introductory guide on how to sign a Gnosis Safe transaction using an Externally Owned Account (EOA).

We'll delve into hashing the transaction via the getTransactionHash method. Adhering to Safe signature schema be adding 4 to the v of an ECDSA signature, and using the WAGMI and viem signMessage hook with the raw parameter.

Gnosis Safe Signature Types

Gnosis Safe supports a variety of signature types, each with a constant length of 65 bytes. The last byte indicates the signature type. Here are some of the signature types Gnosis Safe supports:

1. ECDSA Signature: The most common type, consisting of r, s, and v values.

2. EIP-712 Signature: A structured data hashing and signing standard.

3. Contract Signature via EIP-1271: Allows smart contracts to verify signatures.

For more details, you can refer to the official documentation.

ECDSA Signatures

In ECDSA signatures, the r, s, and v values are essential for recovering the signer. The v value is particularly interesting because it MUST be increased by 4 to calculate the signature when using eth_sign.

The constant part of an ECDSA signature is {32-bytes r}{32-bytes s}{1-byte v}.

EIP-712 Signatures

EIP-712 is a standard for hashing and signing of typed structured data. This signature type is useful when you want to present the user with readable information about what they are signing.

Contract Signatures via EIP-1271

This signature type allows a smart contract to verify a signature. The signature verifier is the padded address of the contract that implements the EIP-1271 interface. The dynamic part consists of {32-bytes signature length}{bytes signature data}.

The getTransactionHashMethod

The getTransactionHashMethod is a function within the Gnosis Safe contract that returns the transaction hash to be signed by the owners. Here's the code snippet:

function getTransactionHash(
    address to,
    uint256 value,
    bytes calldata data,
    Enum.Operation operation,
    uint256 safeTxGas,
    uint256 baseGas,
    uint256 gasPrice,
    address gasToken,
    address refundReceiver,
    uint256 _nonce
) public view returns (bytes32) {
    return keccak256(encodeTransactionData(to, value, data, operation, safeTxGas, baseGas, gasPrice, gasToken, refundReceiver, _nonce));
}

Deep Dive: Adding 4 to the “v” Value

Why?

In Ethereum, the v value in an ECDSA signature is usually 27 or 28.

However, Gnosis Safe allows for more complex signature types, and to accommodate these, the v value MUST be increased by 4. When using eth_sign, as the default v values (27, 28) are adjusted, but we can’t submit that signature without first mutating it.

It’s mentioned in the Safe documentation, but with no links to any example.

https://docs.safe.global/safe-smart-account/signatures

And also in this StackExchange answer.

https://ethereum.stackexchange.com/questions/143583/gs026-i-sign-the-correct-safetxhash-but-checknsignatures-fails

Solidity Verification Logic

In the Safe contract, the signature verification logic accommodates this bit shift.

else if (v > 30) {
    // If v > 30 then default va (27,28) has been adjusted for eth_sign flow
    currentOwner = ecrecover(keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", dataHash)), v - 4, r, s);
}

https://github.com/safe-global/safe-contracts/blob/82dfcc8c0cf21c0f76db354d691d668093fe1618/contracts/Safe.sol#L335

Mutating the Signature via JS

The signHash method available in the safe-global/safe-contracts repo demonstrates how to increase the v value of an EOA signature by searching for 1b (27) and 1f (28) hexadecimal values and replacing them with 1f (31) and 20 (32).

export const signHash = async (signer: Signer, hash: string): Promise<SafeSignature> => {
    const typedDataHash = ethers.getBytes(hash);
    const signerAddress = await signer.getAddress();
    return {
        signer: signerAddress,
        data: (
            await signer.signMessage(typedDataHash))
            .replace(/1b$/, "1f").replace(/1c$/, "20"
        ),
    };
};

https://github.com/safe-global/safe-contracts/blob/82dfcc8c0cf21c0f76db354d691d668093fe1618/src/utils/execution.ts#L116

After the signatures have been mutated to adhere to the Safe signature schema they must be re-ordered from lowest to highest i.e. as if the addresses were uint256 values.

export const buildSignatureBytes = (signatures: SafeSignature[]): string => {
    const SIGNATURE_LENGTH_BYTES = 65;
    signatures.sort((left, right) => left.signer.toLowerCase().localeCompare(right.signer.toLowerCase()));

    let signatureBytes = "0x";
    let dynamicBytes = "";
    for (const sig of signatures) {
        if (sig.dynamic) {
            /* 
                A contract signature has a static part of 65 bytes and the dynamic part that needs to be appended 
                at the end of signature bytes.
                The signature format is
                Signature type == 0
                Constant part: 65 bytes
                {32-bytes signature verifier}{32-bytes dynamic data position}{1-byte signature type}
                Dynamic part (solidity bytes): 32 bytes + signature data length
                {32-bytes signature length}{bytes signature data}
            */
            const dynamicPartPosition = (signatures.length * SIGNATURE_LENGTH_BYTES + dynamicBytes.length / 2)
                .toString(16)
                .padStart(64, "0");
            const dynamicPartLength = (sig.data.slice(2).length / 2).toString(16).padStart(64, "0");
            const staticSignature = `${sig.signer.slice(2).padStart(64, "0")}${dynamicPartPosition}00`;
            const dynamicPartWithLength = `${dynamicPartLength}${sig.data.slice(2)}`;

            signatureBytes += staticSignature;
            dynamicBytes += dynamicPartWithLength;
        } else {
            signatureBytes += sig.data.slice(2);
        }
    }

    return signatureBytes + dynamicBytes;
};

https://github.com/safe-global/safe-contracts/blob/82dfcc8c0cf21c0f76db354d691d668093fe1618/src/utils/execution.ts#L143

Why do the signatures have to be ordered?

That’s a great question!

Because in the checkNSignatures method of a SafeProxy requires it. And this is required to prevent the same owner from passing multiple signatures.

require(currentOwner > lastOwner && owners[currentOwner] != address(0) && currentOwner != SENTINEL_OWNERS, "GS026");
            lastOwner = currentOwner;

The currentOwner > lastOwner comparator means the signatures have to be in sequential order because the recovered address is compared to the previously verified signature as if it were a uint256.

https://github.com/safe-global/safe-contracts/blob/82dfcc8c0cf21c0f76db354d691d668093fe1618/contracts/Safe.sol#L344

Using viem's signMessage Hook

The viem signMessage hook calculates an Ethereum-specific signature in EIP-191 format. It takes an account and a message as parameters and returns the signed message. The message can be passed as a string or with a raw attribute for data representation.

Example Usage with raw Parameter

const signature = await walletClient.signMessage({
  account,
  message: { raw: '0x68656c6c6f20776f726c64' },
});

A full example of signing a hex string and increasing the v value so it adheres to the Safe signature schema.

import { useWalletClient } from "wagmi";

const { data: walletClient } = useWalletClient();

const [signature, setSignature] = React.useState<{
    signed: boolean;
    signature: `0x${string}`;
}>({
    signed: false,
    signature: "0x",
});

const handleSignTransaction = async () => {
    const signMessageData = await walletClient?.signMessage?.({
        message: {
            raw: transactionHash.data as `0x${string}`,
        },
    });
    if (!signMessageData) return;
    const bitShiftedSig = signMessageData
        .replace(/1b$/, "1f")
        .replace(/1c$/, "20");
    setSignature({
        signed: true,
        signature: bitShiftedSig as `0x${string}`,
    });
};

Executing the Signed Gnosis Safe Transaction

After you've successfully signed a Gnosis Safe transaction, the next crucial step is to execute it. This involves sending the signed transaction to the Gnosis Safe contract for execution. Below, we'll explore how to do this using React hooks and Ethereum smart contract interactions.

The following snippets assumed you have generated React hooks using the WAGMI CLI and references to the Safe contracts.

Something like this:

import { defineConfig } from "@wagmi/cli";
import { foundry, react } from "@wagmi/cli/plugins";

export default defineConfig({
  out: "src/blockchain.ts",
  plugins: [
    react(),
    foundry({
      project: "../contracts/safe-contracts",
      include: [
        "Safe.json",
        "SafeProxy.json",
        "SafeProxyFactory.json",
        "MultiSend.json",
        "WalletFactory.json",
      ],
    }),
  ],
});

Preparing the Transaction

Before executing the transaction, you need to prepare it by gathering all the necessary parameters. Here's how you can do it:

• Fetch the Safe Nonce: The nonce is a counter that ensures each transaction is unique. You can use the useSafeNonce hook to get the current nonce for the Safe.

const nonce = useSafeNonce({
    address: safeAddress,
    enabled: true,
});

Calculate the Transaction Hash: Use the useSafeGetTransactionHash hook to calculate the transaction hash based on the parameters.

const transactionHash = useSafeGetTransactionHash({
    address: safeAddress,
    args: [
        safeAddress, // to
        BigInt(0), // value
        '0x', // data
        0, // operation
        BigInt(0), // safeTxGas
        BigInt(0), // baseGas
        BigInt(0), // gasPrice
        constants.AddressZero, // gasToken
        constants.AddressZero, // refundReceiver
        nonce.data as bigint, // nonce
    ],
});

Preparing the Execution Configuration

Once you have the transaction hash and the signature, you can prepare the execution configuration using the usePrepareSafeExecTransaction hook.

const { config } = usePrepareSafeExecTransaction({
    address: safeAddress,
    args: [
        safeAddress, // to
        BigInt(0), // value
        '0x', // data
        0, // operation
        BigInt(0), // safeTxGas
        BigInt(0), // baseGas
        BigInt(0), // gasPrice
        constants.AddressZero, // gasToken
        constants.AddressZero, // refundReceiver
        signature.signature, // signatures
    ],
    enabled: signature.signed,
});

Executing the Transaction

Finally, you can execute the transaction using the write method from the useContractWrite hook. This will send the transaction to the Ethereum network for execution.

const _safe = useContractWrite(config);

const handleSubmitTransaction = () => {
    _safe?.write?.();
};

To execute the transaction, simply call the handleSubmitTransaction function. This will trigger the write method, sending the transaction to the Gnosis Safe contract for execution.

Conclusion

Signing a Gnosis Safe transaction with an EOA involves a series of steps that require a deep understanding of Ethereum signatures and the Gnosis Safe contract.

This guide has aimed to provide a comprehensive understanding of how to sign a transaction, from hashing it using the getTransactionHashMethod to signing it using the viem signMessage hook and finally submitting it to the Gnosis Safe contract.

By following these steps, developers can ensure that their transactions are not only secure but also conform to the standards set by Gnosis Safe and the Ethereum ecosystem at large.

Happy coding!

Why are we switching from integrations to templates?

Because TurboETH now has over 10+ Web3 integrations: Sign-In With Ethereum, PoolTogether, Lit Protocol, Arweave, Disco, Connext, Aave, Livepeer, Gelato and more!

Want to help us bring TurboETH to the next level?

Apply to become a core contributor and get paid a monthly stipend to develop templates.

https://mirror.xyz/kames.eth/tin2FQN9OoI5mQ4LsCyPVmZpGVF8GMQEySsGtOqyjVY

Have you signed up to become a TurboETH Core Contributor?

Excellent! Below are a few template TurboETH template ideas we have.

TurboETH Template Ideas

🌿 Emergent

A fully onchain dynamic SVG digital collectible that updates when zero-knowledge proofs are submitted via the Axiom protocol

For example if a user makes 20+ swaps on Uniswap or the account is older than 1 year, they can submit a zero-knowledge proof that will automatically update the digital collectible design.

💬 Chatter

A peer-to-peer messaging application that uses XMTP for communication.

Wallets can send each other transaction recommendations. For example you can send friend a transaction recommendation to mint a limited edition digital collectible. Or remind them to pay for their part of a dinner bill with a request to send USDC to your account.

The XMTP protocol allows custom message types to be created, which means other UIs can adopt new types of message formats. Stretch goal is sending verifiable credentials using Disco and/or Veramo.

🏦 Sayvor

A decentralized finance template that encourages saving using the PoolTogether V5 protocol and contributing to public goods when large prizes are won.

🗳️ Ballot

A decentralized voting system where each vote is a transaction on the blockchain.

The system would use zero-knowledge proofs via the Semaphore protocol to maintain voter anonymity while ensuring that each wallet can only vote once.

The results are transparent and verifiable by anyone.

🎥 Streamify

LivePeerChat aims to revolutionize the world of decentralized streaming by integrating Livepeer's video streaming capabilities with Orbis' real-time chat functionality.

As a stretch goal the template could also incorporate an ERC20-based tipping mechanism, complete with a Twitch-like leaderboard to encourage viewer engagement and reward top contributors.

Integrate Orbis' chat API to provide a seamless, real-time chat experience alongside the video stream. The chat will support text, emojis, and even custom message types.

Apply to Become a TurboETH Template Contributor

Interested in helping develop one of these template ideas?!

Join us in the TurboETH Discord 💬

https://discord.gg/MKYh9pg8Yq

Open source software has played a pivotal role in shaping the landscape of decentralized finance, allowing for the creation of groundbreaking applications and tools.

If you're a Web3 developer looking to make a meaningful impact in this space while enjoying the freedom to explore your creative potential, we have an exciting opportunity for you.

https://forms.gle/uDPpTbz54i9Yj7Az7

TurboETH Core Contributor

TurboETH is not just another Web3 application starter template; it's a build system designed to empower developers to create powerful and innovative templates in the world of blockchain technology.

Developed with the aim of simplifying the Web3 development process, TurboETH provides the tools, resources, and community support necessary to kickstart your journey in the world of decentralized applications.

The Opportunity: Joining Our Team of Web3 Developers

With a total of 14,000 OP tokens at our disposal, we are thrilled to announce that we are actively looking to hire 2-4 Web3 developers to be a part of our dynamic team.

This is a unique opportunity to work on a groundbreaking project that offers you the freedom to develop templates that genuinely interest you.

At our core, we believe that fostering creativity and innovation is the key to driving progress in the Web3 space.

Why TurboETH?

• Empowerment: TurboETH empowers developers with a user-friendly and feature-rich platform that simplifies the creation of Web3 applications. You'll have access to a wide range of resources and tools to supercharge your development process.

• Community: Join a passionate and diverse community of like-minded individuals who share your passion for Web3 development. Collaborate, share knowledge, and grow together as you contribute to the TurboETH ecosystem.

• Freedom to Innovate: Unlike traditional development roles, working with TurboETH means you have the freedom to shape the future of Web3 templates. You're not just a developer; you're a creator who can turn your visionary ideas into reality.

What We're Looking For:

• Web3 Enthusiasts: If you're passionate about the potential of blockchain technology and the Web3 ecosystem, this opportunity is tailor-made for you.

• Development Skills: Proficiency in Web3 development technologies, including Solidity, Ethereum, and smart contract development, is a must.

• Creativity: We value creative thinking and innovative problem-solving. Your ability to think outside the box is what sets you apart.

• Collaborative Spirit: Teamwork is at the heart of what we do. We're looking for developers who thrive in a collaborative environment and can work effectively with a diverse group of individuals.

Your Impact:

As a Web3 developer with TurboETH, you'll have the chance to:

1. Shape the Future: You will be at the forefront of the Web3 revolution, contributing to the development of templates that have the potential to transform the crypto landscape.

2. Learn and Grow: The dynamic nature of the blockchain space means that there is always something new to learn. Your role with TurboETH will provide continuous opportunities for personal and professional growth.

3. Inspire Others: Your work will serve as an inspiration to the broader Web3 community. Your innovative templates will help others visualize the endless possibilities of blockchain technology.

Join Us in Shaping the Future of Web3 Development

If you're excited about the limitless possibilities of Web3 technology and want to make a tangible impact, TurboETH is the place for you. Join our team of passionate Web3 developers and be part of a project that's set to change the way we build decentralized applications.

Apply today and start your journey towards a future where Web3 development knows no bounds. Together, we'll unlock the full potential of blockchain technology and shape the future of the crypto space. Your creative freedom awaits!

Don't miss this unique opportunity to be part of something extraordinary.

Join us at TurboETH and let's pioneer the future of Web3 development together.

Apply using the Google Form below 👇

https://forms.gle/ZNTaB6kLYfmgoCpU7

Also be sure to join us on our Discord 💬

https://discord.gg/MKYh9pg8Yq

https://twitter.com/optimismFND/status/1641462688512618498

TL;DR:

Thank you to Optimism RGF badge holders for supporting the Web3 ecosystem.

The OP tokens will be used for funding TurboETH templates/integrations and an Open Source Web3 Design System. These initiatives aim to improve overall user experience and expand the Web3 ecosystem -- building a strong community of developers, designers and optimizoors focused on building next generation Web3 applications.

What’s Planned

As a recipient of the retroactive public goods funding, I have been given the opportunity to put these funds towards initiatives that I believe will help push Web3 forward. Here are the three things that I want to do with the OP tokens:

1. Bounties for new TurboETH templates and integrations: TurboETH is an emerging Web3 app framework that allows developers to quickly build and deploy Web3 applications. To help accelerate the adoption of TurboETH, I want to offer bounties for new templates and integrations. This will encourage developers to build new applications using TurboETH, which will help to expand the Web3 ecosystem and make it more accessible to a wider range of users.

2. Bounties for a Web3 design system: Web3 is still in its early stages, and there is a lot of room for improvement in terms of user experience and design. To help tackle this challenge, I want to use a portion of the funds to create bounties for a Web3 design system. This will incentivize designers to create designs that are tailored to the unique requirements of Web3, such as support for multiple chains, seamless integration with wallets and other Web3 tools, and user-friendly interfaces for complex transactions.

Roadmap

Looking forward, I am excited to share a roadmap for how I plan to use the OP tokens and achieve the goals outlined above:

• In the next few weeks, I will also be reaching out to developers to gauge interest in the TurboETH bounty program. I will be working with the community to establish the types of templates and integrations that would be most valuable, as well as setting up the requirements and timeline for submission.

• At the same time, I will be reaching out to designers to establish the details of the Web3 design system bounty program. This will include outlining the requirements and criteria for submission, as well as setting up a timeline for the submission and review process.

Call to Action

If you're a Web3 designer or developer, I invite you to get involved in the bounty programs for the TurboETH templates/integrations and an Open Source Web3 Design System.

Your contributions can make a real impact in improving user experience and expanding the Web3 ecosystem.

Let's make an optimistic future together!

🔴 ⚡️

Properly built software opens doors for people. For me it meant having an opportunity to teach myself software development. I’ve always found the best way to learn is by seeing and doing. Early content management systems like Joomla and Wordpress gave me an opportunity to create, tinker and explore. A path to competency.

I owe my career to Open Source Software.

Web3 needs its “Wordpress” moment.

We need an Open Source Web3 Build System. Decentralized protocols and distributed networks give us a moment… A moment to take a step back and ask ourselves “What’s possible?” and not simply “What KPI?”

Retroactive Public Goods Funding

⚡️TurboETH was nominated for Optimism Retro PGF V2.

https://gov.optimism.io/t/tooling-utilities-nominations-for-rpgf2/4639/127?u=jonas

Thank you @diligitSP for the nomination 🔴 it was a pleasant surprise!

https://app.optimism.io/retropgf-discovery/0x761d584f1C2d43cBc3F42ECd739701a36dFFAa31

I started TurboETH because I want a build system that brings together the complete Web3 technology stack. Everything. Cryptocurrency, identity, storage, access controls, coordination, and more.

I want new developers to learn, contribute and experiment.

I want experienced developers to plan, engineer and stabilize.

A Web3 Build System that fully utilizes decentralized and distributed technology in the most effective and efficient way possible. An elegant, composable and secure system for creating peer-to-peer networks. A first principles approach to answering the question “What’s possible?” and how can we do it better?

Right now TurboETH is a Web3 App Template built using Next.js, RainbowKit, SIWE, Disco, and Etherscan. It needs to evolve. To be better. To be supercharged.

❖ Open Source Web3 Build System

In the future TurboETH will be an ❖ Open Source Web3 Build System that supercharges developers with decentralized and distributed primitives: blockchains, authentication, identity, storage, and access controls.

The Web3 ecosystem is evolving. Becoming more complex in nature. As an ecosystem we’re moving beyond only interfaces for smart contracts. Applications can now deeply integrate decentralized and distributed protocols and services into a modern application stack.

• access controls - privacy

• authentication - network

• blockchains - value

• identity - context

• storage - communication

Vote for Open Source

To build Web3 applications that grow we need new standards and schemas. An Open Source Web3 Build System designed to maximize collaboration and market efficiency.

Growth happens when people can learn, share and earn. We don’t have to re-invent how the Internet works. We only have to make it better.

https://www.turboeth.xyz/

What we have today will not scale to a future with millions of users.

It’s lacks the elegance to construct complex financial instruments.

Let me explain…

Today we use a Beacon and Receiver model - Chain A sends a message to Chain B. Creating an explicit link between chains. But this is a bridge to nowhere. It lacks the properties required for complex expression of protocols. It works today. But what we have today is primitive. It’s a stone wheel, but what we need is a rocketship.

In the future, when we have Open Finance hyperstructures, it will require relaying messages between 100’s and possibly 1,000’ of rollups and modular execution environments. The Beacon and Receiver model fails us in this Superchain world.

It lacks the elegance required for scale.

Lessons from the Past

I’ve been building applications for awhile now: 15+ years. Witnessing first-hand the evolution the Internet from the perspective of a developer and systems engineer.

One of the the major evolutions was when frontend applications transitioned from two-way data binding to uni-directional state management. Before React became the primary frontend framework we had frameworks like Angular, Ember, Backbone and others.

Why did this shift happen though?

Because a few people noticed two-way data binding was a limiting paradigm. It was difficult to scale. Introduced hard to catch bugs. And lacked elegance. Developers at Facebook, a company focused on Web2 scale, had to go back to the drawing board.

What was once deemed “crazy” is now the dominant paradigm in frontend applications.

We need to prepare for the future

Blockchains are much less forgiving than Frontends. The development lifecycle is months and years, compared to days and weeks. An incorrect assumption or single mistake has lasting impact. The margin for error is small.

We don’t have time for mistakes.

We need to engineer elegant systems from day one. Web3 Experience Architects need to start thinking about protocol lifecycles in terms of years and centuries.

Blockchains as a Brain

Right now the brain is fairly limited. We only have a couple of neurons.

• Ethereum L1

• Optimism L2

• Arbitrum L2

• Base (Soon) L2

• etc…

Bridging works because the complexity for cross-chain communication is still limited.

Protocols have rudimentary cross-chain communications requirements.

But that is going to change.

We are going to have 100’s and possibly 1,000 of L2 and L3 environments. Open Finance protocols will scale to millions of users. But this future world requires elegant data management systems to enable complex protocol construction.

https://mirror.xyz/kames.eth/8SqDiMe3u71nLF3jv7IsTplJOYU8L4IqYFKDZdfUvsE

Cross-chain data binding using the Beacon and Receiver model doesn’t get us there.

Right now DeFi protocols are fairly simple. That will not always be the case.

• IF we have hundreds of L1, L2 and L3 environments this will be due to demand from millions of users.

• IF we have millions of user it means we 10X’ed the traditional finance system UX.

• IF we 10X TradFi user experience it means we have complex financial instruments.

• IF we have complex financial instruments, with millions of users, and hundreds of blockchain execution environments, it means we need to express complex cross-chain protocol interdependencies.

• IF we have complex cross-chain protocol interdependencies we need an elegant paradigm to connect protocols that may or may not know about each other.

In the future, Open Finance protocols will have complex inputs. The inputs will be a combination of storage proofs and zk-SNARKS. The same technologies that are planned in Ethereum protocol roadmap.

Whether it’s synthetic derivatives, futures exchanges or virtualized fiat (money by decree of network) we need to scale one-to-many and many-to-one smart contract protocol communication systems.

The Bridge and Relay model fails us.

We can’t require Protocol Alpha on Chain Alice to initialize a relay request to Protocol Beta on Chain Bob, because it may not even know Protocol Beta exists. We need communication to happen using implicit relationships - observability.

Instead of requiring Chain Alice to broadcast a message, we need Chain Bob to observe state changes on Chain A and Protocol Beta react without requiring Chain Alice know anything about Chain Bob.

Let’s start with a basic example. A cross-chain automated market maker.

Why would we want to build a cross-chain automated market maker?

As I discussed in my thought experiment “Ethereum in 10 Years: How network states can level up fiat - money by decree.” two money principles dominate our financial systems.

Hard/Now/Real Money - money to represent the value we have amassed today.

Soft/Future/Synthetic Money - money to represent the value we’re creating tomorrow.

Soft money at its best is futures exchange and at its worst is credit default swaps and collateralized debt obligations that underpinned the 2008 financial crisis.

Arguably these financial instruments allow people, institutions and states to create an efficient marketplace of ideas, resources and investments i.e. capitalism. It’s how we’ve went from trading seashells on the sea shore to quantitive trading at the speed of light.

I love decentralized and distributed systems. But I love capitalism more. It can be ruthlessly efficient. It can drive people to action. It can move humanity forward.

But capitalism has flaws. Flaws from centralization. And not simply “fvck the banks” type of centralization. But flaws that arise from centralization in all systems.

Inability to quickly evolve and adapt.

Distributed and decentralized systems have an opportunity to make capitalism better.

Evolving today’s complex finance instruments underpinning our global markets.

Cross-chain AMMs will replace futures exchanges, collateralized debit obligations swapping, synthetic derivatives and more. But for these complex financial instruments to work at scale, we need elegant blockchain data management systems.

We need implicit observability. Not explicit data binding.

If you believe in a Superchain future you also believe in cross-chain data observability.

https://optimism.mirror.xyz/2jk3D1Y8-hid8YOCUUa6yXmsyzNCYYyFJP0Nhaey9x0

It’s the only way to scale Open Finance hyperstructures to millions of users.

Connecting Neurons using Succinct Messages

Enough pontificating on the future of blockchains. Let’s get technical.

A One-to-Many and Many-to-One smart contract protocol data management system will happen using storage proofs and succinct messaging via zk-SNARKS.

Storage proofs, for those unfamiliar, is a method for validating state on the blockchain.

https://www.laconic.com/blog/what-is-a-proof

When storage proofs are used in combination with zk-SNARKS magic can happen.

For example the Celo blockchain has Plumo. Allowing users to efficiently validate the state of the blockchain without requiring a full node. Using only a smartphone it’s possible to verify the state of the blockchain without a centralized authority.

It’s an incredible achievement! Even though it was incredibly early.

https://docs.celo.org/protocol/plumo

Plumo is a zk-SNARK based system that allows mobile and resource constrained nodes on the Celo network to sync to the Celo blockchain faster and with less data. It accomplishes this by using zero-knowledge proofs, which allow the quick verification of the chain syncing computation without having to run it locally.

Storage proofs and zk-SNARKS aren’t limited to off-chain light clients.

They can power a cross-chain Proof of Consensus using on-chain light clients.

https://blog.succinct.xyz/post/2022/09/20/proof-of-consensus/

Once an on-chain light client can keep track of block headers of another chain, anyone can supply state proofs to prove any information (balances, storage, transactions, events) about the source chain in the context of the target chain. With this, building a cross-chain application, such as a token bridge becomes simple.

[Using] zero-knowledge proofs to generate a validity proof of the state of a chain according to its consensus protocol. This validity proof can be used to power a [on-chain] gas-efficient light client, which facilitates trust-minimized interoperability.

Succinct has prototyped a Proof of Consensus protocol. Demonstrating how it’s possible to use zk-SNARKS and state proofs for efficient cross-chain communication.

https://demo.succinct.xyz/

Chain Reaction Protocol

We can take this concept one step further. Remove Bridges/Beacons entirely.

Everything is a beacon signal: balances, storage, transactions, events, etc…

Storage proofs can be generated from any data object.

Why is this important?

To match the sophistication and scale of the traditional finance system we need to design protocols with complex abstractions. Complexity requires expressiveness. Expressive blockchain protocols ultimately require access to all the state and across all time ranges and execution environments - whether broadcast from a beacon or not.

No small achievement.

But it is what’s required if we want a global Open Finance system. A decentralized finance system where can start to view blockchains as neurons in a brain and less as islands connected using rickety bridges.

Where centralized capitalism fails is where decentralized capitalism excels.

Wisdom of the crowds and hyper efficient markets are the big unlock.

It’s the next evolution of finance.

Conclusion

Explicit data binding between chains is an important but simple construct.

Bridges and Beacons serve an important role today. But alone they’re not capable of scaling to meet the demands of Open Finance hyperstructures.

We will always require a Beacon and Receiver model. However future bridges will use a Proof of Consensus protocol… and not multi-sigs using 5/7 signer enforcement 🙈

Implicit Data Binding - Global Observability

Implicit data binding will be a new frontier in a world with hundreds of L2 and millions of users. It’s going to be difficult. We’ll need to rethink best practices and patterns.

If we actually want to build a better future, we need a cross-chain data management system capable of meeting global demands of Open Finance; security and scale.

A Chain Reaction protocol.

⚇

• Where will Web3 products provide 10x value?

• How do we scale to millions of users and hundreds of thousands of developers?

• What will be the protocols, systems and networks to ignite massive adoption of decentralized and distributed technologies?

We have several interesting verticals: DeFi, DAO, and NFT.

But, all lacking the "it" factor for catalyzing hyper-growth. They’re interesting, but standalone they don't speak to a mainstream audience.

When I take a step back and ask myself what is the key to unlock massive growth…

I always come back to Identity.

Identity is expansive. Prime for disruption. And unlocks Web3’s full potential.

It touches almost every aspect of our lives. Whether it's logging into an application, getting invited to a party or accessing the traditional finance system. Identity is the key we use to unlock the world around us.

Identity, authentication and access controls are the bedrock of digital systems.

You don't build complex systems without these primitives being rock solid.

Web3 Identity currently lacks elegance.

Unlocking Web3’s Full Potential

DeFi, DAOs and NFTs are still experimental.

Highly speculative, difficult to use and with minimal utility, these experiments don’t offer us a path forward to millions of users in Web3. It isn’t the right infrastructure for hundreds of thousands of developers.

If we want to cross the Web3 chasm we have to do so methodically.

We have to work from first principles. And ask ourselves…

How do we unlock Web3’s full potential?

A Web3 of Trust

Building a social graph on a blockchain is a bad idea. It lacks elegance.

What we need is off-chain social networks. Identity, authentication and access controls primitives that can give life to more complex Web3 applications. Applications that integrate DeFi, NFT and DAOs into a more organic experience.

Without the ability to craft more complex decentralized and distributed applications we will continue to build products, marketplaces and ecosystems that can’t meet the demands and needs of a global Open Finance system.

We need to combine on-chain and off-chain cryptographic primitives/substrates.

We need to build products that offer a 10X user experience.

We need a Web3 of Trust.

Scaling DeFi to millions of users means simple and secure. The amount of protocols and products that can full this niche is limited. It’s a winner take all game, so that means this vertical won’t scale to hundreds of thousands of developers.

Scaling NFTs to millions of users means building products that enhance a community experience. What you collect is important. But what’s more important is connecting with others who share your values.

Scaling DAOs to millions of users means building products that provide insights into complex decisions and problems. Blockchains are where decisions are finalized, but not where information is discovered.

No matter how many times I go back to the drawing board I always arrive at the same conclusion.

Identity is the massive unlock for onboarding millions of users into Web3.

Identity helps users pass through essential Web3 commitment thresholds: creating a wallet, managing private keys, distributed access controls, etc… all without requiring a blockchain transaction.

Identity is an expansive digital frontier - one large enough for hundreds of thousands of developers to build new and interesting products in.

Identity is the catalyst for hyper-growth of Web3.

Web3 is more than blockchains and cryptocurrency.

Web3 is a re-imagining of what’s possible. A re-thinking of our relationship with cryptography. A chance to build systems, networks and products that weren’t possible before.

1. It's mathematically infeasible to scale Ethereum to accommodate millions of users within the next couple of years. Despite the introduction of rollups, the Ethereum base layer in its current form lacks the capacity for hyper-growth. This is an unfortunate but unavoidable truth.

2. Bridges possess a major design flaw, namely explicit Beacon and Receiver bindings. To establish a scalable blockchain network, that can handle hundreds of interconnected L1/L2 execution environments and support an Open Finance network designed for millions of users, the only viable option is to employ cross-chain storage proofs using SNARKs. Utilizing SNARKs, relayers can quickly and securely verify transactions without the need for explicit interchain bindings, resulting in a more efficient and reliable network. But we’re not there yet.

3. Despite initial enthusiasm for decentralized finance (DeFi), in its current form, has failed to live up to its promise of banking the unbanked. Instead, we are building complex financial instruments, but for whom? The proliferation of non-sensical governance tokens across many DeFi/CeFi protocols has created additional challenges for the ecosystem. Failure to work from first principles has hampered progress and a fundamental shift is needed if DeFi is to realize its potential as a tool for financial inclusion.

To move the needle forward we need to go back to the drawing boards.

We need asynchronous protocol construction, distributed circuit-breaker systems, and virtualized fiat (money by decree of network) if we expect to match the sophistication and scale of the current, albeit failing, financial system.

It can be done. But it will take time.

What we need right now is to evolve the culture of the Ethereum network state. We need to build networks, connect, and reshape our relationship with decentralized and distributed technology.

Blockchains cannot currently scale to millions of users, but decentralized identity can.

On the horizon is a revolution in identity and social networks.

The advertising models of yesteryear are failing, and big tech is scrambling. The writing is on the wall, as seen with Twitter, Facebook, Google, and Microsoft. Subscription fees for verified digital identities. Artificial intelligence making search an obsolete mode of interacting with the Internet. The walled gardens of the Web2 era are becoming relics, and the walls are starting to crumble.

We have an opportunity to reimagine and rebuild the internet.

How will technology serve us for generations to come? The world is changing, and "decentralization" is no longer just a buzzword. It is a necessity.

To achieve a decentralized future, we must focus on building strong communities and networks built on trust, transparency, and collaboration. We need to create an ecosystem that welcomes new users and developers, encourages experimentation and innovation, and creates the foundation for an Open Finance revolution.

Decentralized identity is a key component of this future.

It’s how we scale all of Web3 - onboarding millions users and hundreds of thousands of developers into the decentralized and distributed future.

◎

Instead of utilizing banks, most individuals interact with Open Financial protocols for their everyday needs. Fiat, money by decree, is still around but the landscape is shifting.

“Fiat money is a type of currency that is not backed by a commodity, such as gold or silver. It is typically designated by the issuing government to be legal tender.”

https://en.wikipedia.org/wiki/Fiat_money

Optimism's rollups are generally used for Open Finance hyperstructures with hard money principles i.e. near-instant debt settlement, collateralized speculation and other financial instruments that use real-world indicators for value accrual. Inherit to hard money is small discrete time ranges (1 - 15 seconds) and minimal "virtualization" of speculation in the form of debt. Hard money rollups prioritize tighter feedback loops and accurately representing the state of the world as it today.

Fuel's modular execution environments are used to abstract/virtualize Open Finance protocols with soft money principles i.e. localized fiat currencies, fractional reserve credit lending and other financial instruments that use abstract indicators for long-term value generation. Inherit to soft money is unbounded discrete time ranges (15 seconds to 30+ days) and abstract virtualization of value in the form of speculation. Soft money execution environments prioritize longer feedback loops and coordination games that speculate on the state of the world as it should be tomorrow.

Enter the Thought Experiment

For just a moment I'm going to play fast and loose with definitions of "hard" and "soft" money since it's my thought experiment and you're invited to come along for the ride :)

Hard money can be defined as real financial indicators for the state of the world as it is today.

Soft money can be defined as abstract financial instruments to bet on (and arrive at) a desired future.

Hard money enables value accrual in real-time and soft money enables speculating on value creation in the future. Put another way, hard money is the physical gold humanity has been mining for the last 2,000+ years and soft money is the futures market started in the 1930's to insulate farmers from risks in emerging global markets.

https://www.cam.ac.uk/research/features/agricultural-markets-and-the-great-depression-lessons-from-the-past

“An agriculture commodity future is a contract, traded on an organized market called an exchange, whereby a specific quantity of a certain subset of grades and quality of a natural raw product (such as wheat or cotton) can be contracted for at a set price in advance of its delivery.”

One might even consider the transition for the gold standard to the fiat standard, in the 1970s, as a bridge between modern hard money and soft money principles. Even Ethereum's recent upgrade from proof-of-work to proof-of-stake shines light on the idea of hard and soft money principles playing out exclusively in virtual environments.

And begs the question... Would it have been possible for Ethereum to start out as a proof-of-stake network and forgoing its proof-of-work phase? I would argue no... The bridge from physical to digital (literally buying GPUs and working to secure a network) acted as an essential "hard" money financial instrument required to bootstrap the Ethereum network at that time.

As the saying goes... Timing is everything.

Whether you agree with the transition from the gold to the fiat standard, it can be argued it was a required abstraction for moving into the Digital Era of value creation. Gold as a hard money standard had reached its maturation and we collectively needed a new financial instrument to "upgrade" the value humanity had amassed/accrued up until that point in time.

Now, let's move onto doing some future world building.

It's 10 years in the future and a network state called "Nexus" exists. Members of this network state have high-conviction decentralized staking of ETH is a positive sum game: 1 + 1 = 3.

More ETH staked means more higher-order secondary benefits.

To virtualize the higher-order value creation, a rollup is launched and the native token is an abstract representation of all ETH staked in decentralized protocols, like RocketPool and Lido. Let's call this new asset nexETH. The aptly named "Nexus Network State" uses succinct storage proofs to efficiently transmute large nexETH "state" snapshots into consumable input for a Open Finance "fiat" protocol that can create money "by order of decree".

Example virtual DeFi protocols today are virtual automated market makers.

https://coinmarketcap.com/alexandria/glossary/virtual-automated-market-makers-vamms

Modular math but for abstract Open Finance protocols instead of SNARK construction for low-level blockchain protocols.

https://vitalik.ca/general/2021/01/26/snarks.html

Members of the "Nexus Network State" bootstrapped a community with hard money principles, but are also free to accrue value on their collective "intuition" by using soft money principles to create "speculative" fiat money that can be used for day-to-day economic operations of the Nexus Network State.

Hard money hyperstructures and soft money protocols need to interoperate.

And thus we need to start answering the questions...

• What are the environmental conditions required for bootstrapping virtual networks?

• What external pressures are required for the network to evolve at the right time?

• What are the signals for when a network is reaching a local maxima and either needs to stabilize or enter into a higher plane of abstraction for sustained growth?

Ethereum could stabilize in its current form; aligned mostly with hard money principles.

Or we can continue to ask the questions...

"What's possible?" and "Is it the right time to introduce a catalyst for an Ethereum network state evolution?"

Can we abstract the hard money principled DeFi protocols we've built so far, into more complex, higher-order primitives, that enable us to scale global Open Finance hyperstructures?

My intuition tells me yes, and it's the future I'm betting on.

In short- Leveling up fiat, money by decree, with emerging blockchain technologies and unlocking a new form of human coordination by leveraging both hard and soft money principles to capture the value accrued today and continue to speculate on the value created tomorrow.

https://twitter.com/KamesGeraghty

TurboETH is a Web3 application build system designed to supercharge developers.

Go from idea to production in minutes.

www.turboeth.xyz

How It Works

Get started at deploy.turboeth.xyz with an instant deploy to Vercel and Github.

Projects are initialized using the TurboETH web3-application template.

Application:

• https://github.com/turbo-eth/template-web3-app

Periphery:

• https://github.com/turbo-eth/core-wagmi

• https://github.com/turbo-eth/erc20-wagmi

• https://github.com/turbo-eth/erc721-wagmi

Developer:

• https://github.com/turbo-eth/turbo

The TurboETH application build system is designed for rapid development. 

https://github.com/turbo-eth

Seamlessly blend today’s leading Internet technologies into a beautiful production ready application that uses a combination of Web2 and Web3 technologies. 

Focus on what makes great applications - an unmatched user experience.

What is a supercharged Web3 build system exactly? Great question!

An application build system that integrates cutting edge frontend, backend and cryptography technologies integrated into a single development framework.

It’s opinionated, but also extreme flexibility.

Hybrid Web2/Web3 Applications

TurboETH blends traditional Web3 application technologies with cutting-edge Web3 cryptographic primitives. 

Why? So developers can start building next-generation applications today.

Web3 Frameworks

• RainbowKit - Wallet connection manager

• Sign-In With Ethereum - Account authentication

• Etherscan - Blockchain Metadata

Web2 Frameworks

• Vercel - App Infrastructure

• Prisma - Database ORM

Developer Experience

• TypeScript – Static type checker for end-to-end typesafety

• Prettier – Opinionated code formatter for consistent code style

• ESLint – Pluggable linter for Next.js and TypeScript

User Interface

• Tailwind CSS – Utility-first CSS framework for rapid UI development

• Radix – Primitives like modal, popover, etc. to build a stellar user experience

• Framer Motion – Motion library for React to animate components with ease

• Lucide – Beautifully simple, pixel-perfect icons

Sponsors

⚡TurboETH development is sponsored by 🌐 District Labs.

Acknowledgements

Original template was forked from https://github.com/wslyvh/nexth

Underlying wallet manage and design systems were changed, but the template is continuing to use the original folder structure, plus other developer experience optimizations.

Thank you @wslyvh 🙏

The Precedent designed system was absorbed (https://github.com/steven-tey/precedent) into TurboETH. 

Muchas gracies @steven-tey 🙏