Today, the common way to gate an area of a world is an asset that stores a password string inside Udon. If the world's assets are ripped, that password is recovered directly.

Hashing or obfuscating it does not fix this. As long as the comparison happens client-side in Udon, it can be defeated by decompiling the Udon program or editing memory. Anything shipped to the client is not a secret.

Why existing features don't cover this

Group and Invite+ instances gate the whole instance, not a specific area inside a world.

Persistent data (PlayerData) is readable and writable from Udon, so it can't hold a secret.

There's no way for someone other than the instance creator to grant access dynamically (e.g. adding event staff on the day).

Request

An Udon-callable API where verification happens on VRChat's servers. Possible shapes:

Secret comparison API — the world author registers a secret through the website/SDK; Udon submits an input string and receives only a boolean. The secret itself never ships in the world assets.

Per-world server-side key-value store — writable by the author only, not readable from Udon, exposing comparison results only.

Per-instance access tokens that can be issued and validated server-side.

Any one of these would let creators build access control without placing a secret in the world at all.

Use cases

Staff-only backstage areas at events; green rooms before doors open

Supporter-only content gates

Puzzle and escape rooms where the answer shouldn't be recoverable by ripping the world