Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 12/01/2020 in all areas

  1. This proposal is focused on expanding the Elrond staking economy. Please read the information below carefully in preparation for our feedback sessions. The changes we are proposing are meant to open a new era of growth for Elrond, specifically increasing the token distribution and decentralization, strengthening the security of the network, and enabling sustainable business models around staking-as-a-service providers. In short, by enabling more eGold to be staked, more people and validators will participate, more tokens will be locked, security will improve, potentially increasing the value of the locked assets. A secure environment will give confidence to more businesses to start building on Elrond, increasing the demand of eGold, in a perpetual virtuous circle. The following changes are proposed: Increasing the staking cap: increasing the maximum number of Validator nodes Increasing the amount of stake per node, and enabling compounding feature Enabling open delegation via system smart contracts 1. Increasing the staking cap There are 2,169 Validator nodes active in the Elrond network, each with a 2,500 eGold stake, totalling 5,422,500 eGold staked. This is 37.49% of the circulating supply. The Delegation Queue enabled additional participants to engage with staking and increase the amount of eGold locked to more than 8 million, or 55% of the circulating supply. We therefore propose to increase this staking cap by a) increasing the number of Validators and b) adding a compounding rewards function that enables each validator to increase the amount staked per node. Increasing the number of Validator nodes We propose increasing the maximum number of Validator nodes from 2,169 currently to 3,200. The number of shards will remain the same: 3 shards and one metachain. Also the number of eligible nodes per epoch remains at 400. What is changing is the number of nodes per shard that are not eligible but are on the shard waiting list that will increase from a maximum of 142 to 400 (not to be confused with the queue from Phase 1). The minimum number of nodes on the waiting list will be 80, instead of 142 as it used to be, so the minimum number of nodes will also change from 2169 to 1920. With 2,500 eGold staked per node, the total amount of eGold staked will be exactly 8,000,000 eGold, on par with the current locked amount. The change in the maximum number of nodes is more complex and will enable a variable number of active nodes on the Elrond network: 1920 minimum, 3200 maximum. The actual number will be driven by the market demand for eGold staking. Since the amount of rewards is fixed per year (2,16 Mil eGold in the first year) the change in number of nodes will directly affect the rewards earned by validators and delegators as well. Please find below the rewards for Validators & Delegators in the min & max scenarios: Validator Min. nodes: 1920 Current: 2169 Max. nodes: 3200 APR % 40.65% 36% 24.40% Delegator Min. nodes: 1920 Current: 2169 Max. nodes: 3200 APR % 32.75% 29% 19.65% What the limits mean: Minimum 1920 Validators: unStake is not possible when only 1920 Validators are in the network. Elrond Foundational nodes will be added in this (unlikely) scenario, to enable community validators flexibility Maximum 3200 Validators: creating a new Validator is not possible when 3,200 Validators are already staked. Elrond Foundational nodes will be progressively removed in this scenario, to allow more community nodes Increasing the amount of stake per node Another important part of this proposal is enabling people to stake an amount larger than 2500 eGold per node. The minimum value will remain 2,500 eGold, but the maximum value will be uncapped. Validators will be able to add more stake to their nodes and therefore earn more. The amount of eGold staked per Validator does not influence its chances of being selected as block proposer or consensus member, but rewards will be proportional to that amount. A diminishing returns mechanism will be applied, so it will be more profitable to i.e. run 2 nodes with 2,500 eGold each, instead of 1 node with 5,000 eGold. Please see the rewards system details taking into consideration top-up stake at the end of this post in the Appendix. Some simulation data can be found below. This is based on year 1 inflation (10.84%), considering 100% hit rate (no missed blocks) and the proposed values in Appendix. Scenario for 1920 Validator nodes in the network (minimum) Avg stake per node 2,500.25 eGLD 3,000 eGLD 4,000 eGLD 5,000 eGLD Total stake on the network 4,800,480 eGLD 5,760,000 eGLD 7,680,000 eGLD 9,600,000 eGLD APR base stake 40.67% 38.65% 35.43% 33.47% APR top-up stake 10.36% 10.12% 8.73% 7.20% Average APR per node 40.66% 33.89% 25.41% 20.33% Scenario for 2169 Validator nodes in the network (current) Avg stake per node 2,500.25 eGLD 3,000 eGLD 4,000 eGLD 5,000 eGLD Total stake on the network 5,423,042.25 eGLD 6,507,000 eGLD 8,676,000 eGLD 10,084,500 eGLD APR base stake 36.02% 33.99% 30.78% 28.81% APR top-up stake 10.36% 10.12% 8.73% 7.20% Average APR per node 36.01% 30.01% 22.51% 18.00% Scenario for 3200 Validator nodes in the network (maximum) Avg stake per node 2,500.25 eGLD 3,000 eGLD 4,000 eGLD 5,000 eGLD Total stake on the network 8,000,800 eGLD 9,600,000 eGLD 12,800,000 eGLD 16,000,000 eGLD Average APR base stake 24.40% 22.38% 19.16% 17.20% APR top-up stake 10.36% 10.12% 8.73% 7.20% Average APR per node 24.39% 20.33% 15.25% 12.20% This will be a powerful mechanism for Validators to compound their rewards on a daily basis, while further increasing the value of assets locked for staking and therefore the network security, with all the benefits detailed above. Increasing the stake of a node will be possible using eGold from any source, not just Validator rewards. Enabling open delegation Presently, everyone delegating eGold is doing so towards the Elrond Foundational Nodes. This interim solution was instrumental to securely bootstrap the Elrond blockchain. Our common goal is to decentralize the network and decrease the number of Elrond Foundational Nodes, in favor of more community nodes. Open delegation enables us to achieve that. Open delegation will be enabled at protocol level through system smart contracts. This enables Staking Providers to build a great business model around their services, creating very secure staking products without the need to invest in smart contracts programming resources such as developers and audits. Staking Providers will be able to tailor their staking terms according to the interests of their respective customer base. Staking through regular (non-system) smart contracts will be possible as well, and we look forward to these options gaining in popularity and complementing the system smart contracts with innovative staking products. The Delegation System Smart Contracts will enable Staking Providers to register their nodes and define parameters related to their individual staking products, such as the maximum amounts to be delegated, and service fees. End users looking to delegate their eGold will be able to select their preferred Staking Provider and delegate their eGold towards them. Most importantly, every staking as a service provider will be able to start marketing Elrond, offering compelling and differentiated services to the Elrond investors and community, increasing their eGold amount delegated and growing their revenue, while at the same time significantly increasing the Elrond network exposure and overall security. The specific details about the Delegation System Smart Contracts can be found here: https://github.com/ElrondNetwork/elrond-specs/blob/main/sc-delegation-specs.md Outlook on Phase 4 The Phase 4 of the Elrond Staking mechanism will cover a soft-auction mechanism, but this will only come into play at a later stage, once the maximum number of 3,200 Validators is reached and most of them staked more than 2,500 eGold. A separate post will detail the mechanism and begin community discussion once components are ready. Appendix A copy of the proposal and the detailed formula for calculating the top-up rewards can be found in this document.
    4 points
  2. I'm not part of the team, but just my humble opinion. Need to recap a bit the history to understand the present. This blockchain has less than 7 months from the mainnet and is already in top 20 - 25 by marketcap. Inevitably the node price increased a lot. From technical perspective the project is rock solid (and this is reflected in the eGLD price as well), the validators community is also very strong, the same team with long term vision. You cannot change the rules during the game and need to let some time to digest the new economic environment and the current validators expectations. Growing organically is the key in a fully distributed environment if want to keep both security and safety. In this point, is very risky to change the node min amount, there are lot of validators which already made the setup for phase 3 with all the economic context in place. Starting with phase 4, the auction mechanism will be enabled, let's see what's happening after the voting. Also, from scalability point of view and taking in consideration the current overloading, 3 shards with one metachain with 3200 nodes is more than enough for running any kind of project. Elrond is one of the most distributed PoS project from the community from both the nodes distribution and from hw requirements perspectives. I understand your point, but need to wait at least to phase 4 or when the network will naturally request more nodes.
    4 points
  3. Hi Milan, 1. If you run a staking service (accept delegations) there is a delegation manager contract that allows you to create your own delegation contract with your preferred configuration (service fee, delegation cap, etc). For this you need to come with 1250 eGLD yourself, which will be the first delegated amount (your own delegation) and is required in order to keep your delegation contract active. Everything else can come from other delegators. 2. Yes the node will be deactivated by the protocol while the staked amount is below the minimum required. If in the meantime there is one delegation that causes the staked amount to exceed the min required, then the node will be re-activated. 3. Slashing is currently not enabled, but the intention is to have less impact on delegators (could be 0) and more impact on provider. This is still TBD and there will be a proposal before we activate the feature so we can discuss and reach the best decision. At point 3 could you explain which lock you were talking about? Is this about the requested features for delegation SC for min lock period, where in exchange for longer lock time the service provider could have lower fees? The way that will be designed is that delegators have a guarantee for lower service fees while they abide by the agreed lockup. The funds can be withdrawn any time nevertheless, with some penalties on the rewards for the last period if there is a breach of the agreed lockup. One thing we are trying to implement here is correctly defining the constraints for both parties, delegators and service providers. So if we have a breach of contract from the delegator, its rewards for the the last period have a penalty, while on the other side, if for example the service provider gets slashed, or changes anything with the agreed delegation contract parameters that negatively affects the delegation APR, then delegators can withdraw without any penalties.
    3 points
  4. I checked today and I can finally see after almost 3 days my egld in my Maiar wallet. 🙂 problem solved!
    2 points
  5. Hello ! Of course, this can be automated. You have to also get the results of the transaction. Speaking of API endpoint, this is the URL you're interested in: https://devnet-gateway.elrond.com/transaction/5c8a46bedf88048768da6de865b296e74604c4badc88ea5e1a8295e7c5e20849?withResults=true In erdjs, you can use ProxyProvider -> getTransaction() method that also receives a withResults boolean param, that has to be set to true.
    2 points
  6. The article looks like a promoting article for radix, so it should be viewed from that perspective. In regards to the numbers mentioned in the article for radix, I don't see in the article which kind of setup they ran, in order to make a comparison with elrond capabilities. Elrond has reached 263k TPS in a real world scenario, where the nodes forming the network were ran together with the community, with a good geographical dispersion, 50 shards, low end machines (some used the cheapest contabo machines, others used personal laptops, etc). The elrond binary used in this benchmark was the one we were testing in preparation for the mainnet launch, so all verifications (signatures, hashes, state, etc) were in place, with real operations and most transactions being cross shard. In the same real world scenario if we would have increased the number of shards to 200, elrond would have also gone above 1 million TPS, more so with the latest protocol improvements. Regarding the concern about breaking atomic composability, there are different models that enable defi applications to work well with the elrond asynchronous execution model. In addition to this, we have done an in depth analysis that ended with an internal proposal that would also enable atomic composability for smart contracts in Elrond that would also fit with the current architecture. This would allow smart contracts to specify the need to be executed atomically and the protocol would be able to ensure the execution of the Smart Contract calls as if all smart contracts "touched" by one call were in the same shard. In regards to the atomic composability for smart contracts in radix, I have read the paper and am assuming they do not have this working currently with nodes that are holding different subsets of shards. There are many limitations and drawbacks with their proposal that would only become visible in this scenario (which is actually the scenario where their sharding would start working, otherwise it is like running a single chain and no sharding).
    2 points
  7. I'm Lucian from Romania. I've started using crypto back in 2014 by selling my online services and receiving crypto payments. In January this year I bought my first share of eGLD. Since then I'm always adding some, every 1-2 weeks! I'm currently staking it and so far I love it. There is no crypto I've seen with this level of implication form it's creators. It haven't even been 1 YEAR yet, and it looks like it's already a standalone network. I love that it's not based on another cryptos/blockchains. It features every part of the spectre to make it a global go-to for everything. from the blockchain to the wallet, to the exchange, launchpad and everything, it's the best all-in-one. I trust Elrond and the Elrond team and I respect them. That's why all my other investments are now in eGLD. It's worth it for sure. See you here in the next years! And thanks to the team for making this network a reality!
    2 points
  8. April 7 - the first rewards from the new Validators On April 7 ~14:30 UTC at epoch 251, these nodes distribute their rewards towards their stake owners, whether directly staked or delegated, in effect producing the first rewards for Staking Phase 3. Also at this date and time, the next 320 new nodes become Active Validators, and so on.
    2 points
  9. Hello, I am in a bit of a situation. I advanced in the waiting list so much in the last days that I can become an active delegator in about 24 hours if it keeps the same speed. Calculating the APRs in Phase 3, a Phase that I understand will last for about 5 months, please tell me what are your exact plans with the community nodes. Will you force delegators out at some point or will you wait for people to undelegate and shut down the nodes as that happens? Giving the little price cartel SPs created in the last few days, there is nothing attractive in going with them for Phase 3 instead of going with the Elrond nodes. At least you don`t change your fees from one day to another like they do and their fees come closer to yours. At this point for Phase 3 I am inclined to enter the active delegation to get a 29% APR for the next 3 weeks and 5 months of 17.XX% during Phase 3(if I got the duration of Phase 3 right)... than going with a SP and only get about 18.XX% APR for 5 months - (3200 nodes + 2 mil eGLD top-ups calculated). I know the focus is on decentralization and I wanted to go to a SP, but please give me, and others in my situation, some real reasons to go with the SP at this point. I asked some of the SP managers why should I choose SP instead of Elrond nodes in my situation and not even one gave me plausible reasons. I only get political answers and no real facts. If the decision should be a no brainer in favor of SPs, please tell me what details I am missing at this point. Thank you!
    2 points
  10. Hi Emi, Thanks for the feedback! The team already pushed a work-around and tomorrow will be pushed the official fix. I tried from my Mac/Safari and it's working as expected now. Best regards, Marius P.S.: Kindly please let's keep English using on this forum
    2 points
  11. Hi Marius, The removal of Elrond foundation nodes is not yet in discussion for the phase 3 release, this will be further down the line and will be announced beforehand. But just for the sake of discussion, the mechanism should be fairly simple, one option (which in my opinion would also be elegant) would be to keep the extra stake from the removed keys(nodes) as TopUp stake on the remaining nodes. This will indeed cause the return per staked token to decrease on average a bit, since the topUp stake APR is always below the base stake APR, but will also allow SaaS providers to become a more competitive alternative the more nodes are removed. This mechanism will make the migration process from elrond foundation nodes to SaaS more organic, so if delegators see a better option out there with some SaaS they will migrate. For your other questions: 1. It doesn't really matter which keys are unregistered. 2. Only delegators themselves can move their funds to other staking partners if they see a better option, and if they move or not depends probably on the advantages offered by the staking partners, but as explained above, since the APR will decrease a bit by unregistering elrond nodes, this will make the SaaS options look more competitive. 3. There will be no specific delegator greatly affected, this affects all delegators by a small degree, but this is already to be expected with the V2 proposal. Until keys are unregistered from the elrond foundation nodes, the APR for the elrond foundation nodes will be the highest possible (fees aside), so up to a certain number of unregistered keys keeping the funds delegated to elrond foundation nodes will still be one of the better options, out there, as long as the ratio of (topUp stake)/(base stake) for elrond foundation nodes is better than the same ratio for SaaS providers (again not considering fees). As soon as this ratio falls below what staking partners have, there will be an incentive to move. Hope this clarifies a few things, this is not yet decided to be the way to go, but I think it is one of the better options. If anyone has other ideas we can discuss.
    2 points
  12. Hi folks! I have some questions please. My understanding is that (soon) starting with the phase 3, the max no of validators will be increased up to 3200. Also, some of the Elround Foundation nodes will be removed letting some space for some external nodes. So far so good. My questions: 1. How are selected the nodes to be removed? Just random? 2. What's happening exactly with the tokens delegated to those Elround Foundation nodes? Will be moved transparently to some staking partners? 3. The affected delegators will be announced and can decide for themselves? Thank you, Marius
    2 points
  13. Hi, I tried to harvest my Mex rewards from EGLD-MEX farm on maiar exchange. I confirm transaction in my Elrond web wallet. When I come back to my browser on maiar echange, transaction is said to be « rejected by user ». thanks for your help
    1 point
  14. Hi How can we track how many fees we have accumulated without withdrawing? Or how do we know how many fees we have accumulated without withdrawing?
    1 point
  15. Hi Fabien, please contact support team on help.elrond.com (bottom right corner there's a button for chatting with support - pass over the chat bot questions, and then give the support team the info so they can check (your erd1..... address, etc) )
    1 point
  16. I solved in the meantime, but now i get another error at build: INFO:myprocess:Successful run. Output: rustc 1.58.0-nightly (c9c4b5d72 2021-11-17) error: failed to get `elrond-wasm` as a dependency of package `adder-meta v0.0.0 (/Users/pslr/Desktop/Elrond/crowdfunding/meta)` Caused by: failed to load source for dependency `elrond-wasm` Caused by: Unable to update /Users/pslr/elrond-wasm Caused by: failed to read `/Users/pslr/elrond-wasm/Cargo.toml` Caused by: No such file or directory (os error 2) CRITICAL:cli:Build error: error code = 101, see output. pslr@Adis-MacBook-Air Elrond %
    1 point
  17. Good day Adrian! Thanks! I did sort of figure that these mentions were less a case of bugs and more just a case of known issues & features being in development. Looking forward to this Year in Elrond and has been an amazing ride so far in 2020, thanks all for this wunder blockchain, certainly is a fantastic technology. I've been inspired to put on the developer hat now, and working on building some great things!
    1 point
  18. Hello, for the moment you can not add custom metadata via devnet web wallet, we will add this functionality in the future. You can add custom metadata if you create the transaction by yourself and add to the attributes field the desired attributes. The attributes field should follow the format attribute_name:attribute_value;attribute_name:attribute_value. For more information you can look here (https://docs.elrond.com/developers/nft-tokens/#nftsft-fields)
    1 point
  19. Hi! I came across this while playing around with NFTs on the devnet. So it seems that the retrieved NFT object in the API has a wrong name... Here's how to reproduce: Create a new NFT Collection. I already created one, here's the API Request to GET the new collection.: Create a new NFT in this collection. Send the transaction. Then GET the NFT's via API: Notice how we set the name as "TheRealNFTName" in the creation step. As you can see here. The name of the NFT is actually the name of the collection, not of the NFT itself. The wallet returns the same value (probably because of using the API ) and so does ElrondScan. Most probably the API Method to GET NFTs (and GET NFT/{identifier} as it seems to have the same behaviour) actually set the collection name to the final object that is sent as a result. Either that or the Create Method registers the collection name as the NFT name instead. Or is this just expected behaviour? How do I retrieve the actual NFT name then?
    1 point
  20. https://github.com/ElrondNetwork/elrond-sdk-erdjs/blob/bdec7b5fb1335dba3311d721681f35a16f1f4f5a/src/proxyProvider.ts#L102 if you pass to sync() the devnet provider ( chooseProvider("elrond-devnet") ) the network config will be taken through a GET request from the devnet so chainID should end up as 'D'
    1 point
  21. Hi, The problem is easy to solve. On your Ledger, you must go to the settings and activate the "Contract data" option on "Yes". Normally you will be able to withdraw ;)
    1 point
  22. My bad, now it has appeared. It just seems to have taken a long time to appear (and not the same for every wallet).
    1 point
  23. That's not gas price, that is gas limit, don't change the gas price, as that is aleady the minimum. Approximately: 12mil -> 50000*0.000000001 + 11950000*0.00000000001 = 0.0001695 EGLD 7mil -> 50000*0.000000001 + 6950000*0.00000000001 = 0.0001195 EGLD 2mil -> 50000*0.000000001 + 1950000*0.00000000001 = 0.0000695 EGLD I say approximately, because each byte in the data field costs 1500*0.000000001 EGLD, and you have 19 bytes so extra 19*1500*0.000000001 = 0.0000285 EGLD for each of the above
    1 point
  24. For every transaction you need to pay a fee. The unstake/undelegate has a higher fee than normal payment transactions as it interacts with a smart contract. From the message it appears you do not have enough egld for the unstake transaction fee. If you have enough pending rewards, you can try claiming those first as the claim rewards transaction is cheaper. The undelegate transaction normally consumes less than 7mil gas, so you can also try to set manually instead of the default 12mil gas 7 mil and if you have enough balance for that it will probably be executed. The claim rewards normally consumes less than 2mil gas, so there you can also try to set manually instead of the default 6mil, 2mil gas. Otherwise if you can't do either, then you should get some egld to have for the fee (ask a friend ?)
    1 point
  25. HI folks, i wanted to start this thread as i suspect *many* involved with Elrond, especially node/staking-agency operators, may want to consider setting up an online safety deposit box. We each need to consider the HBAB event (lightly known as the Hit-By-A-Bus event). We joke about it in software/crypto but it is a real concern, especially if we run nodes. I want to setup up a safe methodology to allow a trusted family member or colleague to be act to access my crypto assets and methodology in the event of my untimely death. I see few interest and concrete avenues for this, especially in Canada, that require the presence of a death certificate to access my data. Any and all thoughts are welcome. thank you, drew..
    1 point
  26. Legacy delegation means that you delegate/stake your funds for "elrond community nodes" that are run by the elrond foundation Stake - you stake your funds in a staking pool for nodes run by a staking provider The legacy delegation currently cannot accept more active delegation (that actually earns rewards). You can still send, only it gets into a waiting list and in case some place is freed in active delegation it can become active delegation (but probably right now not many chances for places to be freed up). There are some though some staking pools still accepting delegations and giving rewards (check the APR for annual percentage returns)
    1 point
  27. Hello, Not really related to this topic, but let me reply if the team hasn't already. You have to wait your turn, there is no other way. Myself, I had to wait 6 months.
    1 point
  28. Thank you Adrian. I have been soooooo busy, it took me a while to thank you. I guess I will continue that way then. First, I was surprised because it went down from 29% to 16.7% so I thought it would be better to move to staking. But most of interesting staking pools are full. Cheers
    1 point
  29. Hello, I have succesfully delegated my EGLD to SIKKA and i can see the validated transaction under the "transaction" tab. But there is nothing under the "staked" tab and if i click on "unstake" nothings appear. I have tried to unlink/link my wallet but the problem is still appearing. Can you help me please? Romain
    1 point
  30. Only if you really want to move the delegation from elrond community nodes to a staking provider. Right now, as you mentioned, the APY for the legacy delegation is 16.7% (after fees are deducted) and it is better than what most staking providers that still accept delegations have.
    1 point
  31. Check on telegram with DrDelphi, he has already implemented a telegram bot doing the notifications for SPs increasing cap and changing fees, etc.
    1 point
  32. Yes, the 10-day unstaking period is a little intense, since so much can happen to the market in that time. I’m giving it until tomorrow afternoon, then taking the advice support gave me. Hopefully it doesn’t come to that, though.
    1 point
  33. Thank you Bogdan, I did what you'd suggested and it works like a charm! Martin
    1 point
  34. I am curious how this will be handled at protocol level. Can someone give me a high level explanation ?
    1 point
  35. Hi Maulik, Meantime please use https://devnet-wallet.elrond.com/dashboard, I tested right now and it's working as expected. Best regards, Marius
    1 point
  36. Good day. Was reading through the delegation documentation and noticed what I'm fairly certain to be an incorrect word: This is on url : https://docs.elrond.com/validators/delegation-manager/#unstaking-nodes Under the heading Unstaking Nodes, the line is: " IMPORTANT "Validators are demoted to validator status at the beginning of the next epoch after unstaking. This means that they stop receiving rewards." I believe the second 'validator' is actually an observer: "Validators are demoted to observer [node] status at the beginning of the next epoch after unstaking. This means that they stop receiving rewards The [node] I added in, I believe it is more clear specifying it that way. Thanks!
    1 point
  37. Hi Andrew, 1. Yes, staking via ledger is already possible. 2. All the SPs will be officially listed on both wallet.elrond.com and Maiar. 3. The SPs will make materials, video, presentations and will support a flawless onboarding for the delegators. Today will be a new blog post released will all the details around the phase 3 preliminary dates and other specific details. Best regards, Marius
    1 point
  38. Is it possible to make the minimum service fee dependent on the amount of nodes in a Delegation SC? Otherwise, larger providers will be able to offer a higher APR than smaller providers, making it relatively hard for new staking providers. Let me explain: Why would people choose a larger staking provider? My reasoning is: if a provider runs 50 nodes or 5 nodes, that matters for the average top-up of that provider. Suppose that the large provider is left with 2499 EGLD and is just unable to create a new node with it. Then those 2,499 EGLD are distributed over the 50 existing nodes. Imagine that the small provider is left with 2499 EGLD and cannot create a new node with it. Then those 2499 EGLD are distributed over the 5 existing nodes. For example, the large provider gets an average top-up of ~ 50 EGLD and the small provider an average top-up of ~ 500 EGLD. This way, the larger provider will be able to offer higher APR than the smaller one, according to the table. You can stimulate smaller providers by allowing them to charge a lower service fee. I hope this makes sense.
    1 point
  39. Hi Alexandru, The DelegationManager SC was verified and strongly tested by the team Elrond team. As you maybe already know, they use also formal verification on those for the safety part. Most of the staking agencies were very active on our Elrond Validators Telegram group, very technical guys and good professionals. Basically 2 things can happen: 1. If the staking agency will not maintain properly the nodes (shut down, doesn't upgrade etc): these will get jailed and stop earning rewards. Everyone on those nodes stops earning rewards. 2. If the staking agency will use the nodes to attack the network or by mistake will make double signing (using the same BLS key for 2 different nodes) or just they loose control of the nodes (and others will use them to attack the network). The protocol notices is and the entire pool gets slashed - (some of) the funds are lost. As far I know the slashing mechanism is not yet enabled. But taking in consideration the staking agency need to make the heavy lifting and come with 1250eGLD per DelegationManager SC to enable the stake function, for sure his own interest is to make things going reliable. Best regards, Marius
    1 point
  40. Hi cneazul, The reward pool for the combined waiting lists (staking/delegation queues) is already 5000 eGLD. With phase 3 you will be able to delegate your funds to staking services providers or run your own validator, as 1031 validator seats will be opened (from 2169 total number now to 3200 in phase3). This means that there will be an extra 1031*2500 = 2,577,500 eGLD that can become active delegation or active stake. Currently there are already 339 out of the 1031 seats filled in the staking queue (you can see that in explorer). For the validators that fill the 1031 seats, or active delegations for those seats, they will earn rewards as described in the phase 3 proposal. Phase 3 will also enable top-up, so extra to those 2577500 eGLD there can be an uncapped amount (actually limited by the circulating supply) staked/delegated, but with lower APR. The APR for the active stake/delegation that cover the base stake for those 1031 seats, as well as the APR for the top-up stake will change dynamically based on the total stake in the network, but it will always be guaranteed that the return for the base stake (2500 per validator) will be higher than the return for the top-up (extra stake, above the 2500 per validator). The queues for delegation and staking (currently also called waiting lists, but we decided to change the naming as to avoid confusion since we also have waiting nodes in the system used to buffer the shuffling between shards of active nodes) will still work but as you mentioned will no longer be incentivized. These will be used for providing easy replacement for undelegated and unstaked amounts.
    1 point
  41. I'm assuming you mean sending it as argument to an already deployed smart contract, using erdpy. There is no built-in "date" type in either C or Rust smart contracts. You will have to use unix timestamp as a u64. As for string, you'll have to hex-encode the bytes. There are plenty of tools online that do this, I personally use https://www.rapidtables.com/convert/number/ascii-to-hex.html Make sure you add a "0x" in front and use "None" as delimiter.
    1 point
  42. Hi Ikosov, For the ActiveDelegation the APR is fixed currently at 29% and you need to manually claim the rewards using the ClaimRewards button (right side). This is paid daily. For the WaitingList Delegation the APR is dynamically and can vary based on the no of eGLD in the queue (which evident can be different from week to week). Last week the APR was ~ 6.7%. This reward is coming by default in your main wallet (from where you made the delegation process), so no need for manually ClaimRewards operation. Also you can see the transaction in the transactions list. This is paid weekly (on every Monday) - you can receive fractional parts of it if you don't have a full week in the List, but is mandatory to still be in the List in the Monday to receive the rewards. The rewards buffer for both Delegation and Validators Lists is 5000eGLD per week. Best regards, Marius
    1 point
  43. It is not possible to delegate less than 10 eGLD. This is because more fragmented delegations would incur larger gas costs for other operations, like swapping active delegation with staking queue delegation, or increased storage access due to larger SC state. This is also a sort of sybil attack prevention. The difference between staking and delegation is that for staking you need to "lock" 2500 egld in order to run a validator and you need to take care of the machine running the validator software, keep it online, make sure it has good network connection, etc, while for delegation you just lock a variable sum of egld (minimum 10 egld) and leave a service provider to handle the machines/sw/updates, etc. One other difference is that when you stake and run your own validator node, you receive all the rewards, but also have the cost of running the machine, etc, if you delegate you only receive the (rewards - stakingServiceFee) but you have no other costs for running the validator.
    1 point
  44. Actually there is one change, where we plan to remove the maximum number of nodes limit, this is for when we introduce phase 4 staking which was briefly touched in the proposal, but the effect would be that we can have no limit for registering nodes, but in every epoch you would also only have 1600 nodes eligible, out of all registered ones, with a maximum of 20% swap ratio for shuffling, the nodes shuffled into eligible list being the best qualified nodes (considering stake value and possibly rating)
    1 point
  45. Thank you Adrian, this sounds pretty good and indeed is an elegant solution that will accelerate as well the level of decentralization.
    1 point
  46. my point is to reward more people who are committed to the project, and want to secure the system for the long term. and it's a way to keep gambler away
    1 point
  47. This all really great stuff guys! Excited for this next phase. Few questions / comments from me: 1. Is there an auto compounding feature available? 2. When a node reaches 5000 EGLD is there a mechanism to stake an observer automatically while putting next in line in the validator queue? 3. "Increasing the stake of a node will be possible using eGold from any source, not just Validator rewards". - Love this. No barriers to daily cheap compounding / growth. 4. How much EGLD should we hold in our delegation contract to ensure we are always validating? 5. With delegation can we automate the process of staking new nodes? 6. Will we be able to set delegation contracts up to include time based rewards for our delegators. For example someone who lock for 90 days pays less commission? 7. Does the delegation contract include a variable to remove the server cost from the gross rewards before the main distribution? Cheers!
    1 point
  48. Hey Truststaking, That makes sense sense to be considered in the research work mentioned above. Thank you!
    1 point
  49. I think it's time for a small presentation. My name is Kevin and i'm from France :) My interest for cryptocurrency really started in March and i discovered Elrond quite late in June. I am autodidacte and passionate in web-technologies and i believe that Elrond will occupy myself for the years to come. I am used to work with API and im fluent in SQL. Who know may be one day i will write some smart contracts on Elrond I feel like i'm taking part in history and i'm glad to help the french community in telegram and on medium as a translator :) Have a nice day !
    1 point
  50. Week #40 | Monday, September 30 – Sunday, October 6, 2019 1. Preparations for the Battle of Nodes (improvements, bugfixes, benchmarks, tests) 2. Initial implementation of a System VM and smart contract for validator staking, that will allow nodes to join the network real-time, through a fast protocol built-in mechanism 3. VS Code extensions can handle WASM smart contracts written in C and Rust. Work in progress to enable debugging of such code in the IDE 4. First flood attack on our testnet v1.0.19 made us tweak the libp2p's parameters and craft additional anti-flooding capabilities 5. Fixed the arm64 build so we can now run validators on raspberry pi4 6. Refactoring of shard processor in order to remove duplicate code and group all arguments in a single structure 7. Snapshot of the trie for saving the current state of the trie in a separate database. 8. Compaction of miniblocks to allow us to add more transactions in a block and decrease the data that needs to be propagated to metachain. Throttled mini blocks creation to a defined maximum value, to avoid bottlenecks with blocks with a too higher number of miniblocks 9. Added a local cache of meta blocks, used for processing current shard block, to avoid situation when a full pool of meta blocks (happening especially when a node is bootstrapping), would generate situation when needed meta blocks are in fact evicted from pool 10. Validator's uptime statistic improvements for the Battle of Nodes 11. Added more data in Elastic Search related to consensus group, will be visible in the testnet explorer 12. Economics rewards metrics for termui. Soon an estimation of how many ERDs you can earn 13. Fixed bug that caused in some situations the block to be rejected due to missing reward transactions 14. Fixed a bug after merging with the economics part which didn't allow the node to start 15. Further bugfixes and improvements
    1 point
This leaderboard is set to Bucharest/GMT+02:00
×
×
  • Create New...