Tribe Staking
Last updated
Last updated
Imua is the universal protocol for shared security allowing AVSs to gain additional security by leasing re/staked tokens. For AVSs with their own native tokens for staking, they have to pay additional rewards to borrow the external tokens for enhanced security. Imua introduces "Tribe Staking", a novel concept that enables AVSs to form a collective tribe. Within this tribe, AVSs pool the security of each member’s natively staked tokens, which then serves to protect every participating AVS.
Let’s assume there’s an expected annual return for staked tokens, such as 3%. A yield lower than this percentage will likely cause re/stakers to exit, and eventually, the yield for the remaining re/stakers would approach this 3%. This percentage is then treated as the expected cost for shared security. For staked tokens, the expected yield might be lower, given that the token already accrues yield from the original staking instrument and re/staking offers an additional yield on top of that existing yield.
Nonetheless, to attract additional re/staked tokens from external re/stakers, an AVS must pay additional rewards to compensate for the increased security cost. For instance, if an AVS with a re/staked security budget of $50 million wishes to increase its re/staked security budget to $250 million for enhanced security, it would need to substantially boost its rewards to lure in the additional re/staking tokens. Expecting an AVS to suddenly have extra capital to purchase a significantly elevated level of security seems unrealistic unless it resorts to inflating its reward tokens significantly.
In light of this practical challenge with re/staking, Imua introduces Tribe Staking. Tribe Staking allows multiple AVSs to form a tribe and benefit from the combined shared security of all members without incurring substantially increased costs. For instance, in a tribe comprised of two AVSs, the native staking token from each AVS can be used for re/staking in the other AVS.
Consider a tribe formed of two actively validated services, AVS1 and AVS2, each having their respective native staking tokens, $AVS1 and $AVS2. An operator with $1 million $AVS1 already staked in AVS1 can simultaneously opt into AVS2, and the $1 million $AVS1 would be automatically restaked onto AVS2, and vice versa. This way, all tokens from the two AVSs can be used to provide security for each of the AVSs.
Operators staking for an AVS within tribe staking will likely eventually opt into all other AVSs in the same union due to competitive pressures. Those operators only staking in one AVS within the tribe won’t maximize their capital utilization, as the same token could be re/staked to another AVS, yielding additional rewards. Such operators will feel compelled to opt into all other AVSs when they observe other operators doing so and providing more rewards to their delegators. Ultimately, the market equilibrium should see all operators opting into every AVS within the same tribe, fully optimizing capital utilization and security for the AVSs.
Through tribe staking, the security of the AVSs grows as more AVSs join the tribe. This fosters a genuine “pooled security” effect where AVSs become more robust by supporting each other without having to pay for external security.
