Token Hooks

Transcript

[Music] Hi everyone, my name is Anton Buukov. Uh I'm co-founder of 1 in and I'm here to show uh the newest newest DeFi primitive called uh token hooks. What is token hooks? It's actually dynamically expanding and changing functionality of any token. Uh there are many things tokenized onchain. uh including some projects like Dows also some uh like Dexes, AMMs, like lending protocols all those pools they have proper tokenizations and uh uh holders of those tokens they

could uh if if there if these tokens and tokenizations would be hook enabled this would let holders of those tokens to change behavior of their uh balances dynamically. So this means that uh if your token or any tokenization thing is uh hook enabled, this means that uh owners of this uh token can add own hooks. They could add uh some hooks approved by DAO or they could add permissionlessly any hooks. This this is something you could decide on your own when you use this kind of library. But basically if it's like permissionless environment users

can add any hooks they wish to change functionality of their token whenever their balances will be changing hooks will be notified about this and they can handle it in like any manner. So basically your your token have to be hook enabled. It's a extension of ERC20 called ERC20 hooks. Or if you already have something tokenized which is not hook enabled, you can build a wrapper. Just use ERC20 wrapper from standard open zeppelin library and make it hook enabled.

So then you can have arbitrary hooks deployed for your token like uh any I will show a few examples but I hope to see much more different examples of different hooks and yeah in this example uh holders can permissionlessly add any hooks they wish but yeah if you're building this system you can change this you can make only approved hooks or anything you want. Uh so what what's what's actually hooks adding to the token behavior? So how far you can change your behavior? So actually those hooks they can be developed

permissionlessly. So this means that even if I'm uh building some system which is tokenized and these tokens are hook enabled I can make it open in terms of anyone can develop any idea of hook they wish and owners of these tokens will be able to have this functionality also hooks they are risk-f free so it's actually like balance hooks they're like hooks on token balances and they can't prevent transfers, means, burns, whatever is usually happening to your token. Hooks are only getting notified, but they can't prevent this from happening. And yeah, users are free to

participate in multiple hooks. But amount of hooks, number of hooks should be limited. You you could not have infinite amount of hooks. Uh for some systems, if your system is uh for example lending protocol, you should make sure your users are still liquidatable. They should have limited number of uh hooks and limited gas uh spendings in those hooks. Uh so yeah there are two examples we built.

So originally we were trying to build all those two things separately but then we came up to this concept of hooks and realized that both of concept can be implemented as hooks and moreover if we would have it as hooks we can add any arbitrary logic later as a custom hook. So farming incentives hooks it's very similar to farming pool which was uh implemented in 2020. I w with my teammate were the guys who implemented the first farming pool for synthetics in 2020 and now we're like reimagining this idea with hooks because uh this would let

users have uh multiarming permissionless and it's also risk-f free any pool where you lock your LP tokens or anything else are not risk- free. You have to outdid those systems to make sure those pools will not steal your money or your tokens or they will not be locked forever or any other issue would not happen to you. When you are using hooks, you you can use any hooks without any audits and it's still safe. In worst case, hook will just ate a lot of gas when you will try shut it down from your balance turn uh to detach it from your balance. But yeah um in non it's not affecting your

balance in any way. They can steal or block your funds and uh delegation hook also we call delegating. So it's actually yeah you can uh have some balance there and you can delegate your balance to someone and this hook itself is also C20 which is read only and which is uh representing total delegated balance of entities. It's uh one of the cool features for onchain governance. We for example have delegation for votes in governance uh and we also have delegation for uh unicorn power for resolvers. So you could have multiple delegation destinations. uh this

approach is much more agile than any other ERC20 extension like ERC20 volts or any other similar because you have to inherit those extensions before deployment. You have to inherit it when you write the code of your token while hooks can be added much later at any stage. So it's dynamically extending any token functionality uh uh per user. So some users can install some hooks. So not you you are not enforcing this behavior for everyone.

And what is hook itself? Hook itself is just a smart contract with one single method update balances. It's getting notified about balance changes in a very similar way how internal update method of open Zeppelin ERC20 implementation looks like. So yeah, it's very similar. We just added uh base hook implementation to make sure you will not forget any important checks like who is the caller. The color of this method should be always the token. It is this hook is attached to. So we just inherit from base implementation which perform this uh basic checks. So it's just a little bit of comfort here.

So yeah, that's basically the whole presentation. Uh I I can spend more time on this slide probably uh reexplaining the concept. So in the past whenever you want to incentivize someone to participate in your protocol, you have to deploy some farming pools and users have to uh trust those pools that those pools will not steal or block their funds. uh or whatever else bad could happen. With this new approach, you could make any tokenized thing of your protocol. If it's like LP token or DEP token or collateral token or like whatever you're

building or it could be DAO token or it could be a stake DAO token. We also use this system for staked 1 in which we call unicorn power token. So it's non- transferable but it still works with all those primitives because of the proper tokenization where balances are not changing on the flight. Yeah. So this thing is only compatible with tokens which balances are not changing with time uh via formula depending on time. So all balance changes should happen transaction wise. So yeah, imagine just imagine if balancer for example would just inherit this functionality

20 hooks for their pools. This would let uh Dows to coincentivize those pools. Just imagine three four different Dows could set up hooks with incentives for some uh for for the for the same pool for example. And this means that participants of this pool can just plug into those hooks like three four hooks and get incentives from all of them and they it's completely risk-free for them. Uh development of those hooks is permissionless which is also cool. Yeah. And you could have like a permissionless risk-free multiarmming.

This sounds like a uh economical craziness. Uh so yeah, we built only two of them. We unified our approach to build it uh in unified way. So originally it was two different things which were not owning tokens. Uh it was farming and delegating. And we found a way to unify this concept via token hooks. And I personally hope to see much more different hooks implementations. Maybe we will see them on hackathon or somewhere else in production. It's also very cool to build systems out of these hooks for any kind of governance

systems. So for example, we could have uh snapshot hook which will make snapshots of ERC20 balances. For those users who won't participate in this, they will install this hook and whenever for example uh administrator or operator of this hook would decide that it's required to make snapshot, they will make transaction and this hook will uh remember all the balances uh before this event and it could represent it via external ERC20 readonly smart contract.

So your governance system could later work with this read only ERC20 implementation or something like this. In general, this system is much more agile as than any C20 extension because you can change how things works after your token is being dep deployed. So that's actually it. Thank you. Uh any questions? Yeah, for now. Uh so the question was who is paying for those instruction for being executed? So yeah, who is changing

the balances is actually paying for hooks notification. For example, if you have some hooks A and B and I have some hooks B and C. If we are changing our balances, for example, you transfer some tokens to me or I am transferring some tokens to you. We will notify hooks. For example, we will notify hook A that your balance was decreased. But you will it this hook will not see my balance for example or my address because I'm out of this hook. I'm only participating in B and C. I'm not participating in hook A.

So yeah uh whoever will change balances will pay for this but number of plugins connected to one um address and amount of gas which they could spend should be limited and this should be defined on deployment stage. Whenever you uh inherit from this ERC20 hooks, you have to pass uh arguments how many hooks should be allowed per address and what's their gas limit. So using this system you could for example have incentives on depth tokens.

If you're building like a lending protocol and your depths are properly tokenized, their balances are not changing on the fly. For example, this could be uh achieved with a compound like approach where balances are not changing, price is changing uh of asset to underlying asset. Uh so yeah, you could have incentives for depths because obviously you can't put your depth into the pool without collateral. It should not work as as it was implemented in the past uh implementations of farmings. But this one would work for you. If you have anything which is tokenized properly,

you could use hooks with this. More questions. Yeah, I actually have two questions for you. The first one is what happen if a hooks revert? Will that prevent the transfer from happening? And the second one is are you worried about the possibly re-entrancey risks if the hooks is used in the case of let's say 4626 or something like that? Yeah, a great question actually. Yeah, originally when we came up to this idea, we discovered that uh those who execute transaction or execute this call can uh lower gas limit to make those hooks fail due to uh low gas for example. And yeah, we wanted those hooks to be uh as less invasive as possible. This uh that's why

originally we implemented it like we check that we are passing 200,000 of gas into hook and make sure it will if it will fail it's not due to low gas. So it's fine it's fine for token to transfer while hook is failing. I mean hooks can fail if their logic is uh written in with some bugs or something or or or if it's intentional it will spend your guess but it will not prevent your uh token logic because this could be mint of token shares burn of token shares transfer or liquidation or like whatever is your protocol about and uh hooks should be non-invasive. Now it's uh using optimistic approach but still

safe. We're executing we're notifying hook and if it's not failing that's okay. If it is failing we're checking that we passed at least 200,000 gas inside to make sure it was not failing due to low gas. And yeah it's like optimistic but yeah it's protected. And in terms of uh uh attacks uh the thing is that it's notifying after balance changes as it should be. So yeah if your contracts and protocols are following uh say notations checks effects interactions you should not have any problems here because yeah it's also built the same way. It's also checks and

effects and then do any interactions separately. So yeah, that's actually the great way to avoid re-entry attacks. Not to put re-entry guards everywhere on every method of your protocol. You can just write every method uh using these checks effects interactions notations. So perform checks and state changes and then only after that perform external calls like transfer froms to any tokens are like whatever external calls you are willing to perform. If you will have code written like that for all your protocol or many protocols even if someone will be able to perform

re-entrance attack it will not actually attack you at all. It will work a strange way but it will be safe for your protocol. So yeah follow checks effects interactions pattern please. Uh more questions uh how do you see this uh interacting with my own token position in the contract like for example let's say that I want to reset the allowance to zero after a transaction has happened. For example, I've given uh an allowance to a desk to spend up to my max slippage, but the actual allowance consumed is obviously slightly less than that and I just want to give it a one pass allowance. So, I want the hook to affect my position. Again, how do you see that happening? Uh hooks are actually balance

hooks. So, they're not anyhow interacting with your allowances. So, whenever your balance is changing, it's notifying hooks associated with the accounts participating in this change. So, there are like three ways to change balances in ERC20 implementation from open zap for example that's like the most popular one you can transfer balance you could mint balance or burn balance so whatever you are touching it will notify those balance hooks and yeah regarding approvals yeah it's not approved hooks at all but during a transfer an approval is consumed somebody on my yeah yeah if you're have some hooks connected to your

balance. If someone is changing your balance on your behalf, yeah, it doesn't matter. They would execute and they would also pay for gas. For example, if you would have some farming incentives in some lending protocol for your collateral, for your deps, someone who would liquidate you, they would pay all the gas for all those hooks execution. That's true. More questions. Do you have any other governance ideas?

Uh yeah, I I said about uh snapshots hook. I think it makes sense to build it because yeah I I found some useful implementations for sure in your C20 extensions of open zeppelin and some other libraries but for me it seems that uh yeah it's too strict if you need to include this logic on compilation time when you write your code for your protocol it's one thing but if it's something what you could add later like one year later you want to have incentives or you want to have governance to voting or like whatever other functionality you can wish. So yeah, hooks help with that actually.

More questions. So it should be obvious. Yeah. Not really a question, more a comment. You should write an ERC that specifies everything you just did and mentioned. Yeah, I agree. I agree. We should push this as ERC standard and we should probably try to push it to uh open Zeppelin library as a separate extension with hooks as a separate folder because they have folder for extensions. We could put ERC20 hooks there. They actually audited this thing. So yeah, I agree.

[Applause] Thank you. [Music]