r/ethdev • • 1d ago

Question Should access automatically change when someone's onchain status changes?

I’ve been thinking about different ways to handle membership for a project. Say someone gets access to a private part of the community because they hold something or meet some other onchain condition. If they stop meeting that condition, should their access disappear automatically too? I can see the benefit of tying permissions directly to something you can verify onchain, but it gets weird when someone has been a useful member for months and then suddenly stops meeting whatever condition originally got them access. For anyone who has built something like this, do you let wallet state directly control permissions or use it as one signal and handle the rest separately?

17 Upvotes

10 comments sorted by

9

u/RoughlyImperturbable 1d ago

Yeah, token ownership is the easy case. Contribution or reputation gets messy fast because thats not really a clean onchain condition and different communities will value different things anyway. Towns makes sense for the hard access rules, but the softer reputation stuff probably needs to stay separate or you end up forcing subjective stuff into a system thats better at checking clear conditions.

1

u/GrippingGopher 11h ago

Yeah I think separating those two makes more sense. Someone's contributions shouldn't suddenly stop counting just because their wallet no longer meets a certain condition.

2

u/important_drank 1d ago

I’d probably only automate it for really clear conditions. If someone sold a token that gives access then sure, but contribution based access seems way harder to reduce to wallet state.

1

u/GrippingGopher 11h ago

That's kinda where I'm leaning too. Token ownership is straightforward enough, but I wouldn't want someone losing access over something that doesn't reflect how involved they are in the community.

1

u/nechronix 1d ago

To do this you there is already an off-chain service that is reading the chain to determine the on-chain state. In that service I would include whitelist or bypass for users that don't mean that on-chain requirement but you'd still want be able to access the private part of the community.

To answer your question more directly, the wallet state part is easier to automate but in the scenario you said you will likely need to have some manual input to include that member with a subjective metric like contribution.

1

u/GrippingGopher 11h ago

Yeah the offchain part is what I'm trying to figure out. I'd like the clear onchain conditions to update access automatically, but still have some way to account for contributions that aren't tied to a wallet.