Thanks. Also edited metadata on polkassembly (after a few technical hickups!)
Both Treasury Motions have been approved, executed and are now closed.
Expect the GLMR payout in 5 days 10 hrs and in 2 days for MOVR.
Thank you, @stakebaby!
Thank you guys! I will continue providing updates here until the project is 100% ready and pushed to production.
Hi @stakebaby ,
Can you give an ETA on the pending functionalities, please?
We’d like to share this with the broader audience and push through our socials.
Or if you think the current state would work for that too, then let me know.
The most time consuming process is the deep state indexing. I will experiment with the 80-core Arm-based server in Hetzner (vs the AMD 48-core I am using now) and then scale out. The indexing process should take 3-4 months.
However, as I mentioned before it would be prudent to wait for surrealdb to launch their non-beta version of surreal 2. I will discuss with them how risky it would be to start with their beta version and then upgrade. You can view their releases here: SurrealDB | Releases | The ultimate multi-model database
As far as sharing something with the community, let me add some additional safety checks and solve some annoying frontend bugs, and then we can share the non-production version at the v2 url. I will be back from vacation in 10 days and i need another week for that.
Then i’d take that as 3 weeks
Let me know if anything changes.
Hey team, I will be a little late (as usual). I need to refactor the temporal workflow that keeps the staking data (including unbonding info) in near real-time sync. This is a separate workflow from the deep-state indexer because it had to be custom-built to be able to stay up to speed. It seems that it processes 140GB of data per day, which will result to a $80 monthly bill at minimum retention (1 day), and a multiple of that if i want higher retention. I didn’t expect that, but I can refactor it to move some data flows off the workflow and onto activities + s3.
Finished the following:
- Added extra measures for backend calls to not crash db due to load
- Implemented contract calls in https://v2.stakeglmr.com/staking-account , now users can stake and unstake from there
- fixed wallet connect issues
- fixed UI bugs and polished components
- added smart contract utilities (only insurance cover for now) and connected to smart contract
- started staking indexer workflow refactor
Pending:
- fix more UI bugs
- implement collator management dashboard (upload icons, edit post moertems, etc.)
- index chain from block 0 (cannot start until surreal db 2 goes out of beta, most likely at the end of sept)
- finish staking indexer workflow refactor to lower monthly costs
- improve dark mode looks
I think we can share the v2 url with users now, but make it clear that it is WIP. @lina.k.m
Hi team, Surrealdb released their production ready 2.0 version. The step-up from v1 would have required a db export and import (which would have been impossible with the data volume), so, good thing we waited. We can now start syncing from genesis
- Updated some libraries to latest versions, fixed breaking changes
- Set up Surrealdb 2, and updated the code and statements to address the breaking changes
I have ran into a database bug that was not there in surreal v1, and crept up in v2. Basically, IGNORE does not work in INSERTS. I have tried a few ideas to work around it but they cause new issues in a highly concurrent environment so, I think I will have to wait for a fix in a subsequent release :-/
The new version is live on
Here is a sample account dashboard form a random address that stakes with multiple collators:
https://www.stakeglmr.com/staking-account/0xc0459ed471434a234acf1b388512cfc71978cbc6
If the address is logged in (your wallet) you also get stake and unstake buttons.
The staking data is actively syncing from genesis. The current live version has only the last couple of months synced, so, some data inconsistencies are there, especially for data that span long durations, i.e. monthly data, or lifetime data like collator age. These will be resolved when the sync is completed.
Pending to be released
- Deploy platform for Moonriver
- Deep state explorer, where the user can see the data of any query and any input across time (this will take a long time to sync)
- Chat interface for both the staking data and the deep state indexer (it needs some finetuning)
outstanding job @stakebaby new website is awesome. Did notice the data inconsistencies right off for some of the long term active collators only showing 34 days active set. Wow, love the new website, looking forward to seeing the same changes for MOVR
Quick update. Syncing the staking data (not the deep state data) has been progressing without any surprises for 3 weeks. We are at block 3,250,000 and the database is at 8.5 GB. Once the staking data sync is finished, I will unhide the chat module and that will give access to all the data you see in the collator comparison dashboard and in the personal staking dashboard, for a any time span, through chat.
A small change - the chat module will have two assistants, a staking assistant, and a deep state assistant. I initially camped all the tools (functions that an assistant can call) in one assistant. In theory, this allows combining the two datasets for even better insights. In practice, it tends to confuse the assistant because there are tooo many tools to chose from, and there is some overlapping data between staking and deep state (although the method of fetching it is completely different). Anyways, two assistants works much better for now and it gives the user more control too.
Deployed v2 to stakemovr.com
I was planning to do that later, but because the v1 version had some technical issues, i went ahead and pushed.
Similarly to stakeglmr, the current stakemovr version has only indexed the last 20K of blocks. I will start syncing from genesis after I make sure the numbers look ok.
Syncing for stakeglmr staking data is at block 5.5M