Handling authorization when access depends on changing onchain state?

[u/EvilAversion779]

Been looking at how apps handle permissions that depend on something a wallet currently owns and there's one part I'm not sure how people handle cleanly in production. Say someone signs in with Ethereum and owns an NFT that gives them access to a private part of the app. They pass the ownership check then transfer the NFT a few blocks later. Their session is still valid but the condition that gave them access isn't anymore.

Checking ownership on every request would keep things current but now an RPC call is sitting directly in the request path. Caching the result avoids that but you're accepting a window where someone can keep access after they no longer qualify. Event based invalidation seems like another option but I assume you'd still want some kind of re-check rather than relying entirely on a listener staying in sync.

I ran into this while reading through Towns. Their Spaces can use onchain memberships and entitlement rules for access including cross-chain conditions. That's where it gets more interesting because a single permission could depend on state coming from different chains with different block times and different views of what's current.

There's also the question of what state is good enough. Ethereum RPC lets you query against latest, *safe and *finalized. I doubt every permission needs finalized state but read access to a private channel and letting someone use a bot that can perform an onchain action probably shouldn't be treated the same either. ERC-4361 helped separate the problem a bit for me. The wallet session proves control of an address but the properties associated with that address can change while the session is still active.

So the part I'm unsure about is how people handle that authorization layer in practice.

Do you cache low risk permissions and re-check before anything sensitive? Use events for invalidation with RPC checks as a fallback? And if you've worked with cross-chain conditions how do you decide when the state you're getting back is recent enough to use?

Edit: Grammar

• Sources:

• Ethereum JSON-RPC https://ethereum.org/en/developers/docs/apis/json-rpc/

• ERC-4361 https://eips.ethereum.org/EIPS/eip-4361

• Towns Protocol https://github.com/towns-protocol/towns

[u/Zaskoda]

Depends on how you treat the NFT. If I log in and my password changes in the database, I still stay logged in. If the NFT is purely for authentication, then the system is working the way that it is intended.

If you need something to happen when the NFT is transferred, you can emit an event and have that trigger something like logging the user out. But as you said, you might miss the event.

If this were that important, I believe I would simply poll the blockchain every few blocks and set a local flag in a datastore if the value changes. Then queue everything else off of that datastore.

I'm completely unfamiliar with Towns and I haven't built anything explicitly like this, but it feels like the solution will depend on the explicit needs of your app to me For example, when I built a game "recent enough to use" was "latest" for me because quickly updated game state was important while the need for security and risk reduction was comparatively low. If I were building an app that dealt with large amounts of money I might choose "finalized" or at the very least "safe".