Realms voter-weight plugin
Current devnet program status and the remaining Realms client work.
Entros has deployed an on-chain voter-weight addin prototype to Solana devnet. The program reads an Entros Anchor and writes voter weight 1 when the configured Trust Score and recency checks pass. An ineligible update returns an error.
The normal Realms voting flow also needs a JavaScript client. That client must construct the plugin instructions and register with Governance UI. Entros has not shipped that layer yet.
Devnet program
99nwXzcugse3x8kxE9v6mxZiq8T9gHDoznaaG6qcw534No Entros voter-weight program is deployed on mainnet.
On-chain configuration
The realm authority creates a Registrar for one realm and governing token mint.
| Field | Type | Meaning |
|---|---|---|
min_trust_score | u16 | Minimum Entros Trust Score |
max_verification_age | i64 | Maximum seconds since the latest verification |
The program supports these instructions:
create_registrarupdate_registrarclose_registrarcreate_voter_weight_recordupdate_voter_weight_recordclose_voter_weight_recordcreate_max_voter_weight_recordupdate_max_voter_weight_record
Manual program tests can create the accounts and exercise the checks on devnet. This does not make the plugin available through the normal Realms UI.
Remaining client work
The planned Realms integration must add:
- A typed JavaScript client for every program instruction.
- Governance UI registration and plugin metadata.
- Automatic instruction insertion before each governed action.
- Integration tests against a representative Realms proposal flow.
- A documented recovery path for stale or ineligible Anchor state.
Plugin chaining
The current Registrar stores no predecessor plugin ID. update_voter_weight_record accepts no input voter-weight record. Entros therefore does not chain with token-voter, NFT-voter, or another addin today.
Chaining remains planned. The design must add a predecessor field, validate the input record owner and action, then define how Entros eligibility composes with the prior weight.
Intended governance outcome
The program currently enforces one unit of voter weight per eligible Anchor. Each wallet can have one Anchor PDA. Population-level uniqueness remains an open protocol objective, so this is not yet a one-person-one-vote guarantee.
The intended outcome is governance where one returning human contributes one eligible vote without KYC or face scans. The client integration and uniqueness evidence must close before that claim becomes current behavior.