Asset Risk Assessment: Fixed Forex
A look into Iron Bank and Keep3r's Fixed Forex product
Useful links:
Iron Bank Unitroller - Can add or remove assets and oracle. Controlled by Iron Bank Multisig behind the Iron Bank Timelock.
Iron Bank PriceOracleProxy - Controls oracle fallback logic. Controlled by Iron Bank Multisig (behind Timelock) and Guardian.
Iron Bank Timelock - Admin for Iron Bank. Controlled by Iron Bank Multisig. Set with 1 day minimum delay.
Fixed Forex ib_controller - mints ibTokens into Iron Bank. Controlled by Keep3r Multisig
Abstract
Fixed Forex allows the borrowing of a new family of forex stablecoins from the Iron Bank. By incentivizing liquidity for these stables in Curve, Fixed Forex hopes to increase non-USD stable liquidity in DeFi.
A quick TL;DR of our findings:
Much of Fixed Forex security guarantees rely upon Iron Bank security. ibTokens enter circulation by being borrowed through the Iron Bank. The Iron Bank’s liquidation mechanics establishes the peg.
The Keep3r 3/5 Multisig has the ability to adjust the ibToken interest rate and funnel earned interest where it pleases. It cannot steal user funds, which are in the Iron Bank’s custody.
The Iron Bank 3/5 Multisig has the ability to rug users, although it is behind a one-day timelock.
The Iron Bank audit was done as part of a brief audit of CREAM V2. The audit did not explicate the differences from Compound, the protocol forked, but highlighted the lack of documentation of the changes as problematic.
The Fixed Forex audit was minimal, checking for compliance with the ERC20 standard.
Usage of Curve pools containing ibTokens is minimal, meaning LPs profit chiefly from rewards.
Fixed Forex - An Introduction
The Fixed Forex protocol creates foreign exchange stablecoins, called ibTokens, that maintain their peg by being backed by collateral assets deposited into the Iron Bank. Although the Iron Bank’s liquidation mechanism ultimately ensures the peg, Curve plays an important role in providing cheaply available liquidity for swaps between ibTokens and other forex stables.
Iron Bank
Since the protocol relies on Iron Bank for much functionality, we give a brief review here. The Iron Bank is a Compound fork that allows collateralized borrowing from a shared pool of collateral assets with the added feature of credit-based lending for whitelisted protocols. Iron Bank’s version of Compound’s cToken is effectively the same except for extra logic to handle a lending cap based on the whitelisted protocol’s credit limit (technically, the modification made is to Compound’s Comptroller contract, which is where borrow limits are calculated).
A cToken can be thought of as a vault where you deposit an underlying token and receive a cToken amount based on an exchange rate that accounts for each cToken sharing accrued interest in the underlying. Once a user has obtained one or more types of cTokens by depositing one or more underlying assets, they can borrow any other underlying up to a percentage of their deposited collateral value. The collateral prices are obtained via Chainlink or Band price feeds.
ibToken as an asset
The key “trick” behind Fixed Forex is that you can design a cToken that takes in a value-less token you have minted at will, e.g. let’s say ibEUR. By pricing ibEUR using an oracle that prices EUR in USD, you decree the value of ibEUR to be equal to EUR. Thus when a user wants to borrow ibEUR, it gets priced as EUR and requires the appropriate value in deposited collateral to back it, e.g. if a user deposits $1000 in WETH, they would be allowed to borrow $750 worth of ibEUR since WETH’s collateral factor is 75%. (To complete the story, we should mention that ibEUR’s collateral factor is 0%; nobody can borrow against it!)
This idea effectively turns what was originally a shared pool of collateral assets into a shared CDP generating pegged assets at will.
Minting ibToken
The minting of ibTokens is explicitly privileged and handled by the token governor, set to the ib_controller which is controlled by the Keep3r 3-of-5 multisig:
gov account to mint. gov can be set by the Keep3r Multisig with a 1-day delay.The multisig can infinitely mint ibEUR to the ibEUR contract itself. The contract allows only two ways for ibEUR tokens to leave its account: 1) deposit function 2) profit function
The deposit function deposits the contract’s entire balance into the cyToken corresponding to the ibToken. The cyToken is given as the ib property in the ibToken contract. In the case of ibEUR (our example), ib points to Yearn’s cyEUR token contract deployed by Cream Finance.
The cyEUR token contract is a fork of Compound’s cToken contract. This contract is behind a proxy and is upgradeable, controlled by the Iron Bank multisig bound by a one-day timelock.
The underlying implementation has been updated following recent bugs found in the original Compound contracts. An example of a Github commit amending a Compound bug found in Compound and amended in Iron Bank: protection for reentrancy liquidation attack commit.
Once the assets are deposited into cyEUR, they can be borrowed by any user who has sufficient collateral in the Iron Bank. This condition is checked using the price oracle to compare the ibEUR value to be borrowed against the user’s available collateral value.
The profit function claims earned ibEUR from the cyEUR contract. The earned profit is sent to the gov account.
The currently set gov is ib_controller, which has a corresponding profit function that sends the profit to the burner account.
profit function transfers profits from ibTokens to the burner account. This account can be set by the Keep3r Multisig.Risk Vectors
Some of the risks below are highlighted in the Fixed Forex docs.
Custody Risk
Given the tight linkage between Fixed Forex and Iron Bank, it is important to distinguish the power each gives to its multisig.
The Iron Bank multisig is able to make several changes to the system that could pose a danger to deposited user funds:
it can add an oracle that provides inflated prices
it can add a maliciously-crafted asset contract
it can alter the collateral factor of any asset
These changes have to be made through the Iron Bank Unitroller, which allows only the admin account to do so. The admin is set to a timelock controller managed by the Iron Bank multisig.
Regarding #1, the multisig can disable the oracle hierarchy which starts with Chainlink, falls back to Band, and then ultimately falls to Cream V1’s custom oracle. The custom oracle allows a price override via setPrices, which is still being used by Iron Bank for certain assets. The guardian of the PriceOracleProxy can also set the oracle source.
Regarding #2, the protocol assumes that any added asset is a protocol-compliant cToken. Of course, this doesn’t have to be the case; the supposed cToken could literally just take your funds upon deposit.
Regarding #3, the Iron Bank multisig could change the collateral factor of ibTokens, say to 90%, enabling leveraged borrowing. This is likely dangerous on its own, but also breaks the unique asymmetry which defines the Fixed Forex protocol: ibTokens are backed by collateral when borrowed but have no value as collateral itself.
In contrast, the Fixed Forex (Keep3r) multisig is only able to:
alter the supply of ibTokens through control of the
ib_controllerable to set, via a 1-day delay, the controller for ibTokens
able to set the burner address which collects earned interest
Regarding #1 and #2, depositing a large supply into the Iron Bank would decrease interest rates. Similarly, redeeming a large supply from the Iron Bank would increase interest rates.
This enables a possible attack where the multisig could withdraw supply in order to force liquidations and in concert with other entities could get collateral at a discount. However, very possibly other liquidators will also profit from this, so we regard this as low risk.
Regarding #3, we noticed that the set_burner function on the ib_controller does not have a delay, which we communicated to the Fixed Forex team:
Smart Contract Risk
Useful links:
The Fixed Forex audit by Peckshield thoroughly checked the ibToken for inconsistencies with the ERC20 standard and for coding best practices. It does not appear to have checked other contracts in the Fixed Forex protocol or verified the overall protocol logic consistently maintains its invariants.
The Iron Bank contracts themselves were audited by Trail-of-Bits as part of their CREAM V2 audit. We say more about the audits below.
Discussion and Conclusions
The Fixed Forex team has been quite upfront about the risk they impose on their users.
Does the asset meet minimum requirements?
Is it possible for a single entity to rug its users?
Yes, the Iron Bank 3-of-5 multisig can rug its users. The Keep3r 3-of-5 multisig cannot rug its users. Since the protocol founders are doxxed, a trust assumption might be sufficient to lessen this risk.
If the team vanishes, can the project continue?
Likely. Besides addition and removal of assets to the system, the Iron Bank (and Fixed Forex) smart contracts require only standard operational overhead, such as claiming and minting. This can be managed by a devops team familiar with the operational manual of the existing team, as long as they had access to the multisig.
Regular upgrades would likely still be needed to handle any uncovered bugs or to add features to remain competitive. Since the vast majority of the codebase is forked from Compound, a well-studied project, this should not pose a challenge when onboarding devs to handle the work.
Do audits reveal any concerning signs?
The 2-day effort by Trail-of-Bits to audit the entire CREAM V2 platform, including Iron Bank, was apparently seen by many as sufficient, due to the forked nature of the protocol. Nonetheless, the audit did flag two areas of concern:
lack of documentation around CREAM’s modifications
CREAM’s use of a custom oracle as a fallback for certain assets
Forked protocols like Iron Bank rely heavily on the credibility of the original codebase. However, hackers have taken advantage of deviations from the original protocol design. In the case of the last CREAM hack, it was precisely the use of their custom oracle, highlighted as problematic by Trail-of-Bits, that led to the $130M loss.
The Compound protocol is precisely the kind of DeFi platform that should require independent auditing as part of best practices, no matter how stellar the dev team, due to the high level of complexity. That a top-notch auditor spending multiple days on a fork felt uncomfortable about CREAM’s modifications being undocumented should not be surprising. Anyone interested in conducting proper due diligence on such a system would be concerned about this lack of clarity.
In particular, Iron Bank’s custom oracle is still undocumented, although it is still in use:
Iron Bank’s PriceOracleProxyfalls back to an oracle deployed by CREAM as the last option.
Iron Bank’s custom oracle has prices set manually for certain assets. This usage is not explained in their documentation. Since Fixed Forex relies completely on Iron Bank’s oracle system to properly assess value, ibTokens are potentially affected.
In addition, it’s unclear what security loopholes or economic attack vectors may exist around the addition of a credit limit to the Compound protocol, as the audit is silent there.The Fixed Forex audit is possibly even more problematic, as noted by its own creator:
In fact, if I saw an audit like [for Fixed Forex], where a team said they are “audited” and all they did was audit their ERC20, I would be even more cautious.
— Andre Cronje
Summary:
Much of the security guarantees of the Fixed Forex protocol rely upon Iron Bank security:
freshly minted ibTokens can enter circulation only by being deposited into cyTokens in Iron Bank
ibToken peg is maintained by Iron Bank’s liquidation mechanics
Given this heavy dependence of the Fixed Forex code upon the Iron Bank platform, we have lingering concerns over the lack of complete auditing. While the Fixed Forex mechanism looks like a straightforward addition to the Iron Bank protocol, its audit was limited to a check of the ERC20-properties of the ibToken. It would be undoubtedly beneficial for adoption to have a systematic audit done of the entire system.
Having said that, we don’t see any immediate rugpull threat from Fixed Forex itself; the Keep3r multisig which manages Fixed Forex has very limited power once an ibToken is deployed. The Iron Bank multisig has much more capability to rugpull but that can be considered out-of-scope.
The pertinent question is whether incentivizing ibToken pools in Curve is worth it. The volume across ibToken pools is exceedingly low, effectively zero in many cases. Although the Fixed Forex technology is innovative, veCRV holders are not likely to benefit tangibly in the short term.
Other than veCRV fees or risks to LPs, how does this affect the DAO? While overall volume is low, one may believe that decentralized forex liquidity should be improved as a public good. At the same time, the DAO will suffer reputational risk if such a large swathe of pools on the Curve platform were to de-peg.
Is the tradeoff worth it? Only the DAO can decide. We hope we’ve laid out sufficiently detailed information, including the nature of Fixed Forex’s dependence upon the Iron Bank so that readers can assess the risks involved.
