Unichain Satisfy is deployed on Unichain Sepolia and Unichain mainnet as the primary execution environment. The Uniswap v4‑style hook (SatisfyHook), policy engine, adapters, automation module, and timelock are wired to Unichain’s PoolManager and are deployed via deploy_unichain.sh. The repo includes deployment artifacts and a unichain_smoke.sh script that runs governance role checks, policy evaluation, and a real‑data replay against Unichain RPC, plus CI lanes that target Unichain smoke and replay using recorded fixtures.
Reactive Network Satisfy’s SatisfyAutomationModule exposes a REACTIVE_EXECUTOR_ROLE and a set of reactive* functions (reactiveSetEpoch, reactiveSetPolicyActive, reactiveSetPoolPolicy, reactivePauseAll, etc.) that are designed to be driven by Reactive jobs. Reactive Network (or a similar automation layer) can submit replay‑protected jobs that adjust policy windows, pool→policy routing, hook caller allowlists, or emergency pause state. This lets policies and epochs evolve based on off‑chain signals while keeping the actual updates bounded, on‑chain, and single‑use via the module’s job‑consumption logic.
Github:https://github.com/cryptanu/Satisfy Slides: https://gamma.app/docs/Minimum-Disclosure-Maximum-Coordination-sytnpr17ne5a5u2?mode=doc Project Link: Demo Video:https://kommodo.ai/recordings/iSR1kwvOFjE4XpY5wxMO?uploadId=2YHVxhkCJCQOZbqOnAmH
I wanted a way to gate swaps and liquidity inside the hook on verifiable proofs (e.g. World ID, attestation bridges) with minimum disclosure, so policy looks like “this proof satisfies the condition” rather than “this address is on a list.”
Incentive programs and access‑controlled DeFi flows are still mostly address‑based, which makes them trivial to farm with cheap wallets and hard to align with real‑world credentials. DAOs launching liquidity incentives get botted within minutes; allowlists don’t help because they key off addresses, not what a participant can actually prove.
Satisfy makes Uniswap v4‑style markets credential‑aware without changing core pool math: proofs are evaluated at beforeSwap / beforeAddLiquidity, and if policy fails the transaction reverts. The design is modular—adapters for World ID and Self, a general SatisfyPolicyEngine, and a hook that routes pools to policies—so DAOs can combine multiple proof sources with AND/OR logic, replay protection, and pausability.
Automation and governance: making the SatisfyAutomationModule powerful enough for real operations (epoch changes, pool -> policy routing, emergency pause) but constrained via roles and one‑shot reactive jobs so misconfiguration or replay can’t silently corrupt policy.