Thanks ! The problem with it is that it cannot be done in a trustless way, we'd have to have someone or "something" like a fundation to manage it and it's a whole other ordeal, but that argument

Thank you !

Thank you ! I took a look, nice pictures !

Thank you !

Thank you !

Haha figma the bane of my existence

Very cool ! which app are you using ?

thank you ! Not confirmed yet but it's starting to look good

You can't do it the same way with voting power because the current voting power is not correlated with your hive power. someone at 50% voting power with 500 hp != someone with 50% vp at 1000hp I guess

Good question! Sadly no, storing that kind of fluctuation would cost way too much in space to be done in L1. But could be done via L2 in an external db that tracks all the transactions and calculates each

It's instant, the 5 days HP limitation is linked to duplicating voting power, which doesn't exists via RC (use all your voting power, delegate to someone else, use all your voting power again, undelegate,

Thanks !

This is really cool ! I just finished watching your talk. I'm curious, which skills did you have at 18 that made you win the startup weekend and how did you manage to convince the 35 year old engineer

Yeah it costs very little, but also this is where other accounts can set your slot for you, the account creator can change your slot 1 and your recovery partner can change your slot 2.

Oh yes definitely

it's tricky to do 2b because you can overdelegate so it's hard to tell if an incoming delegation is "better" than the existing ones. For instance I could delegate 1m rc to you but my pool is

what happens at 1 million users does rc costs per transaction get much more expensive in the RC system RC costs will skyrocket driving up demand for hive power. It's similar to ethereum gas(fees) basically.

You use your own first then the 3 slots in order? Yes The idea is that if you have rc you shouldn't pull from the pool, don't take from others when you have some yourself basicaly

Haha, thanks !

From first slot to the last. Order is account rc > slot 1 > slot 2 > slot 3 I think it's a good enough for a first implementation to see how it goes and then maybe experiment where it consumes