An Overview of Arcadia’s Architecture
Last week we wrote about our vision for Arcadia Finance and why we decided to build a company in the first place.
Today’s post provides a high-level overview of Arcadia’s architecture, and our testing frameworks.
When we decided to build Arcadia Finance, we knew we wanted to build a different kind of protocol. We decided to take a collateral management first approach to building Arcadia because we understood that our predecessors had failed not in their algorithms, but rather in their approach to collateralization.
The way protocols approach collateralization today creates many shortcomings for the industry:
- Long-tail assets and new asset primitives cannot be used as collateral.
- Users cannot actively manage assets being used as collateral.
- Risks are defined on a single-asset level, not on a portfolio level taking into account the interactions of assets within one portfolio.
- Protocols are not future-proof. They are built around one type of asset. The emergence of new primitives/token standards, therefore, requires migrations/new protocols.
By taking a collateral-first approach, that is, formally separating the collateral management layer from the financial contracts, Arcadia solves all these problems. This architectural decision has many advantages:
- Capital Efficiency — whereas most protocols require holders of multiple assets to open multiple separate positions, Arcadia allows users to open positions in multiple financial products from a single interface, abstracting substantial complexity for the end user.
- Future proof — whereas traditional protocols build their entire architecture around a single asset type and thus are limited to what assets they can take as collateral, Arcadia’s architecture is asset agnostic, enabling the use of new assets, including long-tail assets, without requiring liquidity migrations.
- Full Composability — any protocol that requires user collateral to manage counter-party risk can integrate and/or build on top of Arcadia vaults. There is no need for redundant implementations anymore.
For more technical details on Arcadia’s architecture, keep reading.
Modular Pricing Logic
Composability enables an accelerated pace of innovation. This is why new token primitives and completely new ERC standards emerge regularly (ahem 4626). But each new primitive requires custom logic to price the token in a single numeraire (think USD or ETH). Very few protocols are built with this in mind from scratch.
At Arcadia, when we implement new logic for a new primitive or token-standard, we want users to have the ability to deposit these newly allowed assets into their vault without having to migrate to an entirely new protocol version every time. Therefore, we built a modular protocol architecture that allows Arcadia to easily add new blocks of pricing logic for new asset types. This architecture was inspired by Enzyme Finance’s approach.
To achieve this modular state, a separate logic contract is deployed per type of token. All pricing logic is internally calculated with 18-decimal precision relying on gas-efficient and battle-tested mathematical libraries. Pricing calculations have been tested to be flash-loan resistant too. Where TWAP price feeds are used, risk assessment is performed in function of the capital needed to move the TWAP price before the asset can be accepted as collateral.
For primary price feeds, we either have a direct, decentralized price oracle, or we rely on on-chain data via, for instance, Uniswap V3 TWAP prices. Examples of tokens for which we have primary price feeds are vanilla ERC20 tokens and floor prices of NFT collectibles.
For derived price feeds (as the name implies), we don’t have a direct price feed; we first break down the asset in its underlying tokens, for which we do have primary price feeds. Examples here are Uniswap LP positions or aTokens.
Vault Upgradeability
Each deployed vault is linked to a specific vault logic contract. Vault logic includes the features vault owners can benefit from, including flash withdrawals, active collateral management, authorization delegation, etc. This vault logic is upgradeable, but the user has full control of when/if they want to upgrade to a new logic. Users will not have to migrate assets or close DeFi positions when doing so.
Similarly, protocols building on top of Arcadia Vaults can determine which vault logic versions are allowed for positions within their protocol. The Arcadia protocol cannot change the version of a user-owned deployed vault.
For example, we might implement an integration with Superfluid, so that users can stream their income straight to their vault to repay a loan. In this case, no vault logic update will be forced upon our users. To us, a user taking out a credit line against their Arcadia Vault is akin to a signed contract. That is, no party should unilaterally be able to alter the conditions of an already agreed upon contract. Users are able to keep their Arcadia Vault address the same along with the assets already in it and their current credit line still running. Conversely, if a user wants to make use of the new features (a new liquidation logic, a new interest rate calculation logic, etc) they can voluntarily upgrade their vault logic when they feel the time is right. In short, vaults are upgradable, but what exists is immutable by default.
To achieve this, we shifted a lot of functional blocks around in our protocol architecture in the first few weeks. We believe we have now found the perfect balance between modularity, immutability, upgradability and gas efficiency.
Multi-asset
Our modular pricing architecture allows new token primitives and new token standards to be added to existing vaults without the need for any upgrade or asset migration.
Whereas traditional protocols build their entire architecture around a single asset type and thus are limited to what assets they can take as collateral, Arcadia’s architecture is asset agnostic, enabling the use of new assets, including long-tail assets, without requiring liquidity migrations.
Testing Frameworks
From the start we knew that our tests had to be good, had to be extensive, and had to cover any scenario. Any external library used must be separately tested too. Our first test scripts were built in JavaScript (hello Truffle and Hardhat). They worked pretty well, but if you’re running hundreds of tests where you’re deploying thousands of contracts in each test-run, JavaScript is simply not performant enough. You don’t want to be waiting 15 minutes every time you test your code changes.
Enter Foundry. Created by the giga brains over at Paradigm, Foundry is a solidity development framework that offers incredibly fast testing capabilities and insanely informative call traces (check out the repo at https://github.com/gakonst/foundry). Sure, we had used Tenderly to inspect and gas-profile transactions, but it’s way more tedious on the scale we’re working with. So we faced a decision: do we port our thousands of lines of JavaScript test code to Foundry?
Luckily at this time, Thomas was on a short trip abroad. Before anyone could stop me, the first thousand lines of Solidity test code were already written using Foundry. Needless to say we ended up porting all our tests to Foundry. As of now we’ve switched completely to Foundry.
Looking back on the decision to port our framework to Foundry, I’d definitely say it was the right call. It did cost us quite some time and effort, but the fuzzing, test speed and insights it has already provided us was well worth it. Big bonus: no more BigNumber headaches in JavaScript!
We hope this post was informative and that after reading it, you’re as convinced as we are that what we’re building at Arcadia Finance is truly revolutionary. If you want to learn more about how we’re improving on the technical limitations of current protocols, follow us on twitter. If you’re interested in building with us, please reach out.
