Grant Application: Offline Election Tool by Team Starks

[Ipsa11]

This pull request contains the Level 1 grant application for the project titled Offline Election Tool, developed by Team Starks, in response to the offline-election-tool RFP.

✅ Grant [Level]
Level 1: Up to $10,000, 2 approvals

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[Ipsa11]

I have read and hereby sign the Contributor License Agreement.

[Ipsa11]

Hi team 👋

The CLA Assistant bot has confirmed ✅ "All contributors have signed the CLA",
but the status check CLA Assistant / CLAAssistant (pull_request_target) is still failing.

This looks like a workflow execution issue rather than a signature problem.
Could someone with write access please re-run the CLA check from the Actions tab?
Thanks!

[keeganquigley]

thanks @Ipsa11 we will fix it on our end. I will mark the application as ready for review and ping the committee to take a look.

[keeganquigley]

I will also ping @michalisFr who wrote the RFP, in case he is able to take a look.

[Ipsa11]

Great, thanks @keeganquigley for the update! I appreciate it and look forward to the committee’s feedback.

[michalisFr]

Thank you for your submission @Ipsa11! If could answer the following questions, that would be greatly appreciated:

1. Please have a look at this issue: Feature request: Offline election prediction with custom parameters paritytech/polkadot-staking-miner#1050 where this is discussed with core devs and their proposed solution is based on polkadot-staking-miner. Does your planned approach coincide with theirs?

2. Which election algorithm will the tool use if one is not specified?

3. If no snapshot block is specified and we're in the Off Phase, will the tool be able to generate results based on the latest chain state?

4. Please note the comment by @sigurpol that the new staking miner only works with staking-async after the Asset Hub migrations. This is acceptable, given the short timeframe until the migrations. Do you have a better solution? In any case, though, the tool definitely needs to work after the migrations, since Staking won't be long on the Relay Chains.

Finally, please also note the request that the output includes the specific nominators allocated to each validator (which you have included) along with the allocated stake.

[Ipsa11]

Hi @michalisFr sorry for the late reply and thank you for the thoughtful questions! Let me address them one by one:

Relation to polkadot-staking-miner (#1050):
Yes, our planned approach largely coincides with the discussion in the referenced issue. We also intend to base the solution on polkadot-staking-miner, extending it with offline election prediction capability and exposing parameters for customization.

Election algorithm if unspecified:
If the user does not specify an algorithm, the tool will default to the same election algorithm currently in use by the Polkadot chain (Phragmen). This ensures consistency with on-chain elections.

Handling missing snapshot block in Off Phase:
If no snapshot block is specified and the tool is executed during the Off Phase, it will fallback to the latest available chain state to generate results. This allows predictions to remain useful without requiring manual input every time.

Compatibility after Asset Hub migrations / staking-async:
We are aware that the new staking miner only works with staking-async after the Asset Hub migrations. This is acceptable for us, since our tool is being designed with the upcoming migrations in mind. We do not see a better short-term alternative, so our focus is to ensure smooth operation post-migration, when staking is no longer on the Relay Chains.

Output requirements (nominator allocation + stake):
Yes, the output will explicitly include both (a) the list of nominators allocated to each validator, and (b) the specific stake amounts allocated. We consider this essential for the usefulness of the tool.

[sigurpol]

Sounds great, looking forward to it. And ofc we remain at your disposal in case you need help or you have open questions.

[michalisFr]

@Ipsa11 Please add these clarifications to the proposal and then it will LGTM. Thank you!

[Ipsa11]

Hey @michalisFr I've made the requested changes to the proposal. Please review them and let me know if everything looks good. The link for the same is:-
bbd1944

[keeganquigley]

Thanks @Ipsa11 I'm willing to give the first approval. In the meantime, could you please do KYB verification with our provider?

NOTICE:
In connection with your participation in an ecosystem initiative organised by Web 3.0 Technologies Foundation, you agree to the processing of your personal data for identity verification, in order to prevent fraud, ensure eligibility, and maintain the integrity of our processes. This processing is based on legitimate interests under the EU General Data
Protection Regulation and on justified organisational needs under the Swiss Federal Act on Data Protection. Your information will be handled in line with the Web3 Foundation Privacy and Cookies Policy and the Sumsub Privacy Notice.

[Ipsa11]

Thanks @keeganquigley and @michalisFr for the approval. Since this is a Level 1 grant, it should only require two approvals to merge.
Grant Level:
Level 1 – Up to $10,000, requires 2 approvals.

So why does it indicate that 5 approvals are required?

[keeganquigley]

Thanks @Ipsa11 no worries we can merge manually, but I'm not seeing that KYB was completed yet?

[Ipsa11]

Thanks @keeganquigley. We’re in the process of completing the KYB on our end, but the data verification is taking a bit longer than expected. We hope to have it finalized as soon as possible.