Radius

Demo

About

Most networks — corporate offices, university campuses, co-working spaces, event venues — still run on shared passwords, manual key distribution, and flat access for everyone. There's no per-person policy, no isolation between roles, no audit trail, no revocation without a full credential reset. Identity is an afterthought bolted on after the fact, if at all. **Radius** is an identity-gated network and API access control system. Any organization with an ENS name can use it — a company, a university, an event venue. Your ENS subname becomes the sole credential for everything: WiFi admission, bandwidth tier, sponsor or internal API access, SSH. The subname carries your role, your access policy, and your device group in ENS text records. The infrastructure reads ENS instead of a password database. No VPN client, no RADIUS server, no manual provisioning — mint a subname, walk in, connect. The system enforces access in three layers: a captive portal gates WiFi entry and assigns per-role bandwidth tiers at the kernel level, a resource proxy intercepts every API call and injects keys server-side so credentials are never exposed to end users, and an operator console lets administrators define groups, set per-identity and per-group daily quotas, rotate keys atomically, and revoke sessions in real time. Every admission, every proxied request, every quota check is logged against a session identity — not a bare IP — giving operators the first real audit trail without a dedicated security appliance. Critically, Radius gives everyone on the network a usable, role-appropriate slice of real bandwidth — so nobody has to fall back to their mobile hotspot. Role-based VLANs mean a staff member or VIP gets a dedicated high-bandwidth lane, isolated from general attendee traffic, while basic users get a fair share without being able to saturate or snoop on each other. One shared network, properly segmented — the way it should have always worked. The demo targets a crypto hackathon, but the enforcement model is identical for a corporate office, a university lab, or any physical location where identity-based access control matters.

How it's made

**1. Mint at check-in.** Every attendee gets a subname under the event domain — `philo.tokyo2026.ethglobal.eth`. The organizer writes their role, bandwidth policy, SSH public key, and device group directly into ENS text records. No database entry. No password issued. The subname *is* the credential. **2. Captive portal reads ENS, not a password DB.** When a device connects to the event WiFi, it hits the captive portal. The attendee signs an EIP-191 challenge with their wallet. The portal resolves the signing address to an ENS subname, reads the `wifi-tier` and `wifi-bandwidth` records, and maps them to an access group. That's the only auth check. **3. Network enforcement runs at the kernel level.** Login triggers two things instantly: an `iptables` rule marks the device's traffic with an fwmark tied to its tier, and a `tc HTB` class enforces bandwidth — 5 Mbit for basic attendees, 10 Mbit for staff, 1 Gbit for VIP. Cross-tier `FORWARD DROP` rules prevent devices on different tiers from reaching each other at all. Device isolation is structural, not policy — there's nothing to misconfigure. **4. A resource proxy injects API keys server-side.** All sponsor API access goes through a proxy layer. Attendees never see the keys. The proxy reads the active session, checks group membership and daily usage counters, then forwards the request with the key injected — into the URL path, query param, or header depending on the upstream. Limits are per-device and per-group, adjustable mid-day without a restart. Key rotation is atomic: stage a new key, commit it — zero downtime, old key invalidated in one swap. **5. The full audit trail is automatic.** Every proxied request is logged against a session UUID (never a bare IP). Organizers see per-person API usage, bandwidth consumed, login/logout times — in real time, via the operator console. Nothing requires manual instrumentation.