Zap router
This is what you interact with as a user, and approve tokens with.
It receives your Intent: (Zap X for a min of Y). Zap 10000 USDC for (at least) 9999.4 eUSD or Redeem 10 hyUSD for (at least) 10.3 USDC.
The intent is what you see in the UI. It is the minimum amount of RTokens you will receice when interacting with the router.
After pressing 'send transaction', to the router. The following happens:
Then it pulls your tokens via the approval and sends it to the zap executor.
It then forwards execution to the zap executor, with an encoded list of commands and data it needs to execute the zap.
Zap executor
The zap executor is a fork of the weiroll VM
It takes a bundle of instructions and data, and executes it. The instructions and data is generated by our token zapper:
We simulate the generated zaps using before returning the result - this means if we were to execute them on the EVM right here and now, it would commit.
But if the user waits too long with submitting their zap transaction it might still revert for various reasons. The state of the blockchain change a lot in a few blocks, so it’s best not to sit too long on a finalized zap transaction as it makes it more likely to revert.
Once the zap executor has finished, control returns the the router.
Zap router (Post execution)
The zap router verifies that the users intent has been met, or reverts if it has not.
- If the bundle the executor executed resulted in it stealing the users funds, the router will revert the whole thing, as the intent was not met.
- If the bundle the executor executed resulted in the user receiving less than the specified in the intent (The market conditions resulted in a worse result than expected) it reverts.
(The slippage setting in the settings menu large controls how sensitive the zapper is to the above by lowering the expected output of the whole zap)
Deployments
Ethereum:
- Zap (router): 0xcc2b9b55952718b210660b56ca12eb88694dc60f
- Zap executor: 0x675D37489A7A64c051D0204e5c72a469f6558a47
Base:
- Zap (router): 0xe811b62AB97d9370cE2e25F9ceBC904522b81FE1
- Zap executor: 0xA4b275feAf3A1450fc57270Ed863923261aBFD05
Arbitrum:
- Zap Zap (router): 0x39Eb11db86140d5bd0Cc24d411d833e53b0ACAf8
- Zap Zap executor: 0x59B56F9e965445f007bCc73960F6d0D034562c3e
Anyone can create an RToken
In a similar way as how anyone can create a new trading pair on Uniswap, anyone can permissionlessly create a new Reserve stablecoin (RToken) by interacting with Reserve Protocol’s smart contracts. The protocol applies a system of factory smart contracts that allows anyone to deploy their own smart contract instance.
Creating an RToken can be done either by interacting directly with the Reserve Protocol’s smart contracts or any user interface that gets built on top of it. The first user interface for these smart contracts will be released by ABC Labs the company that's leading protocol development. Besides the creation of RTokens, this user interface will also support exploring usage and stats related to RTokens, RToken minting & redeeming, and RSR staking.
Non-compatible ERC20 assets
The following types of ERC20s are not supported to be used directly in an RToken system. These tokens should be be wrapped into a compatible ERC20 token to be used within the protocol. A concrete example is the use of Static ATokens for Aave V2.
- Rebasing Tokens that return yields by increasing the balances of users
- Tokens that take a "fee" on transfer
- Tokens that do not expose the decimals() in their interface. Decimals should always be between 1 and 18.
- ERC777 tokens which could allow reentrancy attacks
- Tokens with multiple entry points (multiple addresses)
- Tokens with multiple entry points (multiple addresses)
- Tokens that do not adhere to the ERC20 standard in general
Advanced RToken parameters
When deploying an RToken, the deployer has the ability to configure many different advanced parameters. The following list goes into detail about what these parameters do and some of the factors the deployer should keep in mind to set them.
As many of these parameters concern the Protocol Operations, we advise reading through that section of the documentation first—as it will give the deployer the necessary context to fully understand all parameters.
Trading delay(s)
The trading delay defines how many seconds should pass after the basket has been changed before a trade can be opened.
A collateral asset can instantly default if one of the invariants of the underlying DeFi protocol breaks. If that would happen, and we would not apply a trading delay, the protocol would react instantly by opening an auction. This would give only auctionLength seconds for people to bid on the auction, making it very possible for the protocol to lose value due to slippage.
The trading delay parameter may only be needed in the early days - before we get to a point where there is a robust market of MEV searchers. We expect that this parameter can be set to zero later on (once a robust market of MEV searchers is established).
