Most online communities spend a quiet majority of their effort on gatekeeping. Bots screen new members, mods verify role-claims by hand, ambiguous self-attestations get treated as evidence, and trolls slip through anyway. The whole apparatus exists because the underlying identity layer cannot answer a simple question: did this person actually do the thing they say they did?
In Sudo, that question has a simple answer: the chain knows. If your group is "everyone who ever interacted with this contract", you don't need a screening bot. You need an index.
This post is about smart-contract groups — Sudo's primitive for communities that grow themselves out of on-chain history — what they are good for, where they break, and how to set one up in two minutes without a single line of code.
The problem: gatekeeping is exhausting
Run a modest Discord for an NFT project and the daily ops are the same in every server. New users join. They claim to hold the token. The moderator verifies the claim — usually by asking them to connect their wallet to a third-party verifier bot that posts a signed message. The user signs. The bot grants the role. Twelve hours later, the user transfers the NFT, but the role persists because the bot polled once at join time and never again.
Every step of that flow is an invitation for fraud. Every step costs the moderator attention they would rather spend on the community. And every step is unnecessary because the chain is already the source of truth — moderators are just doing the chain's job by hand.
Smart-contract groups invert the entire flow. The group is a cached query against the chain. Membership is a derived property, not a manual grant. Ownership changes propagate automatically. The mod work disappears.
How it works in two minutes
You create a group in Sudo, paste a contract address into the "smart contract" field, optionally narrow the eligibility rules (e.g. "owns at least one NFT" vs "owns at least three NFTs", or "interacted with the contract before block N"), and save.
Behind the scenes, the indexer reads the contract's full event history, filters for the eligibility predicate, intersects the resulting wallet set with the Sudo user base, and adds the matching wallets as members. Future blocks are streamed in real-time; new wallets that meet the predicate are added immediately, wallets that fall below the threshold (e.g. they sold their last NFT) are demoted out of the group, and re-entries are restored automatically.
There is no claim flow. There is no role bot. There is no quarterly re-verification. The group is the contract, lazily evaluated.
Per-event filtering and role mapping
Most contracts emit several distinct event types, and you usually want to slice the population accordingly. A DeFi protocol might want a "depositors" channel and a "governance voters" channel out of the same contract. A game might want "first 1,000 players" treated differently from "everyone after that". An NFT project might want "OG mints" separated from secondary buyers.
Smart-contract groups support per-event filters with a small DSL. You can write rules like "events where method = mint AND blockNumber < 18500000" or "events where the from address is in this set". Each rule maps to a role in the group, and roles compose: a wallet that matches the OG-mint filter and the current-holder filter gets both roles.
Roles drive permissions in the group — who can post in which channel, who can react with which emoji, who can call which slash commands. The whole permission system is a query, not a manual grant.
A real example
A 12,000-member NFT community migrated to Sudo last quarter and shared their numbers with us. Before migration, they ran a Discord with three full-time moderators, two role-verification bots, a daily reconciliation job and a backlog of complaints about wallets that were demonstrably out-of-spec but still held a role.
After migration, the same community runs as a single smart-contract group with one moderator and zero role bots. Membership is the chain. Disputes about who is "really" a holder evaporated, because the answer is one block scan away.
The moderator team's saved time went into community work that actually moves the project forward — proposal review, contributor coordination, IRL meetups. The cumulative effect was somewhere between "felt nice" and "operationally transformative", depending on who we asked.
What smart-contract groups are not
Smart-contract groups are not the answer to every community shape. There are real limitations and they are worth being honest about.
The eligibility predicate has to be expressible against the chain. If your community is "people who finished a 12-week course we ran on Notion", the chain knows nothing about that — and a smart-contract group cannot help unless you mint a credential token for course completion (which you should consider doing).
Privacy of membership is intentionally limited. Anyone who can scan the chain can compute the membership set themselves, with or without Sudo. If you want a community whose membership is private, smart-contract groups are the wrong primitive — use a token-gated group with rotating credentials instead.
Eligibility changes can feel jarring. A wallet that sells its last qualifying NFT is removed from the group within a few blocks. We surface this in the UI ("You are no longer a member of this group because you no longer hold the eligibility token") and we do not delete message history, but the demotion is fast. Mods can configure a grace period for known-good actors if they want softer behaviour.
The indexer has limits. We index Ethereum mainnet, Base, Arbitrum, Optimism, Polygon, BNB Chain and Solana out of the box. New chains are added on a quarterly cadence. Contracts on chains we do not yet index require running a small companion indexer, which we provide as an open-source binary.
The privacy escape hatches
Some users hold their wallets pseudonymously and do not want to be auto-added to communities. We respect that.
Auto-addition is opt-in at the user level. Inside the Sudo client you can set "do not auto-add me to smart-contract groups", and the indexer will skip your wallet. You will still be eligible — you can join manually whenever you choose — but the indexer does not push.
You can also auto-mute notifications for any auto-added group. The default for new users is silent membership: you are added, the group appears in your sidebar, but nothing alerts you until you open it. Most users discover their groups gradually and engage with the ones that matter to them.
If you ever want to leave, leaving is a single tap and the indexer respects it: re-eligibility does not re-add you until you explicitly re-join.
What is next
We are working on a few extensions that will land in the next two quarters.
First, off-chain conditions through verifiable credentials. A community could require holders of a specific Sismo proof, an Ethereum Attestation Service attestation, or a Worldcoin proof of personhood without needing the underlying wallet to be public.
Second, time-decayed roles. A wallet that interacted with a contract three years ago is sometimes equivalent to a current holder and sometimes not — the community should be able to decide. We will let mods set decay curves on roles so that "OG holder" remains forever, but "active depositor" decays after a set number of inactive epochs.
Third, programmable group treasuries. The same indexer that knows who is in a group can be extended to know what the group's collective wallet looks like, opening the door to per-group governance, automated payouts to roles, and group-wide subscriptions.
Smart-contract groups are the simplest piece of plumbing in Sudo and one of the most consequential. They are how communities stop pretending to be databases and start being what they are — populations of wallets that did things together.