LockENS

Demo

About

LockENS turns wallet-held ENSv2 identities into access credentials that can be presented over NFC. The final demo uses one Android holder and three Android gate stands representing a Front Door, Lab and Server Room. A user selects a pass in the LockENS Android app and presents it through Android HCE/NFC. The holder signs a fresh proof with a Privy embedded wallet. A local verifier checks holder control offchain and reads the current credential state and resource permissions from ENSv2 on Sepolia before returning ALLOW or DENY. This means the same credential can remain owned by the same wallet while its global access, validity or permissions for individual resources change independently. The demo shows real NFC grant and denial flows, wallet switching, suspended credentials and resource-specific authorization. The gates are virtual interfaces rather than physical lock actuators.

How it's made

LockENS is built as an Android + NFC + Node.js authorization stack backed by ENSv2 on Sepolia. The holder app is written in Kotlin and uses Android Host Card Emulation to present the selected credential over NFC. Privy provides embedded wallets and signs a fresh resource-bound EIP-712 holder proof. On the gate side, Android devices act as persistent NFC Gate Stands for the Front Door, Lab and Server Room. A local Node.js verifier uses viem to validate the holder proof offchain and then reads the current ENSv2 state on Sepolia. ENSv2 UserRegistry establishes registration and ownership, while PermissionedResolver data provides global access and resource-level policy. The verifier only returns ALLOW when holder control and the current ENSv2 policy both pass; errors and denials fail closed. For the final four-device demo, each Android gate reaches the same local verifier through ADB reverse. We also built and validated an experimental ESP32-S3 + PN532 route during development, but the final submission uses the more reliable Android gate architecture. The notable part is that NFC presentation, wallet control and ENSv2 authorization are separate layers: possession of the phone or credential alone is not enough to open a gate. The verifier evaluates fresh holder proof plus current onchain policy for the specific resource being requested.