Thanks. Also edited metadata on polkassembly (after a few technical hickups!)
3 Likes
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!
3 Likes
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.
1 Like
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.
1 Like
Then iâd take that as 3 weeks 
Let me know if anything changes.
2 Likes
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.
2 Likes
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
4 Likes
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
2 Likes
- 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 :-/
4 Likes
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)
6 Likes
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
3 Likes
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.
4 Likes
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
5 Likes
The staking data for stakeglmr.com is fully synced and the chat module (for staking data) is up.
https://www.stakeglmr.com/chat
Here is an AI summary of the tools available. If you are trying to run a query and it fails, let me know.
Core Blockchain Data
- Block information (hash, timestamp, year, month, week, day, hour, round)
- Events (system actions, extrinsic results, contract executions)
- Extrinsics (user-originated actions)
- Account details (birth block, birth round, birth timestamp, contract status)
Staking Data
Network-wide Statistics
- Total staked amount
- Network APR (Annual Percentage Rate)
- Network authored blocks (total and average)
- Staking leaderboard
Collator-specific Data
- Authored blocks (count and average)
- APR for delegators
- Backing (counted staked amount)
- Missed rounds
- Active rounds
- Identity information (display names)
Delegator-specific Data
- Staking rewards
- Delegations (staked amounts per collator)
- Staking activities (delegations, scheduled undelegations, executions)
Data Granularity
Data can be queried at different frequencies:
- Block-based
- Round-based
- Hourly
- Daily
- Weekly
- Monthly
- Yearly
Time and Block Utilities
- Block range conversion utilities (date to blocks, rounds to blocks)
- Timestamp conversions
- Current date/time and block number retrieval
- Historical data aggregation (mean, min, max values)
Special Features
- Sparse data handling (values recorded only when changes occur)
- Support for both time-based and block-based queries
- Identity resolution for collators
- Logged-in user information
- Support for various token denominations (GLMR with different decimal places)
Query Capabilities
- Filter by specific addresses
- Date range queries
- Block range queries
- Round range queries
- Section and method specific queries
- Related observations for accounts
- Historical aggregations
3 Likes
Hi team,
No updates on the development side, there is a small list of todos but I will be tackling them over the next two months.
I wanted to ask how should we go forward to cover the infra costs. Here is the current rundown on a monthly basis:
| Provider/Service | Description | Quantity | Cost (âŹ) |
|---|---|---|---|
| Hetzner | 7.68 TB NVMe SSD Datacenter Edition | 1 | 64.00 |
| AX162-S Dedicated Server | 1 | 197.30 | |
| Primary IPv4 | 2 | 3.40 | |
| RAM-Upgrade (32 GB DDR5 Reg. ECC) | 4 | 46.00 | |
| Hetzner Subtotal | 310.70 | ||
| Temporal | 1M actions | 1 | 50.00 |
| Vercel | Monthly Subscription | 1 | 20.00 |
| Cloudflare | Cloud Storage | 1 | 20.00 |
| Total Monthly Cost | 400.70 |
This covers both Moonbeam and Moonriver, and it is enough to also cover the deep state data. If the 8TB drive is not enough to fit both beam and river, then we will have to add a second drive. But that would be months from now. The above system is meant for minimizing costs and it doe snot offer redundancy. I will keep backups, but an NVME drive failure would take time to resolve. I think thatâs ok. We can add an HDD for backups when the data is ready for a low cost.
I have already been paying these costs for the past year in development, but that was part of the grant process. How do we manage this going forward? Not sure what the âdefaultâ way to manage recurring costs is.
Ioannis
2 Likes
Discussion post on polkassembly:
Hey guys, it looks like the treasury proposal process has changed and I just have to submit a request here.
I spoke with @micheleicebergnodes and I was informed that we have to do a moving average. The problem with this is that it will move the price risk on me. I would be ok with this if it was a for-profit arrangement, but we are just passing costs.
I am happy to maintain both websites and not charge anything for time. But we have to cover infra costs 100%.
If this is a process thing and we cannot side-step it, then we will have to add a safe margin.
[EDIT]: Was informed that the moving average thing is a rule so thatâs that. In that case, we will simply mark up or down the price every 2 months, trying to keep an target of EUR 800 average (on funds release date).
Let me know if that sounds good @TreasuryCouncil
1 Like
Dear Ioannis,
first of all thank you a lot for your valuable services, always much appreciated and recognized inside our Community!
We reviewed internally this topic with the Treasury Council, here below the final agreements:
- Ok about your proposal to add a safety margin to take fully into account all the costs you faced
- About the price updating timing, we would like to keep the âQuarterly logicâ (like we do for RPC services, for example)
For what concern the costs you ALREADY processed, we wait for your final numbers and beneficiary address so that we will proceed on-chain asap with the related payments.
For the future, keep in mind the quarterly logic.
Thanks again!!!
Michele
1 Like
Hey @micheleicebergnodes , team,
Months: January, February, March
at EUR 400 per month, + EUR 50 safety margin
Total EUR 1,350.00
This covers the infra costs for both stakeglmr.com and stakemovr.com (with many thanks from Hetzner)
For beneficiary you can use Stakebaby collator addresses, and split the amount as you see fit or sent it over one network only. Itâs the same for me.
Moonbeam
0xAb4B115b2D23EF8DA7b0aa54FC074fB4C6886441
Moonriver
0x1980E75f1b1cdAAe3b2f79664C7cb83b86A3D404
2 Likes