# SUAVE, its contracts and higher order commitments

This document aims to give a brief high-level introduction to the literature associated with the idea of "higher order commitments", place HOC's in the context of SUAVE and highlight some of the open problems going forward. Broader discussion on SUAVE is happening in other documents.

## wut is HOC

There is a body of game theory literature which studies "commitment games". The idea is that agents in a game are given the ability to commit to playing certain strategies before the game starts. Depending on the game and what kinds of commitments people can make, the commitments can have a large impact on the outcome. For example, in [a game of chicken ](https://en.wikipedia.org/wiki/Chicken_(game)), one player committing to not swerve no matter what means that you will never have (swerve, swerve) as an outcome and probably that the other player will swerve. Importantly, the presence of commitments can help agents achieve a universally better outcome than the equilibrium without commitments (e.g. working together in prisoner's dilemma).

There are many different commitment settings with different properties. What Xin has come to refer to as "higher order commitments" are commitments which also refer to other players' commitments. E.g. in the prisoners' dilemma "I commit to cooperate if the other player commits to cooperating, else defect." The most universal and "implementable" version of this is studied in a niche field known as "program equilibria" in which users submit Turing complete programs as their commitments. There are nuanced differences between programs and commitments, but I'll leave this aside for now.

*a theoretical example of a program a prisoner can submit*

## Why do we care?

We're surrounded by commitment games in MEV. When users send transactions to the mempool, they are effectively committing to a weird kind of strategy. CoWswap users are participating in these kinds of commitment games in that they the outcome of the program they submit to the CoWswap server depends on what other users' programs do (more on this below). As such, the commitment literature is already interesting to study.

Currently many of these commitment games are enforced via trust. For example, a CoWswap user is trusting the CoWswap server to choose the highest solver batch to execute the order. By moving these kinds of operations to suave "builder" contracts and allowing for permissionless deployment of builder contracts, we are headed into an increasingly complex world of commitment games.

To be clear, a call to a suave builder contract can be interpretted as a "program," but the actual execution logic need not have every builder contract call be a program in and of itself. The execution flow could be something like
* input list of CoWsuave limit orders & list of solver solutions
* execute
(I realise this is not realistic for now)

Arguably, things like programmable privacy [have already been studied](https://arxiv.org/pdf/2204.03484.pdf) to some extent in the context of program equilibria. The high-level connection is that we want to share information with counterparties we know won't abuse it (and share little or nothing when they can). Being able to condition on the programs submitted by other agents means that a program can choose to share information only when the other program embodies the desired behaviour.

## Problems

### Interaction Between Games
Ethereum blocks still have a notion of ordering and we anticipate that many users may still end up playing ordering-based games (e.g. top-of-block arbers). It's unclear how the contracts and the ordering processes should interact. For example, the CoWsuave contract may output a transaction which is then inserted into a block. Should this CoWsuave contract be evaluated without any information about the Eth state it will be executed against? In this case the contract would have to be reexecuted every time a new ordering is grinded.

If the CoWsuave contract is executed without any dependence on the Ethereum state it will be executing against, we lose some efficiency from optimal routing (and maybe other info?). We could allow the CoWsuave contract to output a call to a routing contract which is actually dependent on ordering.

Idk.

### Censorship Resistance

We want to guarantee a user calling the CoWsuave contract that it will only be executed with all other CoWsuave limit orders and solver solutions included. In the presence of censorship, users get much worse execution and will prefer the centralised solution.

I have elaborated on some approaches to solving this elsewhere, but noting it here as well.

### Granular Conditioning
One problem with program equilibria is that conditioning on another program requires us to be able to verify properties of other programs. There are several approaches for doing this. In the example shown above, one program conditions specifically on the type of the other program. This is the easiest route for us to go. In the CoWsuave case, for example, programs would need to know that other programs were formed by calling the CoWsuave limit order function or solve function (I realise that I haven't defined these, coming soon).

This approach, however, is static and may be too restrictive. Going further, we may want to be able to make more general statements, e.g. "all programs/contracts which satisfy <predicate> may read the input to this contract". It's not clear how to do this, but one way we try is to have the properties come for free with how contracts are defined (e.g. if the output of a contract is only ever a single tx) or to allow anyone to permissionlessly provide a proof that a contract satisfies a property, which would update that contract's permissions.