Presented 27 August 2013 at Anoma Intents Day and SevenX Intent Hacker House for Stanford Blockchain Week. Watch recording.
The problem with intents
Intents introduce degrees of freedom for solvers to improve efficiency, UX, other conditions of satisfaction. However delegation to solvers introduced a principal agent problem where solver interests may no longer be aligned with users.
Broadly, there are a few options for alleviating principal agent problems:
- Reintroduce constraints
- Change the information structure of the game
- Change the payoff structure of the game
- Turn into a repeated game
We’re going to be talking about an accountability framework that was originally introduced to me by my friends at Other Internet, and that I have since extended for thinking about off-chain mechanism design.
Accountability framework
First let’s start with a definition of accountability:
A is accountable to B when A is obliged to inform B about A’s (past or future) actions and decisions, to justify them, and to suffer punishment in the case of eventual misconduct.
The social science literature typically separates this into two operations:
Answerability: a responsibility to explain or justify behavior
Enforcement: compelling compliance to a set of rules
These two functions, answerability enforcement, cohere and reinforce one another to create an accountability system between principal and agent.
Let’s look at this constructively. If a user is interacting directly with a system, of course there is no principal agent problem, they are accountable to themself.
However when a user delegates to a solver, they must establish an accountability system to safely delegate decision-making. Note, we’re ignoring more complex supply chains like builders + solvers for the sake of simplicity.
An accountability system is a kind of contract with a combination of formal and informal rules. The contracts are two-sided, where terms of satisfaction require answerability and enforcement from both ends. In this case solvers are expected to satisfy some intent, and the chain is expected to pay upon successful completion.
In Cosmos we also like to think of chains having agency, whereby they create and manage intents of their own. So one alternative view is that the protocol can delegate to a solver the capacity to complete part of a computation that would otherwise be performed by the state machine. And in this case, perhaps the chain delegates the ability to enforce to the user, who will only sign messages to release funds that satisfy the desired intent. Viewing accountability from both ends suggests a design space that has many interesting configurations.
Accountability and the dXdX off-chain orderbook
Now we can talk briefly about the work Skip has been doing for dYdX that applies some of this thinking. dYdX has a combined mempool and orderbook. Validators are expected to correctly gossip and match off-chain orders.
Skip runs globally distributed set of nodes to collect copies of the book and builds an “orderbook discrepancy” metric to measure validator P&Ls vs expected. This statistical view of behavior provides a basis for answerability. Which the dYdX chain can then use to build up an accountability system. dYdX will certainly want to increase the degree of answerability over time and evolve the accountability system, but we think this is a good initial window into validator behavior.
Reputation is a Cosmos Superpower
One of the reasons dYdX’s system can work at all is that Cosmos has a super power, which is its validators. Validators in Cosmos are great candidates for delegating certain tasks due to the latent reputational network that spans the entire ecosystem.
Cosmos validators are incentivized to differentiate via strong brands and a consistent identity chain-to-chain—this is how they attract delegations. And because reputation is informally transitive across the network, this means validators are engaging in repeated, long-term games with delegators and with protocols themselves.
It’s hard to understate how powerful this is for Cosmos, as validators are implicitly biased towards doing right by the network. Finding and fixing software, creating dashboards, writing ecosystem explainers. Almost the entire IBC network is run on a volunteer basis! Side note, we’ll be sharing more on how we can take IBC relaying to the next level soon 
Recently Keplr announced a product to further reinforce validator-delegator relationships, which we hope will strengthen the ability for validators to get feedback from their delegators, and for delegators to hold validators to account.
Conclusion
The question now is holding validators, or solvers, or relayers, accountable to what? As protocol designers and community members, we should think carefully about what kind of system behavior we want to elicit, and how to surface the correct information such that behavior is measurable and answerable. Only then can we create networks that overcome extractive behavior and take on this special character of organically generating value surplus.