ALPHA-Vote is a neuron automation system that ensures the NNS gets the best out of its voters, while allowing voters to get the most out of the NNS.
It’s in its final stages of development. Once it’s wrapped up shortly, it will provide 3 verifiably decentralized options for followers that ensure they never miss voting rewards, securely handling their vote in one of 3 ways:
-
- Voters who have every intention of reviewing proposals for a specific topic manually should consider following Ωmega-reject. In principle an automatic rejection should never occur, but in the unlikely event that a manual vote is accidentally missed, a rejection will be automatically triggered at the end of the voting period (as your neuron will follow the last-minute vote of Ωmega-reject).
-
- Voters who intend to sometimes step in and vote on a specific topic should consider following Ωmega-vote. This ensures a diligent vote is cast by default (if D-QUORUM has voted), but also gives the follower the ability to vote manually for the vast majority of the voting period (should they decide to). If they end up not voting manually, D-QUORUM’s vote will be copied by Ωmega-vote within the last 3 hours of the proposal deadline (which will then trigger your neuron to vote the same way). If D-QUORUM didn’t vote either, then a default rejection will be triggered (in the same way as Ωmega-reject).
-
- Voters who have no intention of reviewing a proposal topic manually should consider following αlpha-vote (or another neuron who uses this framework by following one of these 3 neurons) to guarantee that voting opportunities are never missed, and that voting rewards are always captured. αlpha-vote basically follows D-QUORUM (so it votes as soon as D-QUORUM votes), but will reject in the last 3 hours if D-QUORUM doesn’t vote. The difference between αlpha-vote and Ωmega-vote is that the former votes as soon as it can, and the latter votes as late as it can (while still reliably ensuring a vote is cast). This difference in behavior is where the alpha and omega naming convention comes from (first vs last).
Important Usage Notice
Ωmega-reject, Ωmega-vote, and αlpha-vote (and/or other neurons that themselves follow these neurons) should ideally be the only neuron(s) that you’re following on a specific topic for this process to work reliably for that topic. Otherwise there is a dependency on the behavior of those other neurons (unless they’re also following one of these 3 neurons to ensure a vote is cast reliably).
Though it’s still being finished up, ALPHA-Vote can nonetheless be used today. I’ve been using it for months and have not missed a vote on any topic since. Importantly, ALPHA-Vote is not yet decentralized (while I’m finishing up a test suite, and finalizing threshold control to widely decentralize canister control). There are also a few adjustments to make so that the controlling canisters are stateless, for simplicity and efficiency (thanks for the feedback @sat!), among a few other minor things to tick off.
By establishing these known neurons in advance of the decentralization stage, evidence can be gathered regarding their reliability (via known neuron voting history). Some of the canisters involved in this solution will be blackholed, offering advanced users extra security where desired. Before blackholing these canisters, a final period of observation and monitoring will be carried out on the known neurons (ensuring robustness). Any unexpected issues can therefore be swiftly addressed.
Special thanks to all members of the D-QUORUM founding committee. ALPHA-Vote is built on top of D-QUORUM. 
Control of ALPHA-Vote will be decentralized to interested members of this committee, and beyond.
Within the next day or two, I plan to raise 3 known neuron proposals:
- Ωmega-reject known neuron - “Always votes: This neuron automatically rejects in the last few hours of the proposal (giving you plenty of time to vote manually instead)”
- Ωmega-vote known neuron - “Always votes: This neuron automatically copies D-QUORUM’s vote in the last few hours of the proposal (giving you plenty of time to vote manually instead)”
- αlpha-vote known neuron - “Always votes: This neuron follows D-QUORUM as well as automatically rejecting in the last few hours of the proposal if a vote has not already occurred”
FAQ
What problem does ALPHA-Vote aim to solve?
There are notable examples where diligent voters have lost followees simply for missing an occasional vote. This dynamic is not helpful for encouraging high-quality due diligence and decentralization. This tendency of followers has been used as reasoning to diminish the size of the voting quorum of well-known neurons, including adding hotkeys which grant individuals unilateral control over otherwise community-controlled neurons.
ALPHA-Vote aims to provide an alternative approach that does not compromise on security and decentralization. This solution allows diligent voters to take their time during reviews, safe in the knowledge that they will not accidentally miss the deadline in a way that leads to lost voting rewards. Followers commonly value knowing that their followee neuron will always vote, no matter what.
How does ALPHA-Vote ensure a vote is never ever missed?
ALPHA-Vote has multiple degrees of redundancy and fault tolerance built in. The system is spread across numerous different subnets, including the fiduciary subnet, so if one subnet stalls the others will pick up the slack.
How does ALPHA-Vote deliver highly secure votes?
ALPHA-Vote is deployed on the fiduciary subnet which is composed of 40 nodes. There are also fallback canisters that reside on smaller subnets, but these canisters are required to reach consensus before they can affect the final vote. This means multiple 13-node subnets would need to be attacked in order to affect the behavior of ALPHA-Vote, provided the 40-node fiduciary subnet has also been successfully attacked or stalled at the same time.
Once ALPHA-Vote is finished, the main canister (on the fiduciary subnet) will be controlled by a large quorum of developers, notable governance participants and DFINITY engineers who are required to come to consensus in order to deploy updates. There is no anticipated need to deploy updates, except for unanticipated API changes that may occur in the future.
The fallback canisters on the smaller subnets will be blackholed. Each of these control their own set of neurons, which each contribute to the final vote of the known neurons. If these blackholed canisters ever break (as a result of unanticipated API changes), the known neurons can be reconfigured to follow a fresh set of fixed blackholed canister controlled neurons. In the meantime, no votes would be missed as the blackholed canisters simply serve as an edge-case backstop (the main canister on the fiduciary subnet is capable of catching proposals and triggering votes by itself).
Advanced users who would prefer immutable behavior (with the risk that it may break at some point in the future) can follow the blackholed canister neurons directly.
How can I monitor the behavior of ALPHA-Vote canisters and neurons?
Once the known neurons are adopted you can track the votes like any other known neuron, on the dashboard and via the governance canister.
All canisters also have publicly visible logs. Here’s some example output:
...
[1394. 2025-06-01T03:33:42.370973756Z]: Cycles: 2821409555036, Proposals: 41 live, of which 0 actionable, of which 0 actioned, of which 0 in this run. P#136762 due in 1617 seconds.
[1395. 2025-06-01T04:34:05.161367974Z]: Cycles: 2821190936841, Proposals: 41 live, of which 3 actionable, of which 3 actioned, of which 3 in this run. P#136765 due in 5206 seconds.
[1396. 2025-06-01T05:33:39.092400623Z]: Cycles: 2821088402752, Proposals: 41 live, of which 3 actionable, of which 3 actioned, of which 0 in this run. P#136765 due in 1609 seconds.
[1397. 2025-06-01T06:33:53.016396817Z]: Cycles: 2820901073728, Proposals: 41 live, of which 5 actionable, of which 5 actioned, of which 2 in this run. P#136767 due in 5225 seconds.
[1398. 2025-06-01T07:33:39.728128677Z]: Cycles: 2820798462487, Proposals: 41 live, of which 5 actionable, of which 5 actioned, of which 0 in this run. P#136767 due in 1625 seconds.
[1399. 2025-06-01T08:33:57.275413622Z]: Cycles: 2820579897149, Proposals: 41 live, of which 8 actionable, of which 8 actioned, of which 3 in this run. P#136770 due in 5222 seconds.
[1400. 2025-06-01T09:33:41.311096619Z]: Cycles: 2820477314296, Proposals: 41 live, of which 8 actionable, of which 8 actioned, of which 0 in this run. P#136770 due in 1620 seconds.
[1401. 2025-06-01T10:33:59.85278223Z]: Cycles: 2820258723182, Proposals: 41 live, of which 11 actionable, of which 11 actioned, of which 3 in this run. P#136773 due in 62821 seconds.
...
You can get the latest output via dfx, e.g.
alpha_backend
dfx canister logs 2lo52-kiaaa-aaaar-qaqta-cai --network=ic
alpha_backend_minor_1
dfx canister logs a2fbo-uiaaa-aaaac-qad2q-cai --network=ic
alpha_backend_minor_2
dfx canister logs tuit2-eiaaa-aaaam-aeoqq-cai --network=ic
alpha_backend_minor_3
dfx canister logs ax3oi-myaaa-aaaas-qbueq-cai --network=ic
alpha_backend_minor_4
dfx canister logs qwmt6-kaaaa-aaaau-abyoq-cai --network=ic
alpha_backend_minor_5
dfx canister logs ynhfi-eiaaa-aaaae-qfw6q-cai --network=ic
Can I augment and deploy my own version of ALPHA-Vote?
Of course! It’s all open source and documented in detail here → aodl/ALPHA-Vote: Decentralized, verifiable automation for guaranteed NNS voting, while supporting high-quality due diligence
Who pays for the cycles?
I’m keeping the canisters well topped up for the time-being. I’m also working on a sister project that will provide a perpetual source of cycles for blackholed canisters (using maturity from a blackholed yield generating asset). This will be the next phase in making ALPHA-Vote unstoppable (along with any other canisters that wish to make use of the same cycles top-up mechanism).
Please ask any questions you have and I’ll do my best to answer your queries before raising the proposals. Note that the ALPHA-Vote solution is composed of 6 canisters that are constantly burning cycles on numerous subnets, and more canisters will be added in the future if the community makes use of this system. This setup is designed to provide redundancy, and cross-subnet fault tolerance. The need to never miss a vote is taken very seriously.
Canister + Neuron details
| Subnet | Node Count | Canister | αlpha-vote neuron | Ωmega-vote neuron | Ωmega-reject neuron | Canister Decentralization Plan (once finished) | Canister triggers vote within |
|---|---|---|---|---|---|---|---|
| ejbmu | 13 | alpha_backend_minor_5 | minor (follows D-QUORUM) | minor (copies vote at the end) | minor | Blackhole | Last 3 hours (if not already triggered by D-QUORUM) |
| c4isl | 13 | alpha_backend_minor_4 | minor (follows D-QUORUM) | minor (copies vote at the end) | minor | Blackhole | Last 3 hours (if not already triggered by D-QUORUM) |
| 4utr6 | 13 | alpha_backend_minor_3 | minor (follows D-QUORUM) | minor (copies vote at the end) | minor | Blackhole | Last 3 hours (if not already triggered by D-QUORUM) |
| 4ecnw | 13 | alpha_backend_minor_2 | minor (follows D-QUORUM) | minor (copies vote at the end) | minor | Blackhole | Last 3 hours (if not already triggered by D-QUORUM) |
| w4asl | 13 | alpha_backend_minor_1 | minor (follows D-QUORUM) | minor (copies vote at the end) | minor | Blackhole | Last 3 hours (if not already triggered by D-QUORUM) |
| minor neurons are followees of the known neuron below | minor neurons are followees of the known neuron below | minor neurons are followees of the known neuron below | |||||
| ↓ | ↓ | ↓ | |||||
| pzp6e | 40 | alpha_backend | KNOWN | KNOWN | KNOWN | Threshold Consensus among well-known governance participants, devs, and DFINITY engineers | Last hour (if not already triggered by consensus of the minor canister neurons) |
Note: Some of the minor canisters have been newly instantiated in the last few days, so not all minor canister neurons have been set as followees on the main neurons yet. 4 days need to pass to account for proposals that were submitted before the neurons were created (so that they’re able to vote on all open proposals). This is one among other tasks that need ticking off.
These canisters each reside on their own independent subnets. Given that the remaining subnets (other than pzp6e) have lower consensus thresholds (13 nodes), consensus among these canisters (across subnets) is required to trigger a vote on αlpha-vote, Ωmega-vote, and Ωmega-reject. This is achieved by each of these minor canisters being the controller of its own set of 3 neurons (these ones are not intended as known neurons). Each canister affects its 3 neurons in the same way that the fiduciary (pzp6e) alpha_backend canister affects the 3 known neurons.
The 3 known neurons are configured to follow the minor canister neurons on each topic. This means that >=50% of the minor canister neurons must vote the same way to trigger a vote on the corresponding known neuron.
The alpha_backend canister and the alpha_backend_minor canisters poll the NNS at the same regular interval (offset arbitrarily by deployment timing and drift). They differ, however, in that the alpha_backend canister only triggers a vote on the known neurons in the last hour of the voting period (if the neuron hasn’t voted already). The minor canisters, on the other hand, trigger a vote on their neurons as soon as 3 hours before the end of the voting period. This means that if all systems are working well, and the majority of subnets are not in a stalled state, then the fiduciary alpha_backend canister will never need to trigger a vote (it will have been triggered already via the followee neurons). If, on the other hand, consensus is not reached by those neurons (due to subnet failure), the alpha_backend canister will pick up the slack.
