Blockchain APIs are open and accessible by default - spread across execution environments and smart contract addresses. And as a result users today are met with an increasing amount of choices and decision trees in Web3.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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?

Blockchain APIs are open and accessible by default - spread across execution environments and smart contract addresses. And as a result users today are met with an increasing amount of choices and decision trees in Web3.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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?