Verified humans.
Verified votes.
The devnet program reads an Entros Anchor and writes an eligible voter-weight record. The Realms client layer remains planned.
Token weight tells you about balances.
A standard Solana DAO counts ballots by token balance. Tokens change hands, sit in cold wallets, get delegated, and pile up on attackers willing to pay. The price of attacking governance tracks the token price; it has no connection to the price of being a returning human.
2022
Mango Markets
$47M whale self-vote
The exploiter who drained the Mango Markets treasury used the protocol's own governance to vote on returning a portion and keeping the rest. Their wallet still held enough MNGO to clear quorum, and token balance was the only barrier they had to clear.
2023
Synthetify
~$230K from ten proposals
Ten self-funded governance proposals moved roughly $230K out of the Synthetify treasury before the DAO responded. Each wallet bought enough tokens to clear the proposal threshold. The vote process had no way to ask whether a human stood behind any of them.
2025
Jupiter Jupuary
750K wallets filtered as Sybil
The Jupiter team filtered more than 750,000 wallets out of Jupuary distribution after the fact. Each filter was hand-built, downstream, and ran on data the team had to source itself. An upstream personhood primitive moves that work off every protocol's plate.
In every case the ballot asked about balance. None of them asked whether a returning human stood behind it.
Program first, client next.
The on-chain addin implements the voter-weight record format. A JavaScript client and Governance UI registration are still required before voters can use the normal Realms flow.
Register the future client
The planned JavaScript client registers with Governance UI and constructs each required plugin instruction.
Choose the floor
The operator picks a minimum Trust Score and a maximum staleness window. A comment thread can use a low floor and a long window. A treasury allocation can ask for a higher score and a recent verification.
Voters verify once
A voter holds an Entros Anchor, a non-transferable Token-2022 mint. They run a twelve-second verification capture at entros.io/verify and the Anchor updates. The same Anchor reads to this DAO and every other Entros-gated surface on Solana.
Insert the eligibility update
The planned client updates the voter-weight record before the governed action. The on-chain program then applies the configured Anchor checks.
What the plugin changes.
Spam-quorum on a small DAO
Standard
An attacker spins up a hundred fresh wallets, funds each one with the minimum token balance, and casts a hundred votes. Quorum lands at near-zero cost.
With Entros
The intended design requires each wallet to clear the configured Anchor policy. Population-level uniqueness must prove that the wallets represent distinct people before this becomes a one-person-one-vote claim.
Whale dictating treasury allocation
Standard
A whale holds concentrated token weight and pushes through proposals that pay their own bag. The outcome tracks the balance.
With Entros
The current prototype writes one unit for an eligible Anchor. Future plugin chaining can define how that eligibility composes with token weight.
Dormant delegations
Standard
Stakers delegate tokens to staking contracts and the contracts auto-vote off whale signals. Holders never see the proposal page.
With Entros
The intended client requests a recent Entros result before the action. Realms integration tests must confirm the behavior for delegated voting.
Deployed and inspectable.
The plugin runs on Solana devnet under the program ID below. The source is on GitHub. Read it, run it locally, fork it.
- Program ID
- 99nwXzcugse3x8kxE9v6mxZiq8T9gHDoznaaG6qcw534
- Cluster
- Devnet
- Compatibility
- spl-governance v3.x
- Source
- Open, MIT-licensed
Run your DAO.
On verified humans.
The on-chain prototype is ready for program-level testing. Realms proposal pilots begin after the client and chaining boundaries are implemented and tested.