AL #009: Design with Objectives not Intents
AL #009: Design with Objectives not Intents
The arc of progress in DeFi: Transactions → Intents → Objectives
Crypto Founders and Investors are obsessed with “intents”.
The concept escaped private Telegram groups via Research Day and now has been touring Crypto Twitter.
I'm not here to argue why intents are the next big thing. In fact, I'm arguing they're not the entire answer – intents are one step divorced from what users really want.
So what’s an intent
Uma offered an informal definition of intents during Research Day:
The idea is that an intent is effectively some preference over a set of transactions that may get executed on a user’s behalf.
When we go to transact with Uniswap, we want to execute a swap. But our transaction obscures the underlying intent which could have been better served by a more general product (e.g., a Dex aggregator like Matcha).
Intents are better than transactions precisely because they correspond to user preferences, not protocol constraints.
The problem with intents
The issue with intents is that they are framed in terms of actions.
A user doesn't really want to swap on Uniswap. Instead they may:
Want to close out a profit on an investment position (in which case they didn't want to be optimizing for the best time to do this)
Want to acquire some ETH to pay for gas (in which case they would have preferred to use gas-less transactions)
Want to sell some ETH in exchange for USDC (in which case they would have preferred using an automated dollar cost averaging strategy).
In each of these cases, the intent may look very similar (sell a fixed amount of token X), but the underlying objective is very different.
In each of these cases, the user would have preferred not to have to take the action at all.
Enter passive finance and objectives
What we really want is to be able to define an objective function (or utility function in game theoretical terms) and have the protocol take actions when necessary on our behalf.
Consider the ProfitWell Retain product for SaaS companies.
It claims to “automatically improve retention 15-40%, just by plugging in your billing system.”
This seems too good be true but it really does work.
How?
15-40% of churn is driven by credit card cancellations. ProfitWell Retain automatically e-mails users whose credit cards are nearing expiry and helps them update their subscriptions.
That's it.
This also works in crypto.
Aera helps DAOs manage their treasuries by specifying a unique objective function for each treasury.
The DAO can express its preferences via their objective function and guardians are rewarded by taking the actions that improve the objective function.
This is especially useful for DAOs where actions cost a lot of governance time.
Ultimately, passive finance should be the goal and objectives are a much better fit for intents to achieve that goal.
Here’s how you can design an objective-driven protocol.
1. Parametrize the user's goals
First, decide what users will try to achieve with your protocol.
Instead of thinking about actions (swap X), think about ideal states that the user wants to get to (e.g., 2x starting capital).
The next step is to parametrize the user’s goals so they can easily express their preferences.
Wealthfront, an investment management service offers 10 pre-defined risk levels that have clear names and descriptions. They even created a survey to help you define your own risk level.
This is great UX from the perspective of defining user objectives.
2. Define what intents and transactions help achieve these goals
Next, you’ll decide what actions your protocol can take on behalf of the user to achieve these objectives.
In some cases (yield-bearing vaults), no further action will be necessary other than the initial deposit.
In other cases, the protocol will either need to automate certain transactions on your behalf or incentivize other network participants to take these actions.
3. Consider what communications will help the user
Finally, designing with objectives doesn't mean that users should be kept out of the loop.
The opposite is true.
Doing things automatically on behalf of users means that you need to take extra steps to maintain trust.
Here are three aspects of trust to obsess about:
They need to be convinced that you are achieving the objectives.
They need to have transparency on how the objectives are being achieved
They need to maintain control over the objective.
There are many creative ways to maintain transparency this way whether it's dashboards, notifications or dedicated communications.
The objectives design pattern is the natural end state of finance. It’s a long-term goal we can work towards, not necessarily something we can achieve immediately.
But many protocols can already benefit from these ideas and thinking about what your users truly want can only be beneficial.
Need help building a crypto product?
→ Twitter: Follow me for more frequent & casual insights on the crypto industry.
→ Need an advisor?: I help Seed stage crypto Founders get to Product Market Fit with proven systems. Respond to this e-mail with “Product Market Fit” to start a conversation or click on “Need an advisor” to jump on a free discovery call.