A Problem at Hand

Ethereum applications are complicated for researchers to reason about, developers to create, and users to use. What would make this process easier? The answer is Kits.

As our team has been building Arbiter, DFMM, Portfolio, and, as of late, Excalibur, we have been honing in on a top-down perspective to user interactions and a bottom-up approach to building. The user interactions have been widely discussed in the Ethereum community as intents, while we have explored them in simulation-driven development. Likewise, while the ecosystem has continued to provide a more robust infrastructure, applications built on top of this infrastructure continue to grow in utility.

Our approach today is to align the bottom-up and top-down approaches by describing all possible interactions with any Ethereum application by one codified idea: Behaviors.

Alongside any Ethereum application, we can define a set of behaviors to simulate and test the application; these behaviors illustrate user flows and interactions with the application. These behaviors can be built before the application, like in test-driven development. This collection of behaviors, contracts, and their means of being composed and organized is a Kit. Diagramatically, it gives us something like this:

Let's start from the bottom and work as if we were building a new application.

Research and Development

Any new application starts with an idea of what it can provide users. From the idea, researchers consider the mechanisms involved and the actors that will interact with the application. At the same time, developers are working to begin building workable versions of the application. This stage presents synthesis between R&D.

While this discovery process occurs, researchers can use Arbiter to develop the essential behaviors for the kit accompanying the application. For instance, if the application is a DEX, these behaviors might include Swap, AddLiquidity, RemoveLiquidity, CollectFees, etc. Given that it's running on an Ethereum chain, we also care about UpdateBlock and ChangeGasPrice behaviors, though these are not specific to the DEX! These behaviors define anything and everything that can happen in the application, and how they are combined describes a long-running simulation of the application. How so?

For example, imagine we are building a DEX and want to simulate the Behavior of retail users randomly swapping tokens. When a user swaps, the DEX will take a fee, and the user will receive the swapped tokens. The price of the DEX will also change. This price change alerts arbitrageurs(who run specific Swap behavior logic) to swap tokens to take advantage of the price change. Other behaviors may be looking to swap once a specific price is reached or to swap a certain amount of tokens at a particular time. Each of these drives the market forward and unravels the complex interactions that can happen in the DEX, all using the behaviors.

In this way, researchers can use Arbiter to develop and test the application in a mainnet-like environment before the application's construction. The Arbiter environment is configurable and can be simplistic, realistic, chaotic, and adversarial. These models inform the developers of potential application issues and provide insight into how the application may be improved, e.g., optimized, parameterized, and secured.

Teams can iterate through this process and ensure a safe, clean, and easy-to-use application when it is ready for third-party auditing.

Integration and User Flows

Now that your application has gone through iterations of research, testing, and development, your behaviors have stayed up to date with the application as they have been an essential part of your simulation toolkit. These behaviors used for testing can be extended and used to create an intuitive user interface, given they have been iterated on continuously alongside the application itself. That Swap behavior created for simulation can now be used for user flows in an interface. This is where the bottom-up approach comes into play.

In a simulation, Swap has less to deal with than on a live network. For example, you may need to extend your Swap behavior to monitor the transaction as it waits for confirmation. Only once this is confirmed can the Behavior be deemed completed. Monitoring can also allow you to make changes as necessary to ensure the transaction occurs on time and as expected.

The behaviors created in the R&D phase should be battle-tested and safe for use, as you can see their results in the simulation. Of course, more development is needed to handle the case of confirmations described above, but this can also be done on test networks. If appropriately designed, the Behaviors can be extended from simulation and battle testing into more customizable and complex user flows while remaining safe since the foundation has not changed.

Kit Design

When building your kit, you can start with a set of smart contracts and use Arbiter as a blazing-fast sandbox for your testing. Arbiter also provides the context for you to implement your Behaviors. These should be small event-driven actions that can be extended and used in tandem with one another. Following this principle will allow you to build a kit that can be composed together to define intricate simulations or multi-step user flows. Think about it using this diagram below.

We have a few open-source examples you can reference if you are interested in developing a kit for your application. Remember that these are currently in active development and are not yet ready for use in production! Likewise, we are always available to help you start your kit.

DFMM Kit

In the DFMM repository, we have been working on a kit for our in-house DApp called DFMM. The set of contracts in DFMM was developed alongside simulations, but we were also building software around the simulations to make the process simpler for others to use. Now that this process has been made stable, dfmm-kit represents our version of what your DApp's kit might look like. We can give more concrete user behaviors by taking a more concrete view of the behavior anatomy.

Here, we can look at some common user behaviors for the Dynamic Function Market Makers. For example, someone may want to deploy a new strategy they built, or they may want to allocate capital to a strategy. These behaviors can account for custom logic as well. In this diagram, we see a behavior called swap restrictions; this can resemble additional conditions that must be met before a swap can be executed.

For example, in the Constant Sum Strategy, where liquidity is supplied at a single price, you may want to allocate a stop loss position for two weeks, and if two weeks if up the swap should not execute.

We will continue to pave the way for the user side of using DFMM.

Uniswap V3 Kit

An open-source example kit is the integration kit for Uniswap V3. Many users of Arbiter have asked for this example, and we are excited to work on it collaboratively with the community.

The goals here are the same, albeit UniswapV3 will likely see no future changes with V4 around the corner. Instead, we can focus more on the user side of things here.

Future Snapshot: Positions

In DeFi, there is a need also to have an analogous concept to user behaviors, but more catered towards monitoring and managing portfolios. We are working towards developing an element for kits that we currently codename as Position. DeFi kits with both Behavior and Positions would point towards a landscape where DeFi applications become wholistic modules that can be nicely composed and used in various ways. More on this in the future!

Wrapping Up

If you would like to learn more about how to build your kit, or if you would like to use Arbiter to develop and test your application, please reach out to us on Discord or Twitter. Likewise, visit any of the repositories mentioned above to see how we are building our kits and how you can use them as a reference for your own. We are happy to take contributions and discussions on making the process of building Ethereum applications more accessible and robust.