Search projects, hackathons, sponsors and tech

    ← All projects

    Aegis Governance

    Uniswapv4 pool governance and ENSv2 permissions enforced on-chain

    Demo

    About

    Aegis is an ENSv2-powered governance and identity layer for Uniswap v4 pools. It demonstrates how human-readable ENS namespaces can be used to represent real organizational roles, while smart contracts remain the final source of truth for permissions and enforcement. The project is built around a live Uniswap v4 pool on Sepolia, a custom HookGovernance contract, an OperatorRoleManager authorization contract, ENSv2 identities, and a Next.js/ethers frontend. Instead of managing a DeFi protocol using anonymous wallet addresses alone, Aegis gives participants readable identities such as `aegis.eth`, `operator.aegis.eth`, `alice.operator.aegis.eth`, `bob.operator.aegis.eth`, and `charlie.contributor.aegis.eth`. The key idea is that identity and authority are deliberately separated. Owning or resolving an ENS name does not automatically give a wallet administrative permissions. ENSv2 provides the identity and namespace structure, while OperatorRoleManager determines which wallets are currently authorized to perform specific governance actions. At the top of the hierarchy is `aegis.eth`, which represents the ultimate governance owner. The parent owner retains final control over the governance system and can add, remove, replace, or reactivate delegated operators. A separate delegated account, `operator.aegis.eth`, acts as an operator administrator and can manage pool operators without needing to be the ultimate owner. Below that are active pool operators such as `alice.operator.aegis.eth` and `bob.operator.aegis.eth`. These wallets are authorized through OperatorRoleManager and can pause or unpause the governed Uniswap v4 pool. The HookGovernance contract checks their current authorization on-chain before allowing those actions. This means revocation takes effect immediately. For example, the `aegis.eth` owner can remove Alice as an operator. Alice still owns and resolves to `alice.operator.aegis.eth`, but her authorization state becomes inactive. If she then attempts to pause the pool, the transaction reaches HookGovernance and reverts with `Unauthorized()`. If she is later reactivated, her governance authority is restored without needing to create a new ENS identity. Aegis also includes `charlie.contributor.aegis.eth` to demonstrate that having a valid identity inside the wider Aegis namespace does not imply governance privileges. Charlie can connect to the application, resolve his ENSv2 identity, and use the pool normally, including executing swaps, but he cannot pause or unpause the pool. A governance attempt from Charlie is rejected on-chain by HookGovernance with `Unauthorized()`. This creates a clear permission model: `aegis.eth` → ultimate governance owner `operator.aegis.eth` → delegated operator administrator `alice.operator.aegis.eth` / `bob.operator.aegis.eth` → active pool operators `charlie.contributor.aegis.eth` → identified participant with no governance authority The Uniswap v4 integration is fully functional rather than simulated. The deployed pool uses ETH and a Sepolia MockUSDC token. Users can execute a real ETH-to-MockUSDC swap through the Aegis swap router. When the pool is active, the swap succeeds. When an authorized operator pauses the pool, HookGovernance's Uniswap v4 `beforeSwap()` callback detects the paused state and reverts the swap. Once another authorized operator unpauses the pool, swaps immediately work again. This creates a simple but powerful live demo flow: swap succeeds → Alice pauses the pool → the same swap is rejected → Bob unpauses the pool → the swap succeeds again. The frontend also reconstructs the operator directory from on-chain `OperatorAdded` and `OperatorRemoved` events rather than hardcoding Alice and Bob into the interface. It then checks the current OperatorRoleManager state for each discovered wallet and resolves their ENSv2 primary names. This means the interface reflects current blockchain state rather than maintaining a separate off-chain permission database. Aegis uses ENSv2 not simply as a naming system, but as a composable organizational identity layer. A project could create a namespace such as `project.eth` and organize wallets under roles such as `security.project.eth`, `trader.project.eth`, `liquidity.project.eth`, or `agent.project.eth`, while separate authorization contracts determine what each identity is actually allowed to do. The same model can extend beyond human operators. Autonomous agents could receive readable ENS identities while being granted tightly scoped permissions such as swap-only access, liquidity management, emergency pause authority, treasury actions, or monitoring roles. Those permissions can then be revoked without destroying the agent's underlying identity. Aegis therefore demonstrates a broader design for on-chain organizations: ENS provides readable, hierarchical identity; application contracts provide revocable authorization; and Uniswap v4 hooks enforce those permissions directly at the protocol execution layer. The result is a governance system where users can understand who an account represents, what role it belongs to, and what authority it currently has, while every important permission remains verifiable and enforceable on-chain.

    How it's made

    Aegis is built with Solidity, Foundry, ENSv2, Uniswap v4, Next.js, TypeScript, ethers.js and MetaMask, with the frontend deployed on Vercel and the contracts running on Sepolia. The core architecture is: ENSv2 identity → OperatorRoleManager authorization → HookGovernance → Uniswap v4 execution. On the smart-contract side, `OperatorRoleManager` is the authorization layer. Each governance resource has a parent owner, a delegated operator admin and a set of operators. Every operator is linked to an ENSv2 identity registry and identity resource, but identity and authorization are deliberately kept separate. This means a wallet can keep its ENS identity while its application permissions are revoked or restored independently. `HookGovernance` is a custom Uniswap v4 hook. Each pool is mapped to a governance resource, and operators can pause or unpause that pool. The hook enforces the state directly inside Uniswap v4: its `beforeSwap()` callback checks the pool configuration and reverts with `PoolIsPaused()` when governance has paused the pool. The hook also checks `OperatorRoleManager` before allowing governance actions, so an inactive or unauthorized wallet gets an on-chain `Unauthorized()` revert rather than relying on frontend access control. I built a real ETH/MockUSDC Uniswap v4 pool on Sepolia and added liquidity to it. For the demo I also wrote an `AegisSwapRouter` that talks directly to the v4 `PoolManager` using the unlock flow and performs an exact ETH-to-token swap. This gave me a real end-to-end test: swap succeeds, Alice pauses the pool, the same swap is blocked by the hook, Bob unpauses it, and the swap succeeds again. ENSv2 is used for the human-readable identity hierarchy. I created identities including `aegis.eth`, `operator.aegis.eth`, `alice.operator.aegis.eth`, `bob.operator.aegis.eth` and `charlie.contributor.aegis.eth`. The parent `aegis.eth` account retains ultimate control, `operator.aegis.eth` is a delegated operator administrator, Alice and Bob are pool operators, and Charlie is deliberately identity-only. One important part of the project is proving that ENS identity does not automatically equal authority. Charlie can resolve to `charlie.contributor.aegis.eth`, connect to the application and execute a normal swap, but if Charlie attempts to pause the pool, `HookGovernance` rejects the transaction with `Unauthorized()`. Likewise, if the parent removes Alice as an operator, `alice.operator.aegis.eth` still resolves normally but Alice immediately loses governance poIr. Reactivating her restores the role without changing her identity. The frontend is built with Next.js, React, TypeScript and ethers.js. MetaMask is used for wallet connection and signing, so no private keys are stored in the application. Read-only Sepolia traffic is routed through a Next.js server-side `/api/rpc` endpoint so the upstream RPC URL is not exposed directly in the client bundle. A notable technical challenge was that this hackathon uses the dedicated ENSv2 Sepolia deployment rather than the standard ENS deployment ethers expects. I therefore construct a custom ethers `Network` and attach an `EnsPlugin` pointing at the hackathon ETH registry and Universal Resolver. That lets the frontend use normal ethers-style forward and reverse resolution while talking to the correct ENSv2 deployment. I also avoided hardcoding the operator list in the frontend. Instead, the app scans `OperatorAdded` and `OperatorRemoved` events from `OperatorRoleManager`, reconstructs the set of wallets that have participated as operators, then queries each wallet's current `operatorIdentity(...)` state. The UI therefore reflects the live blockchain rather than a local list. ENSv2 reverse resolution is then used to turn those addresses into readable names such as `alice.operator.aegis.eth`. Another slightly hacky issue was handling the difference betIen the original governance resource and normalized ENS names. The governance resource had originally been registered using the raw label `Aegis`, while standard ENS resolution expects normalized loIrcase names. Rather than redeploying the entire governance stack and pool, I preserved the existing on-chain governance resource and created normalized loIrcase forward/reverse records such as `aegis.eth` for user-facing identity. This let me keep the working deployed governance system while still presenting standards-compatible ENS identities in the UI. The admin interface reads the actual `governanceConfigs(...)` state from the contract rather than assuming who the admin is. The parent owner or delegated `operator.aegis.eth` account can remove operators, reactivate them, or add new operators with an ENSv2 identity resource. I tested this live by removing Bob with the delegated admin account and restoring him, as Ill as removing Alice with the parent and confirming her next governance attempt reverted on-chain. Using ENSv2 gave me much more than readable addresses: it gave me a hierarchical identity model that maps naturally onto an organization. Using Uniswap v4 hooks gave me an enforcement point where those governance decisions can affect protocol execution itself. Putting the two together alloId Aegis to demonstrate human-readable, hierarchical and revocable on-chain permissions without making ENS ownership itself the permission system.