staking & voting design patterns
@Ilya @Luivatra @anon_real @mhs_sam @anon2020s @Cheese Enthusiast @scalahub and others, let's have focused chats aside of weekly ones maybe, we can have a chat on staking and voting solutions in Ergo and corresponding eUTXO design patterns . Please lemme know what do you think
13 Replies
I've never tried this thread functionality in discord. Does it make sense or something else?
I would bring in @Leif Erickson as well for the discussion
Guess it could work to keep the discussion focussed
One thing I am going back and forth on is making unstaking address based or token based. Fe. in ErgoProfitSharingDapp the staker gets a token they can used to unstake again, allowing them to move the token to another wallet without having to unstake->move funds to new wallet/address->restake, which is a nice system, my concern is just that with an increasing amount of dapps that might all use similar systems a users wallet is going to be stuffed with different tokens and nft's. I guess with dapp connectors/ergopay this can mostly be hidden away from the user
GitHub
ergopad/staking.md at staking-contracts · ergo-pad/ergopad
Contribute to ergo-pad/ergopad development by creating an account on GitHub.
Design document for staking setup for ErgoPad
I guess I can see the value of being able to move staked assets between wallets like that, but I really do wonder how necessary it is, especially if multiple dApps start implementing this method. Personally, I feel like users should be the ones who know what address stores their staked tokens and how to access that address.
I guess if dApp connectors are able to identify certain tokens for this type of purpose then it would streamline the process for users.
Haven't checked the ProfitSharingDapp code too closely yet though, so may need to look at it a bit closer before I can come to a full opinion about it.
Like in ergodex adding and removing liquidity, user doesnt have to care about LP tokens
I think having a token that represents your stake could make sense
But it's not necessary, no. On BSC that's not how it's done.
There's no LP token on ergodex?
The thing about a staking token is it also won't actually show what your stake is worth anyway, since the registers won't update with the staked value
Yes there is but the user doesnt have to know about it. They can jut interact with the lp through the site
Nice job!
Is it supposed that all transactions are created on the client? Or some kind of off-chain service like in ErgoDEX will be used?
I usually try to make it such that anyone can execute the transactions, but unlike with ergodex there is no incentive for the off-chain executor. Normally it will be an off-chain service at ErgoPad batching as much together as possible and executing it
but if we for whatever reason disappear it should be possible for anyone to run the system
Because we will batch transactions for distributing staking rewards which will have the following structure (Stake State, Emission, N * (Stake) => Stake State, Emission, N * (Stake)) I am keeping as much ergoscript out of the Stake contract and keep most of it in the Stake State. This way these singular boxes can be seen as includes or traits of the transaction and preventing unnecessary repeating of the same ergotree bytes.
Agree, a fallback option is needed and actually there is a fallback option also in ErgoDEX even in case all offchain operators disappear.
But in practice the performance will be very poor without serialization of txs working with some kind of shared state which is StakeState and Emission in your case
Ergo Community Forum
A more efficient UTXO voting
Let’s say we have a voting contract or a joint-spending contract similar to here. In this setting voters have some specific token that allows them to have a specific “voting power”. For example, if there are a total of 100 of token x and Alice owns 15 x then she has 15% of the entire voting power. We’d like to have an efficient way of voting. V...
has anyone read anon_real's proposal to allow UTXO voting that does not require a lockup of your tokens?
@Ilya I have also seen this proposed solution for off-chain voting on EVM. I'm not familiar with how your off-chain bots work on ergo, but maybe this can lead in the right direction for a similar clean solution:
The general idea is that when a new proposal is created in Ethereum, the Storage Root Hash becomes the census root for the voting process and anyone providing a storage merkle proof of an existing balance for an ERC20 token can cast a vote by sending the proof and a signature to a zkSnark rollup relayer which will compute a proof of the final results. The relayer collects the votes casted by users and verifies them and when a voting process is finished, calls the Voting Process smartcontract to perform the binding action