main.tex

\documentclass[tikz]{article}

% Packages
\usepackage[utf8]{inputenc} % Core latex bundle
\usepackage[a4paper, total={6in, 9in}]{geometry} % Customize document dimensions and formats
\usepackage{changepage} % Customize page layout in middle of document
\usepackage[table]{xcolor} % Add color to tables
\usepackage{standalone} % Add figures and tables from other files
\usepackage{import} % Import glossary
\usepackage{graphics} % General color and formats
\usepackage{url} % URL formatting
\usepackage{breakurl} % URL formatting
\usepackage{enumitem} % Format list spacing
\usepackage[hang]{footmisc} % Footnote margins
\usepackage{hyperref} % References
\usepackage{mathtools} % Useful tools for mathematical typesetting and replaces amsmath
\usepackage{amssymb,bm} % Math symbols
\usepackage{svg} % SVG
\usepackage{tikz} % Making charts
\usepackage{array,boldline,multirow,float,booktabs} % Added to make tables
\usepackage{stackengine} % Customize row heights
\usepackage{hhline} % Add double lines to table
\usepackage{multicol} % Two column lists
\usepackage{nicematrix} % Put table lines after color
\usepackage{wrapfig} % Wrap figures in text
\usepackage{tocloft,titletoc} % TOC package
\usepackage{titlesec} % Section spacing

% Paper formatting
\newlength\LabelWidth
\setlength\parindent{0pt}
\setlength{\parskip}{1em}

% Section spacing
\titlespacing*{\section}
{0pt}{0.6\baselineskip}{0.6\baselineskip} % Modify section spacing - first \baselineskip is spacing before, second is spacing after the section
\titlespacing*{\subsection}
{0pt}{0.6\baselineskip}{0.6\baselineskip} % Modify subsection spacing
\titlespacing*{\subsubsection}
{0pt}{0.6\baselineskip}{0.6\baselineskip} % Modify subsubsection spacing

% String formats
\newcommand{\code}[1]{\texttt{#1}}
\newcommand{\term}[1]{\textsl{#1}}

% Paper margins
\def\changemargin#1#2{\list{}{\rightmargin#2\leftmargin#1}\item[]}
\let\endchangemargin=\endlist

% Table of contents
\renewcommand{\contentsname}{Table of Contents}
\renewcommand{\cfttoctitlefont}{\Large\bfseries} % TOC title size
\renewcommand{\cftsecleader}{\cftdotfill{\cftdotsep}} % Add dots in TOC to sections
\renewcommand{\cftsecpagefont}{} % Remove \bfseries from section titles' page in TOC

% Section
\renewcommand*{\cftsecnumwidth}{2em} % Increase space section from numbers on left
% \setlength{\cftbeforesecskip}{3pt} % Messes with section TOC length

% Subsection
\cftsetindents{subsection}{1em}{3em} % space between numbers and toc subsections
\setlength{\cftsubsecindent}{2.5em} % subsection number spacing from left
\setlength{\cftbeforesubsecskip}{3pt} % Messes with subsection TOC length was 3pt

% Subsubsection
\cftsetindents{subsubsection}{1em}{4em} % space between numbers and toc subsubsections
\setlength{\cftsubsubsecindent}{5.5em} % subsubsection number spacing from leftindent
\setlength{\cftbeforesubsubsecskip}{3pt} % Messes with subsubsection TOC length was 3pt

% paragraph section
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}

\cftsetindents{paragraph}{1em}{5em} % space between numbers and toc paragraph
\setlength{\cftparaindent}{9.5em} % paragraph number spacing from leftindent
\setlength{\cftbeforeparaskip}{3pt} % Messes with paragraph TOC length was 3pt

% indent after paragraph section
\titleformat{\paragraph}
{\normalfont\normalsize\bfseries}{\theparagraph}{1em}{}
\titlespacing*{\paragraph}
{0pt}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex}


% Abstract
% Make abstract justified
\makeatletter
\newcommand{\justified}{
\rightskip\z@skip
\leftskip\z@skip}
\makeatother

% Format and size abstract
\makeatletter
\renewenvironment{abstract}{
\if@twocolumn
\section*{\abstractname}
\else
\begin{center}
{\bfseries \large\abstractname\vspace{\z@}} % Bolds abstract name
\end{center}
\quotation
\fi}
{\if@twocolumn\else\endquotation\fi}
\makeatother

% Delimiters
\DeclarePairedDelimiter\floor{\lfloor}{\rfloor} % Define paired delimiter for floor function
\DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} % Define paired delimiter for ceiling function

% Hyperlinks
\hypersetup{
colorlinks=true,
linkcolor=black,
filecolor=blue,
urlcolor=black,
}
\urlstyle{same}

% Footnotes
\newcommand{\fref}[1]{\footnote{\href{http://#1}{#1}}}
\setlength{\footnotemargin}{8mm} % Spacing between footnote number and body

% Include tables
\makeatletter
\newcommand{\includetable}[1]{%
\@ifundefined{tablepath}{%
\InputIfFileExists{#1}{}{}%
}{%
\InputIfFileExists{\tablepath/#1}{}{\InputIfFileExists{#1}{}{}}%
}
}
\makeatother

% Table formatting commands
\newcolumntype{Q}{ >{\centering\arraybackslash} m{2.4cm} } % (Figure 5 and 11 - col width)
\newcolumntype{S}{ >{\centering\arraybackslash} m{5.27cm} } % (Figure 12 - col width double)
\newcommand\xrowht[2][0]{\addstackgap[.5\dimexpr#2\relax]{\vphantom{#1}}} % Set row height for tables
\newcommand{\rowh}[1]{\xrowht{40pt}} % Command to set row height for cell with 3 rows
\newcommand{\rowm}[1]{\xrowht{26.667pt}} % Command to set row height for cell with 2 rows
\newcommand{\rows}[1]{\xrowht{13.333pt}} % Command to set row height for cell with 1 rows

% Bean symbols
\newcommand{\BeanCover}{\includesvg[scale=2.2]{./logos/black-bean.svg}} % Logo on cover page
\newcommand{\Bean}{\includesvg[scale=0.23]{./logos/bean.svg}} % Bean used throughout the paper in text form
\newcommand{\bean}{\includesvg[scale=0.17]{./logos/microbean-wide.svg}} % Bean used in formulas - micro bean wide
\newcommand{\tinybean}{\includesvg[scale=0.13]{./logos/microbean-wide.svg}} % Bean used in formulas - micro bean wide
\newcommand{\lambdabean}{\includesvg[scale=0.17]{./logos/microbean.svg}} % Bean used in formulas for lambda superscript - micro bean

% Basin symbols
\newcommand{\BasinCover}{\includesvg[scale=0.15]{./logos/black-basin-v2.svg}} % Logo on cover page

% List Key
\SetEnumitemKey{midsep}{topsep=0pt, itemsep=3pt} % Itemize key

% File paths
\newcommand{\tablepath}{figures} % Tables file path
\graphicspath{{figures/}} % Figures file path

%%%%%%% Begin Document %%%%%%%
\begin{document}
\pagenumbering{arabic} % Start page numbering style
\thispagestyle{empty} % Hide page numbering
\begin{titlepage}
\begin{center}
\vspace*{-0.1cm}
\begin{changemargin}{-1.0cm}{-1.0cm}
\centering % added to center title
\textbf{\Large{Basin: A Composable EVM-Native Decentralized Exchange Protocol}}
\end{changemargin}
\begin{center}
\BasinCover
\end{center}
\vspace{0.4cm}

\begin{center}
    \begin{tabular}{>{\centering\arraybackslash}p{5cm} >{\centering\arraybackslash}p{5cm}}
        \large{Brendan Sanderson} & \large{Ben Weintraub} \\
        \href{mailto:brendan@manifestcrypto.org}{\normalsize{brendan@manifestcrypto.org}} & \href{mailto:ben@manifestcrypto.org}{\normalsize{ben@manifestcrypto.org}}
    \end{tabular}
\end{center}

\begin{center}
    \begin{tabular}{>{\centering\arraybackslash}p{5cm} >{\centering\arraybackslash}p{5cm}}
        \large{Brean} & \large{Silo Chad} \\
        \href{mailto:brean.beanstalk@protonmail.com}{\normalsize{brean.beanstalk@protonmail.com}} & \href{mailto:silochad@protonmail.com}{\normalsize{silochad@protonmail.com}}
    \end{tabular}
\end{center}

\begin{center}
    \begin{tabular}{>{\centering\arraybackslash}p{10cm}}
        \large{Beanstalk Farms} \\
        \href{mailto:beanstalkfarms@protonmail.com}{\normalsize{beanstalkfarms@protonmail.com}}
    \end{tabular}
\end{center}

\normalsize{\href{https://basin.exchange/}{basin.exchange}}

\vspace{0.4cm}
\footnotesize{Published:} \normalsize{August 23, 2023}

\vspace{-0.25cm}
\footnotesize{Modified:} \normalsize{July 14, 2024}

\vspace{-0.25cm}
\footnotesize{Whitepaper Version:} {\normalsize{1.0.1}}

\vspace{-0.25cm}
\footnotesize{Code Version:} \href{https://github.com/BeanstalkFarms/Basin}{\normalsize{1.0.0}}\footnote{\href{https://github.com/BeanstalkFarms/Basin}{github.com/BeanstalkFarms/Basin}}


\vspace{0.1cm}
\flushleft{\normalsize{\term{“Composability is to software as compounding interest is to finance.”}}}

\normalsize{\hspace{2.5em}- Chris Dixon, October 23, 2021}\fref{twitter.com/cdixon/status/1451703067213066244}
\vspace{0.4cm}
\begin{abstract}
\justified{\normalsize{\noindent Exchanging is a core piece of economic activity. However, current decentralized exchange (DEX) architectures are not composable, such that adding an exchange function or oracle to them is difficult. The nature of open source software is that each problem should only need to be solved once in a given execution environment. Non-composable DEX architectures prevent this. We propose an EVM-native DEX architecture that (1) allows for composing arbitrary exchange functions, oracles and exchange implementations for ERC-20 Standard\fref{eips.ethereum.org/EIPS/eip-20} tokens and (2) includes a registry to verify exchange implementations.}}
\end{abstract}
\end{center}
\end{titlepage}

\newpage

% TOC formatting
% \addtocontents{toc}{\protect\enlargethispage{20mm}} % TOC margins
\thispagestyle{empty} % Hide TOC page numbering
\addtocontents{toc}{\protect\thispagestyle{empty}} % Allow hiding both TOC page numbers

\cleardoublepage
\pagenumbering{gobble}
{\large\tableofcontents} % Compile TOC with large font
\cleardoublepage
\pagenumbering{arabic}

% \thispagestyle{empty} % Hide TOC page numbering
% \addtocontents{toc}{\protect\thispagestyle{empty}} % Allow hiding both TOC page numbers

\newpage
\setcounter{page}{3} % Begin page numbering

\section{Introduction}
Despite the outsized importance of DEX protocols to the permissionless economy, innovation of them has been slow. One major problem with current decentralized exchange architectures is a lack of composability, such that to add, remove or replace a component of a decentralized exchange requires writing an entire exchange protocol. This is highly inefficient.

The primary components of a decentralized exchange protocol are (1) exchange functions, which specify the conditions under which a given asset can be exchanged for another, (2) oracles, which save data related to the exchange relevant to other protocols that need to permissionlessly and atomically query the exchange's state and (3) exchange implementations that facilitate use (\textit{i.e.}, swapping, adding and removing liquidity) of the exchange.

Utility of decentralized exchanges has been limited in part because current DEX architectures mandate market makers provide liquidity using a finite set of exchange functions that are provided by the DEX. This limits the flexibility and capital efficiency of market makers' liquidity. Lack of flexibility and capital efficiency of liquidity make profitably market making on DEXs excessively difficult. Profitable market making is essential for well functioning liquid markets. Excessive friction to customizing exchange functions to provide liquidity on decentralized exchanges makes it difficult for decentralized permissionless trading environments to compete with centralized permissioned ones in attracting market makers. A shortage of market makers leads to a shortage of liquidity; a shortage of liquidity leads to a lack of utility for takers. 

Saving oracle data on a decentralized network is expensive. The only reason to save DEX data in a network-native oracle is so that it can be queried atomically and permissionlessly by other network-native protocols. Current DEX architectures mandate using a particular oracle, independent of whether the data saved is being used by other network-native protocols. Because the cost to saving oracle data is typically passed on to takers of the DEX, this policy imposes an often unnecessary cost on all takers. 

In a post-Merge\fref{ethereum.org/en/roadmap/merge/} environment, the risk of oracle manipulation due to multi-block maximum extractable value (MEV) attacks has risen dramatically.\fref{alvarorevuelta.com/posts/ethereum-mev-multiblock} This has made using existing network-native oracle solutions risky and impractical for protocols that require manipulation resistant oracles. Upgrading the oracles in existing DEXs to be multi-block MEV resistant is impossible due to the lack of composability between exchange functions and oracles. As a result, protocols are forced to use non-network-native oracle solutions that require additional trust assumptions beyond the integrity of the network itself,\fref{liquity.org/blog/price-oracles-in-liquity} while takers are still paying to update useless oracles.

Basin is an open source permissionless decentralized exchange architecture that allows for the composition of arbitrary exchange functions, network-native oracles and exchange implementations into a single liquidity pool. A registry of pool implementations allows for users to verify the accuracy of a pool's use of its exchange function, oracles and exchange implementation. Anyone can deploy new exchange functions, network-native oracles, exchange implementations and registries. Similarly, anyone can deploy a new pool through an existing registry with an exchange function, any (or no) network-native oracles and an exchange implementation included in the registry. In practice, Basin lowers the friction for market makers to deploy liquidity with custom exchange functions
 and allows their liquidity to be used by other network-native protocols without additional trust assumptions.

\section{Previous Work}
Basin is the next step in the evolution of EVM-native DEXs.

A robust, trustless computer network that supports composability and fungible token standards (\textit{e.g.}, Ethereum) is necessary to host a DEX. Basin supports the exchange of ERC-20 tokens.

Uniswap\fref{uniswap.org} pioneered use of the constant product exchange function that has been immensely popular for market making long-tail assets despite its capital inefficiency. Uniswap has also innovated on manipulation resistant network-native oracles by moving from a simple moving average (SMA) of an arithmetic mean,\fref{uniswap.org/whitepaper.pdf} which weights outliers equally to all other data points, to an SMA of a geometric mean,\fref{uniswap.org/whitepaper-v3.pdf} which weights certain outliers significantly less.

Curve\fref{curve.fi} implemented a variation on the constant product function that allowed for a single parameter (\textit{i.e.}, the A parameter) to be set at pool deployment and adjusted by protocol governance. However, governance is mandatory and omnibus, such that every pool is governed by the same body, independent of who is providing liquidity to it.

Solidly\fref{solidly.exchange/} allowed for the use of more than one exchange function through a single DEX. 

\section{Basin}
Well designed open source protocols enable anyone to (1) compose existing components together, (2) develop new components when existing ones fail to meet the needs of users or are cost-inefficient and (3) verify the proper use of existing components in a simple fashion. Basin allows for anyone to compose new and existing (1) \term{Well Functions} (\textit{i.e.} exchange functions), (2) \term{Pumps} (\textit{i.e.}, network-native oracles) and (3) \term{Well Implementations} (\textit{i.e.}, exchange implementations) to create a \term{Well} (\textit{i.e.}, a customized liquidity pool). \term{Aquifers} (\textit{i.e.}, \term{Well} registries) store a mapping from \term{Well} addresses to \term{Well Implementations} to enable verification of a \term{Well Implementation} given a \term{Well} address. \term{Aqueducts} (\textit{i.e.}, \term{Well} whitelists) store a list of approved \term{Well Functions}, \term{Pumps}, \term{Well Implementations} and \term{Aquifers} to create a single point of trust for users.

A \term{Well} allows for the provisioning of liquidity into a single on-chain position that follows arbitrary rules and is represented by an ERC-20 token (\textit{i.e.}, a \term{Well} LP Token). Each \term{Well} is defined by (1) a list of tokens, which contains the set of ERC-20 tokens that the \term{Well} supports (\textit{i.e.}, that can be exchanged through, added to, and removed from the \term{Well}), (2) a \term{Well Function} and its associated data, which defines an invariant relationship between the \term{Well's} \term{Reserves} (\textit{i.e.}, the balances of tokens in (1) at the time of the last supported \term{Well} operation) and the supply of \term{Well} LP tokens, (3) \term{Pumps} and their associated data, which implement network-native oracles that are updated each time associated \term{Well's} \term{Reserves} may change, (4) a \term{Well Implementation}, which contains all logic for actions supported by the \term{Well}, (5) optional arbitrary additional data used by the \term{Well} and (6) the \term{Aquifer} that deployed the \term{Well}.

A \term{Well's} state consists of its \term{Reserve} balances and \term{Well} LP token ownership.  \term{Well} LP tokens are ERC-20 tokens representing pro-rata ownership of the \term{Well’s} \term{Reserves} and implement ERC-2612.\fref{eips.ethereum.org/EIPS/eip-2612} \term{Well Functions} and \term{Pumps} can be independently chosen to be stateful or stateless, while \term{Well Implementations} are stateful. Including \term{Pumps} in a \term{Well} is optional.

A \term{Well's} (1) address and its associated data, (2) list of tokens, (3) \term{Well Function} and its associated data, (4) \term{Pumps} and their associated data and (5) deploying \term{Aquifer}, can be stored as immutable data in contract storage or as appended bytecode. The associated data of the \term{Well} address, \term{Well Function} and \term{Pumps} are optional and can be arbitrary. Requirements for and use of the associated data of the \term{Well} address are specified by the \term{Aquifer}; requirements for and use of the associated data of the \term{Well Function} and \term{Pumps} are specified by the \term{Well Implementation}. 

\subsection{Well Function}
\vspace*{-0.1cm}
A \term{Well Function} defines an invariant relationship between a \term{Well's} \term{Reserves} and the supply of \term{Well} LP tokens. Basin supports \term{Well Functions} that contain arbitrary logic. However, \term{Well Functions} must be deterministic to be used alongside \term{Pumps}. In practice, the handling of arbitrary logic in a \term{Well Function} allows for arbitrary order creation (i.e., conditional orders that take network state data as inputs).

\subsection{Pump}
\vspace*{-0.1cm}
\term{Pumps} are a generalized framework for network-native oracles. A \term{Pump} is updated upon each interaction with a \term{Well} that uses it. A \term{Pump} can be shared by multiple \term{Wells} if it stores a mapping of multiple \term{Well} addresses. Each \term{Pump} can determine its own method of recording a \term{Well's} \term{Reserves}. 

When there’s an interaction with a \term{Well}, the \term{Well} sends two pieces of information to its \term{Pumps}: (1) a list of \term{Reserve} amounts and (2) additional metadata as a bytestring. Each \term{Pump} is responsible for deciding how to weight the new \term{Reserve} values relative to the values it had previously and processing the bytestring. 

Because storing data on-chain is expensive, only absolutely necessary data should be recorded. Each \term{Well} can be deployed with an arbitrary set of \term{Pumps}, such that only and exactly the data necessary to satisfy composability between the liquidity in the \term{Well} and arbitrary other protocols desired by the liquidity provider is recorded on-chain. \term{Pumps} create a minimalist, composable way for liquidity providers to maximize use of their liquidity in other protocols while minimizing gas costs associated with trading against it.

\subsection{Well Implementation}
\vspace*{-0.1cm}
\term{Well Implementations} contain all logic to support swapping against, adding liquidity to and removing liquidity from, a \term{Well} in arbitrary proportions. A \term{Well Implementation} may require a \term{Well} to have associated data which the implementation uses to properly interface with its \term{Well Function} (\textit{e.g.}, an A parameter for a Curve style stableswap invariant, a trading fee, etc.) and \term{Pumps} (\textit{e.g.}, the \term{Pump} look-back period). \term{Well Implementations} can specify a whitelist (or blacklist) of acceptable (or unacceptable) counterparties and/or liquidity providers.

\subsection{Aquifer}
\vspace*{-0.1cm}
\term{Aquifer} is an instance of a \term{Well} factory (i.e., a permissionless \term{Well} deployer and registry). \term{Aquifer} deploys \term{Wells} by cloning a pre-deployed \term{Well} and stores a mapping of the new \term{Well} address to the \term{Well Implementation} address. 

\term{Aquifer} creates the first layer of trust for Basin users by providing a way to verify a \term{Well's} \term{Implementation}, given its address. However, users must still verify the \term{Well's} \term{Well Function}, \term{Pumps} and \term{Well Implementation}.

\subsection{Aqueduct}
\term{Aqueduct} is a whitelist of \term{Well Functions}, \term{Pumps}, \term{Well Implementations} and \term{Aquifers}. \term{Aqueducts} create a single point of trust for users of Basin components. As long as all the components of a \term{Well} are included in a trusted \term{Aqueduct}, the \term{Well} can be trusted. In practice, protocols can deploy an \term{Aqueduct} that specifies all the Basin components liquidity providers can (or must) use in order to receive some form of credit from it. 

\subsection{Governance}
All components of Basin (i.e., \term{Well Functions}, \term{Pumps}, \term{Well Implementations},  \term{Aquifers}, and \term{Aqueducts}) can, but need not, be upgradable. Governance of upgrades to each component is dependent on the owner of the component. 

\section{Risks}
There are risks associated with Basin. This is not an exhaustive list.

The Basin code base is novel. None of its components has been tested in the “real world” prior to its initial deployment. The open source nature of Basin means that others can take advantage of any bugs, flaws or deficiencies in it. While Basin and an initial implementation of each of its components (except \term{Aqueduct}, which has not been implemented) have been audited,\footnote{\href{https://basin.exchange/06-16-23-halborn-report}{basin.exchange/06-16-23-halborn-report}}$^{,}$\footnote{\href{https://basin.exchange/06-16-23-cyfrin-report}{basin.exchange/06-16-23-cyfrin-report}} it is no guarantee of security. 

Particularly before the development of an \term{Aqueduct}, each component should be verified by users in order to ensure proper functionality. 

\section{Future Work}
Basin is a work in progress. The following are some potential improvements that can be incorporated into Basin through future development:

\begin{itemize}
\item Support for ERC-1155\fref{ethereum.org/en/developers/docs/standards/tokens/erc-1155} and ERC-721\fref{ethereum.org/en/developers/docs/standards/tokens/erc-721} Standard tokens can be added.
\item Additional \term{Well Functions} can be implemented.
\item A template \term{Aqueduct} can be implemented.
\end{itemize}

\newpage
\section{Whitepaper Version History}

The following is a complete version history of this whitepaper. Unless otherwise noted, references within this Whitepaper Version History are not updated to reflect later changes.

\begin{itemize}[topsep=0pt, itemsep=3pt,leftmargin=16pt]
    \item \href{https://github.com/BeanstalkFarms/Basin-Whitepaper/blob/main/version-history/basin1_0_0.pdf}{1.0.0} (August 23, 2023)
    
    \begin{itemize}
        \item Original whitepaper.
    \end{itemize}
    
    \item \href{https://github.com/BeanstalkFarms/Basin-Whitepaper/blob/main/version-history/basin1_0_1.pdf}{1.0.1} (July 14, 2024)
    
    \begin{itemize}
        \item Updated citation 5 with the new URL for the  \href{https://www.alvarorevuelta.com/posts/ethereum-mev-multiblock}{Multi-block MEV in Ethereum} article.
    \end{itemize}
\end{itemize}

\end{document}

\end{document}