Interview with B.Protocol Founder Yaron Velner
November 5, 2020
Ever since the Black Thursday price crash earlier this year, risks of cascading liquidations have loomed large over the DeFi space. B.Protocol helps address this through an innovative backstop incentive mechanism.
While this offers potential benefits for integrated lenders such as MakerDAO, B.Protocol’s launch this past week was partly overshadowed by concern with the vote to grant access to Maker’s oracle price feed.
B.Protocol’s founder, Yaron Velner, graciously took some time this week to answer questions about B.Protocol, the recent MakerDAO vote, and potential for future collaboration between projects.
Nate: What is B.Protocol, and how does it work in general?
Yaron: B.Protocol makes DeFi lending platforms more stable, by giving clearer and more quantifiable incentives to keepers, while shifting the miner’s extractable value (MEV) to the users, who in turn get more from their lending platform, while helping to secure it.
We went live with our first integration over MakerDAO a week ago, and so far MakerDAO Vaults with over 7k ETH in collateral were imported from MakerDAO to B.Protocol.
Users manage their imported MakerDAO Vault via B.Protocol smart contract interface, and as a result get the same terms they get in MakerDAO, and in addition get to share the liquidation proceeds and receive voting power in the next protocol upgrade.
Nate: How does B Protocol interface with MakerDAO, and what parts of the system are used? (eg Vaults, oracles, etc.)
Yaron: B.Protocol integrates in a permissionless way with the Vault system, and in order to allow the liquidators to fairly share the liquidation profits, we use MakerDAO’s OSM module, which determines the price of ETH/USD in the Vault system an hour ahead.
MakerDAO governance took the decision to make the OSM integration permissioned, maybe with a hope to monetize it at certain point, similar to Chainlink’s profit model.
Nate: What made you want to create B Protocol?
Yaron: Over $4B of DeFi funds crucially rely on proper liquidation (backstop) process. In the traditional finance world, such platforms form a professional *backstop*, meaning they give incentives to experienced algo-traders to be willing to commit to liquidations of certain amounts at time of market crisis.
In DeFi, the approach is to outsource this process to the public. This permissionless approach is very much aligned with the blockchain spirit, however it results in almost 0 incentives to build a real liquidation system that could handle large amounts. Moreover, any attempt to give such incentive, in the form of a premium on the liquidation price, ends up by moving a lot of value to the miners, who enjoy high gas prices, because of the competition of who will liquidate first (for the easy liquidations, where you could just arbitrage on uniswap).
This results in events like Black Thursday, where the liquidation process failed, but on a more daily basis it forces DeFi platforms to ask for very high collateral factors. E.g., in MakerDAI you must have $150 collateral for every $100 you borrow, while in Bitmex you can have only $101 deposit for $100 borrowed. As a result Bitmex gives you the option to go x100 long on ETH price, while MakerDAO only allows x3 leverage.
In order for DeFi platforms to offer such terms, a real backstop is needed.
Nate: Borrowed tokens were used to vote on recent MKR executive. Can you describe how that process worked? E.g. sequence of borrows and transactions
Yaron: On a technical level, first ETH was borrowed from dYdX as a flash loan (as they offer around $20M ETH inventory, and have 0 fees on flashloans). Then this ETH was deposited on Aave and MKR was borrowed (in a normal process with almost 0 fees, not via flashloan that has almost 0.1% fee). Then the MKR was “locked” in the MakerDAO vote contract, a voting power was given, and the vote was casted. At this point a call for the vote execution was made. Then the “locked” MKR was freed, was returned to Aave, and the ETH was withdrawn from there and was returned to dYdX. All in a single transaction.
Nate: Why did B Protocol participate with borrowed votes?
Yaron: Integrating with the MakerDAO system, we had to dive very deep into the code. Initially for the liquidation process, and then when our proposal went to a vote we got curious on how the voting process works.
We quickly realized that it is flash-loans-friendly. Knowing the MakerDAO team and the few months discussions in the ecosystem, we were pretty sure that they are aware of this feature, and (wrongly) speculated it is just something they are willing to tolerate.
We decided to showcase it so it could initiate some technical discussion, and as a byproduct, would also push forward the approval of the proposal.
The vote was executed from the same account that the B.Protocol smart contracts were deployed from, and we had no intent to hide our actions.
What we failed to realize is that such an attack could have been made on that day also for malicious purposes. And as a result the MakerDAO foundation had to take urgent measures.
We apologize for making MakerDAO’s team work under stress, and for not making a more responsible disclosure.
Nate: MakerDAO’s monthly governance cycle could have delayed the B Protocol vote if not passed by Monday 10/26 (due to the monthly MIPs executive vote beginning that day). Were you concerned about this? How would delay in oracle whitelisting have impacted your launch?
Yaron: MakerDAO votes are not yes/no, and MKR holders can only vote in favour of a proposal, and can also vote in favour of multiple votes. The proposal with the current biggest number of votes is called the hat, and it can be executed.
To the best of our knowledge, no executive vote in MakerDAO was ever rejected, but maybe I am wrong. Moreover, introducing a new proposal would likely bring more attention to the fact that there is a pending proposal that needs to be voted on.
That said, I only became aware of MakerDAO voting mechanism last week, and I might be wrong in evaluating how things would have gone through.
A delay in the approval would have delayed our launch, which was already in 2 weeks delay because of the long whitelisting process. But everyone we have consulted with from within the MakerDAO teams, told us that these votes are always passed eventually.
Nate: If MakerDAO experienced malicious governance action, what impact could this have on B Protocol and its users?
Yaron: Users who manage their MakerDAO Vaults via B.Protocol are essentially also MakerDAO users. Hence, if MakerDAO experiences malicious action that would result in loss of funds, it would also affect B.Protocol.
B.Protocol is almost fully aligned with the protocol it integrates with, and aims to make them more stable. Any attack on them could also harm our users. As B.Protocol does not have any control over user funds, they security of user deposits fully relies on the security of MakerDAO.
Nate: How do B Protocol rating scores work?
Yaron: B.Protocol allows liquidators to share their proceeds with the users. This is done according to the user rating score, which is determined according to how much the user interacts with the protocol.
In the MakerDAO integration, the correct way to measure it is according to the amount of DAI a user generates over time. Specifically, a user with 1000 DAI debt, will get around 1 new point every day.
In the first month, users accumulation rate is x2 (we have launched on Oct 27th so there is still time for users to leverage on/enjoy from this bonus/subsidy). After 6 months the proceeds are distributed according to the score, and the users also get to vote on a protocol upgrade with their score.
The score is not an ERC20, and not transferable. Just a record that is kept on the blockchain.
Nate: Other than compliance, do you see any benefits in making rating scores non-transferable?
Yaron: B.Protocol's best interest is to have organic MakerDAO users. As there is no initial liquidity to bootstrap, the platform does not benefit at all from users that never intended to use MakerDAO. Those users will not help us make MakerDAO safer, and lack of organic activity will result in 0 profit for the backstop. Hence our approach is to give MakerDAO users something extra on what they originally get, but without making it quantifiable, so there are no incentives for artificial behavior.
Nate: How will governance of B Protocol work after the 6 month launch period?
Yaron: After 6 months the users could vote to upgrade the proceed sharing mechanism. This mechanism determines how liquidators (backstop) are selected, their commitments, and how their proceeds are shared.
It also decides what the new score mechanism will be, and in particular how to treat the already accumulated score.
It does not determine how user deposits are handled, which will remain under their full custody, and subject to the rules of the underlying lending platform.
Nate: How do you see the B Protocol community engaging with governance of underlying protocols over time? Are there opportunities for collaboration?
Yaron: B.Protocol's long term goal is to help make the underlying protocol more stable, and the more of the underlying protocol deposits are managed via B.Protocol the more secure it gets.
The underlying protocol community will have a strong interest in setting up stricter conditions for the backstop, which will in turn make it more stable. The B.Protocol community incentive is to make the underlying protocol more friendly to keepers, and thus increase their proceeds.
It will be interesting to see the interactions between the two communities, and if the underlying protocols will try at a certain point to take over the B.Protocol governance.
About B.Protocol
B.Protocol makes lending platforms more secure by incentivizing liquidity providers (keepers) to commit on liquidation of under collateralized loans and shift the miners extracted profits back to the users of the platform. B.Protocol was founded by Yaron Velner, who was previously Kyber Network’s CTO and a co-designer of the WBTC protocol.
For more information, please visit B.Protocol’s website, Twitter, Discord, Medium, GitHub.