rewall

Demo

About

Rewall is a serverless, on-chain secret management infrastructure. On Rewall, secrets are shareable by design. We use ENSv2's subname architecture for storing secrets and granting access. You share secrets by naming who may read them, and you take these permissions back by rotating the key. There are no accounts and no server in the middle. Nobody but the ENS names you chose can read a secret, and Rewall itself has nothing to read it with. In order to prove the strength of our design, we have tackled three privacy problems, and in one of them, we brought a whole new perspective to on-chain transfers: semi-confidential transactions. Rewall allows you to make confidential token transfers and share the details with whoever you grant access to. That means that while a third party can see your transfer, even the token receiver may not know who made the transaction as long as you do not give them permission. At its core, every person, team, and machine is represented by an ENS name that publishes a public key. A secret, such as an API key, password, private key, or two-factor authentication seed, is encrypted locally and stored as ENS text records under a subname you own, such as <provider>.rewall.alice.eth. Each secret is encrypted once with a randomly generated key. That key is then sealed separately to each authorized reader's public key, creating one small record per reader. Access is not something a centralized server checks. You either hold a sealed copy of the key or you do not. Revoking access means encrypting the secret again under a new key and sealing that key only for the readers who should retain access. Entire teams can also be granted access through subtree grants on parent ENS names. Rewall also introduces a recovery model without relying on a centralized custodian. A secret can have a recovery holder, such as a cold-wallet ENS name, or a group of guardians who each hold a piece of a recovery key. This means losing a wallet does not necessarily mean losing the secret. We also applied this architecture to two-factor authentication. Rewall can securely store 2FA seeds and generate live authentication codes while keeping the underlying seed encrypted and under the user's control. A browser extension can fill sign-in codes only on the exact site associated with the account. Another major use case is AI agents. Rewall allows an AI agent to use a secret without ever seeing the secret itself. Through the MCP server, the secret is decrypted inside the server process, used to perform the requested action, and then removed from the response. The agent receives only the result, with the sensitive value redacted. This means an AI agent can work with API keys, credentials, and other secrets without being able to expose, log, remember, or leak them. Around the core protocol, Rewall includes a dashboard at rewall.me for storing, sharing, revoking, managing secrets, managing live 2FA codes, and making private payments. A TypeScript SDK powers the rest of the ecosystem. The MCP server provides secret-safe access for AI agents, while the browser extension handles site-specific authentication. Rewall also includes a Chainlink CRE workflow that opens a secret inside an enclave and returns only a digest, as well as Ledger Key Ring enrollment that allows a server without a USB connection to join a key ring after explicit approval from a human on the Ledger device. If you want to learn everything about Rewall, refer to docs.rewall.me. It is our official documentation. We explain eight runnable examples, and refer to an Agent Skill that teaches AI assistants how to build on top of Rewall complete the project. Simply run `npx skills add oynozan/rewall --skill rewall`

How it's made

Rewall is built directly on ENSv2 on Sepolia. Each account owns a single PermissionedResolver, deployed through ENS's VerifiableFactory and reused across every name the account controls. This works because records inside the resolver are keyed by the namehash of the full name, so records belonging to different names cannot collide. A user's namespace, such as rewall.alice.eth, lives inside a UserRegistry controlled by that user, allowing new secrets to be created directly as subnames without involving a third party. Every read goes through UniversalResolverV2, following the standard ENS resolution path. Every write is a single PermissionedResolver multicall containing the encrypted blob, sealed data keys, reader lists, and the owner's signature in one transaction. Write delegation for an individual secret, or even an individual record key, is handled through ENSv2's Enhanced Access Control. Read access is deliberately not represented as an on-chain role: it is enforced entirely through cryptography. Names are registered through the Sepolia ETHRegistrar using its commit-and-reveal flow. Contract interaction is implemented directly with viem and typed ABI fragments using parseAbi, with interfaces verified against deployed bytecode. We avoid relying on ensjs for the protocol path because its registration flow targets a registry that the canonical ENSv2 root does not point to. The cryptography is deliberately built from standard, well-understood primitives. A user's identity key is deterministically derived from a single EIP-712 signature. The signature is reduced to canonical r and s values, hashed with SHA-256, and used as the material for an X25519 private scalar. The same wallet therefore derives the same encryption identity every time without permanently storing the key. Secret values are encrypted with AES-256-GCM under a randomly generated data key. Before encryption, values are padded to a multiple of 256 bytes so that the ciphertext length does not reveal the approximate size of short credentials such as passwords, API keys, or 2FA seeds. The secret's own ENS name is bound into the ciphertext as authenticated data, preventing an encrypted blob from being copied to another name and successfully opened there. A key commitment stored inside the encrypted blob additionally ensures that only the intended data key can decrypt it. The data key is then sealed independently for every authorized reader using libsodium sealed boxes. Readers therefore never share a common private key, and adding a reader does not require re-encrypting the underlying secret. The owner also signs the reader lists together with the public key approved for each ENS name. This prevents a delegated writer from modifying the reader set to add themselves and then waiting for the owner to perform a future rotation. Revocation is cryptographic rather than administrative. The secret is encrypted under a fresh data key and that new key is sealed only for the readers who should retain access. No server has to enforce the decision. Recovery follows the same model. Guardian recovery uses Shamir secret sharing, with individual shares sealed to each guardian's ENS identity. Guardians re-seal and publish their shares on-chain for a replacement wallet, and recovery succeeds only when the reconstructed key produces the expected published public key. This allows wallet recovery without introducing a centralized recovery authority. The Rewall dashboard is a Next.js application using Privy for wallet connection. The derived identity key remains in memory for the active session and is never sent to the backend. A small set of server routes sponsors the initial ENS name registration and resolver deployment from a sponsor wallet. MongoDB is used only as the sponsorship spend ledger; those routes never receive or process secret material. The TypeScript SDK, built on viem and libsodium, is the canonical implementation of the protocol. The dashboard, MCP server, browser extension, integrations, and examples all build on the same SDK rather than independently implementing Rewall's encryption or ENS logic. The MCP server allows AI agents to use credentials without giving the model access to the credential itself. It supports both stdio and Streamable HTTP transports and enforces a host allowlist independently for each secret. It rejects IP literals and redirects to prevent destination bypasses, scans returned data for the secret across multiple encodings, and redacts any matching value before the result reaches the model. Just as importantly, the MCP server exposes no general-purpose signing capability. An AI model is never allowed to choose an arbitrary payload for the connected wallet to sign, because doing so would allow it to request the EIP-712 identity message itself, derive the user's encryption key, and gain access to every secret. The agent can use an authorized secret for a specific operation, but it cannot obtain the secret, the identity signature, or the underlying private key material. The browser extension is built with WXT. It detects one-time-password fields using heuristics modeled after Chromium and fills codes only when the current hostname exactly matches the hostname associated with the stored credential. Unlike the web dashboard, the extension can persist the identity key locally, but only in encrypted form under a user-provided passphrase. This makes 2FA another direct application of the same architecture. A TOTP seed can live as an encrypted Rewall secret, be shared or revoked using ENS identities, and generate authentication codes without exposing the underlying seed to a centralized password manager, application backend, or AI agent. ENS provides the naming, ownership, storage, and access-control foundation of the system. The ENS name is simultaneously the identity of a user, the namespace containing their secrets, the location of the encrypted records, and the reference used to determine who receives sealed access to them. Chainlink CRE extends that model into confidential computation. A CRE handlerInTee workflow reads Rewall's ENS records through the DON and decrypts the secret inside a trusted execution environment. The same sealed-box and AES-GCM construction is reimplemented using noble cryptographic primitives because the QuickJS runtime does not provide WebCrypto. The workflow can operate on the plaintext inside the enclave and return only the permitted result, such as a digest, without exposing the secret outside the TEE. Chainlink's Compliant Private Transfer architecture also forms the privacy rail behind Rewall's pay-by-name and semi-confidential transfer design. Its Sepolia vault and ACE policy engine provide the foundation for private transfers, while the current integration uses a local rail as a temporary substitute where the upstream indexer is unavailable. Semi-confidential transfers add selective disclosure on top of the private payment itself. The transfer can remain confidential while its receipt is represented as a Rewall secret. The sender then chooses exactly which ENS identities receive the sealed keys required to inspect that receipt. Transaction privacy is therefore not reduced to a binary choice between public and private: disclosure becomes programmable per participant. Ledger integration uses the Key Ring Protocol through the Device Management Kit. The enrollment flow runs against Ledger's genuine app-ledger-sync firmware inside the Speculos emulator, allowing the complete ceremony to be demonstrated end to end, including explicit human approval on the simulated device screen. This enables a server without direct USB access to become part of a hardware-backed key ring without weakening the approval model. Several infrastructure constraints also required protocol-level workarounds rather than mock implementations. ENSv2 does not currently provide subname enumeration, so Rewall maintains a single rewall.index record through the SDK and uses it to discover the secrets belonging to a namespace. Ledger tooling required inspecting the private wallet CLI implementation to confirm that its transport could not reach the emulator directly. The documentation stack also required correcting a Windows-specific Turbopack alias generated by Nextra. The documentation itself is built with Nextra and Mermaid, and the project includes runnable examples alongside an Agent Skill that can be installed with a single npx command to teach compatible AI assistants how to build against Rewall. Across all of these components, the same principle remains unchanged: ownership and metadata live on ENS, access is expressed through cryptography rather than a centralized authorization server, and sensitive material is revealed only at the exact point where it is required.