{"name":"skill:uniswap-v4-hooks","files":[{"path":".imd/reads/skills/uniswap-v4-hooks.md","digest":"ebb4f11c9426c9f5ccf1c2894ec5cbe9fbc28aebc6576a10c361bb91657ffd3e","content":"# v4 Hook Generator\n\nUniswap's `v4-hook-generator` skill (MIT), imported as knowledge. Upstream drives the OpenZeppelin\nContracts Wizard's MCP tool and talks to a user; here there is neither, so read \"Scope of this\nimport\" at the end first. Where upstream wording had to change, a bracketed\n`[reworded in this import: ...]` note says what it was, and `[removed in this import: ...]` marks a\nremoval.\n\nDesign Uniswap v4 hook contracts with the decisions the OpenZeppelin Contracts Wizard encodes. This\nguide walks through selecting the right hook type, configuring permissions and utilities, and\nrecording the configuration, and you write the Solidity yourself. [reworded in this import: upstream said \"Generate Uniswap v4 hook contracts via the OpenZeppelin Contracts Wizard MCP tool. This skill guides you through selecting the right hook type, configuring permissions and utilities, assembling the canonical MCP JSON, and invoking the MCP tool to produce ready-to-compile Solidity code.\"]\n\n> **Security companion**: Hook code touches fund-handling contracts. Always apply the\n> `uniswap-v4-security` reference as soon as the hook is written to audit permissions, delta\n> accounting, and access control before deploying to any network. [reworded in this import: upstream said \"Generated hook code ... Always apply the `v4-security-foundations` skill immediately after generation\"]\n\n## When to Use This Skill\n\nUse this skill when you need to:\n\n- Scaffold a new Uniswap v4 hook contract from scratch\n- Select the right base hook type for a specific use case (fees, MEV protection, oracles, etc.)\n- Configure hook permissions, utility libraries, shares, and access control\n- Record the configuration in the Wizard's canonical JSON shape, as a compact statement of the decisions [reworded in this import: upstream said \"Produce the canonical MCP tool call JSON to invoke the OpenZeppelin Contracts Wizard\"]\n- Understand trade-offs between hook configuration options before committing to an implementation\n\n**Companion reference**: `uniswap-v4-security` — read it before writing custom logic and apply it\nagain before submitting. Hook misconfiguration can drain user funds. [reworded in this import: upstream said \"Prerequisite / companion skill: `v4-security-foundations` — run it before writing custom logic and again before deployment\"]\n\n## Hook Type Decision Table\n\nChoose the base hook type that matches your primary goal. If your hook has multiple goals, choose\nthe type that covers the most critical concern and layer additional logic on top.\n\n| Goal                 | Use Hook                   |\n| -------------------- | -------------------------- |\n| Custom swap logic    | `BaseHook`                 |\n| Async/delayed swaps  | `BaseAsyncSwap`            |\n| Hook-owned liquidity | `BaseCustomAccounting`     |\n| Custom curve         | `BaseCustomCurve`          |\n| Dynamic LP fees      | `BaseDynamicFee`           |\n| Dynamic swap fees    | `BaseOverrideFee`          |\n| Post-swap fees       | `BaseDynamicAfterFee`      |\n| Fixed hook fees      | `BaseHookFee`              |\n| MEV protection       | `AntiSandwichHook`         |\n| JIT protection       | `LiquidityPenaltyHook`     |\n| Limit orders         | `LimitOrderHook`           |\n| Yield on idle        | `ReHypothecationHook`      |\n| Oracle               | `BaseOracleHook`           |\n| V3-compatible oracle | `OracleHookWithV3Adapters` |\n\n**Selection tips**:\n\n- `BaseHook` is the general-purpose starting point — choose a specialized type only when the\n  built-in logic provides concrete value.\n- `BaseCustomCurve` replaces the entire AMM math; only use it if you are implementing a novel\n  pricing algorithm.\n- `AntiSandwichHook` and `LiquidityPenaltyHook` both address MEV but target different actors\n  (traders vs. JIT LPs). Clarify which attack vector you are mitigating.\n- `OracleHookWithV3Adapters` is appropriate when downstream integrations expect a Uniswap v3\n  `IUniswapV3Pool`-compatible oracle interface.\n\n## Minimal Decision Checklist\n\nBefore writing the hook, settle all six decisions: [reworded in this import: upstream said \"Before calling the MCP tool, confirm all six decisions:\"]\n\n1. **Hook type** — chosen from the decision table above\n2. **Permissions to enable** — only the callbacks your logic actually uses (`beforeSwap`, `afterSwap`, etc.)\n3. **Utility libraries** — `currencySettler`, `safeCast`, `transientStorage` as needed\n4. **Shares** — `false`, `ERC20`, `ERC6909`, or `ERC1155`\n5. **Access control** — `ownable`, `roles`, or `managed`\n6. **Hook inputs** — `blockNumberOffset`, `maxAbsTickDelta` (only for hook types that use them)\n\n## Permission Configuration\n\nAll 14 permission flags with guidance on when to enable each. Start with all flags `false` and\nenable only what your hook logic requires. Every enabled permission increases the hook's attack\nsurface and requires a specific bit to be set in the hook's deployed address (see address encoding\nnote below).\n\n| Permission Flag                   | Enable When                                                                                                     | Risk     |\n| --------------------------------- | --------------------------------------------------------------------------------------------------------------- | -------- |\n| `beforeInitialize`                | You need to validate or restrict pool creation params                                                           | LOW      |\n| `afterInitialize`                 | You need to set up state after a pool is created                                                                | LOW      |\n| `beforeAddLiquidity`              | You need to gate or transform LP deposits                                                                       | MEDIUM   |\n| `afterAddLiquidity`               | You track LP positions or distribute rewards                                                                    | LOW      |\n| `beforeRemoveLiquidity`           | You need lock-up periods or fee-on-exit logic                                                                   | HIGH     |\n| `afterRemoveLiquidity`            | You track position removals for accounting                                                                      | LOW      |\n| `beforeSwap`                      | You modify swap behavior, apply dynamic fees, or block                                                          | HIGH     |\n| `afterSwap`                       | You observe final swap state for oracles or accounting                                                          | MEDIUM   |\n| `beforeDonate`                    | You restrict who may donate to the pool                                                                         | LOW      |\n| `afterDonate`                     | You track donation events                                                                                       | LOW      |\n| `beforeSwapReturnDelta`           | You implement custom AMM curves or JIT liquidity (CRITICAL: NoOp attack vector — see `uniswap-v4-security` [reworded in this import: upstream named `v4-security-foundations`]) | CRITICAL |\n| `afterSwapReturnDelta`            | You extract a hook fee from swap output                                                                         | HIGH     |\n| `afterAddLiquidityReturnDelta`    | You adjust LP token amounts on deposit                                                                          | HIGH     |\n| `afterRemoveLiquidityReturnDelta` | You adjust withdrawal amounts                                                                                   | HIGH     |\n\n**Address encoding note**: Permissions are encoded as bits in the hook contract's deployed address.\nThe address must have the correct bits set at deployment time or the PoolManager will revert. Use\n`HookMiner` (from `v4-periphery`) to mine a salt that produces an address with the correct bit\npattern. Never change permissions after deployment — the address is immutable.\n\n## Utility Library Selection\n\nThree optional utility libraries can be included in the generated hook. Include only what your\nhook logic uses.\n\n| Library            | Include When                                                                                                                                                |\n| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `currencySettler`  | Your hook moves tokens between itself and the PoolManager (e.g., custom accounting, fee collection)                                                         |\n| `safeCast`         | Your hook performs arithmetic that could overflow when casting between integer types                                                                        |\n| `transientStorage` | Your hook needs to pass data between callbacks within a single transaction without persisting to storage (requires EVM Cancun or later, Solidity >= 0.8.24) |\n\n**Guidance**:\n\n- `currencySettler` is almost always needed when `beforeSwapReturnDelta`,\n  `afterSwapReturnDelta`, `afterAddLiquidityReturnDelta`, or `afterRemoveLiquidityReturnDelta`\n  are enabled — it provides `settle` and `take` helpers that implement the correct\n  `sync → transfer → settle` sequence.\n- `transientStorage` is a gas-efficient alternative to storage slots for intra-transaction state.\n  Use it to pass a flag or value from `beforeSwap` to `afterSwap` without paying 20k gas for a\n  cold SSTORE.\n- `safeCast` is advisable whenever you compute amounts derived from `int256`/`uint256` conversions,\n  especially for fee calculations.\n\n## Shares Configuration\n\nThe `shares` option controls whether the generated hook issues a token representing user shares\n(e.g., LP positions in hook-owned liquidity pools).\n\n| Option    | Description                                                                                  | Use When                                                 |\n| --------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------- |\n| `false`   | No share token — hook does not track ownership of deposited assets                           | Simple hooks that do not hold user funds                 |\n| `ERC20`   | Fungible share token — one token represents proportional ownership of all hook-held assets   | Hook-managed liquidity pools with interchangeable shares |\n| `ERC6909` | Multi-token (minimal) — one contract manages many token IDs with lower overhead than ERC1155 | Hook manages multiple distinct asset classes efficiently |\n| `ERC1155` | Multi-token (standard) — full ERC1155 with metadata URI support                              | Hook needs broad wallet and marketplace compatibility    |\n\n**Trade-offs**:\n\n- `false`: smallest bytecode, no share accounting overhead; appropriate for fee hooks and oracles.\n- `ERC20`: simplest fungible share; good DeFi composability (e.g., used as collateral).\n- `ERC6909`: gas-efficient multi-token with a minimal interface; preferred for new protocol designs.\n- `ERC1155`: widest ecosystem support (wallets, explorers, NFT marketplaces); higher gas cost per\n  transfer than ERC6909.\n\n## Access Control Options\n\nThe `access` option shapes the constructor and administrative interface of the generated hook.\n\n| Option    | Constructor Shape                                 | Use When                                                                     |\n| --------- | ------------------------------------------------- | ---------------------------------------------------------------------------- |\n| `ownable` | `constructor(IPoolManager, address initialOwner)` | Single owner controls all admin functions                                    |\n| `roles`   | `constructor(IPoolManager, address admin)`        | Multiple roles with granular permissions (OpenZeppelin AccessControl)        |\n| `managed` | `constructor(IPoolManager, address authority)`    | External authority contract governs permissions (OpenZeppelin AccessManaged) |\n\n**Guidance**:\n\n- `ownable` is the simplest — one address can perform all privileged operations. Suitable for\n  early-stage hooks and personal tools.\n- `roles` adds `ADMIN_ROLE`, `PAUSER_ROLE`, etc. via OpenZeppelin `AccessControl`. Use when\n  different team members need different privileges (e.g., a keeper bot that can update fees but\n  cannot upgrade the contract).\n- `managed` delegates all permission checks to a separate `AccessManager` contract. Use when\n  you need a unified governance layer across multiple contracts or want timelocked admin actions.\n\n> **Note**: Changing the `access` option changes the constructor signature. Update deployment\n> scripts and initialization logic accordingly. When using `ownable`, ensure the `initialOwner`\n> is not the zero address — OpenZeppelin's `Ownable` reverts on zero address since v5.\n\n## Hook Inputs Reference\n\nSome hook types accept numeric configuration inputs that tune behavior. They are the `inputs`\nobject in the configuration record below. [reworded in this import: upstream said \"These are passed as the `inputs` object in the MCP tool call.\"]\n\n| Input               | Type      | Used By                                    | Description                                                            |\n| ------------------- | --------- | ------------------------------------------ | ---------------------------------------------------------------------- |\n| `blockNumberOffset` | `uint256` | `AntiSandwichHook`, `LiquidityPenaltyHook` | Number of blocks before sandwich/JIT detection window opens            |\n| `maxAbsTickDelta`   | `int24`   | `AntiSandwichHook`                         | Maximum tick movement allowed per block before MEV protection triggers |\n\nFor hook types that do not use these inputs, omit the `inputs` field or pass an empty object `{}`.\n(The Wizard ignores unsupported inputs rather than failing.) [reworded in this import: upstream said \"Passing unsupported inputs to the MCP tool will not cause an error but the values will be ignored.\"]\n\n## Configuration Record (the Wizard's canonical shape)\n\nThe OpenZeppelin Contracts Wizard's `generate_hook` MCP tool takes this JSON. No worker has that\ntool, so do not try to call it: populate each field from your decisions above, record it in the\nREADME or your summary, and implement exactly that configuration in Solidity. [reworded in this import: upstream said \"## MCP Tool Call (Canonical) — The OpenZeppelin Contracts Wizard exposes a `generate_hook` MCP tool. ... then pass this object as the tool's argument.\"]\n\n```json\n{\n  \"hook\": \"BaseHook\",\n  \"name\": \"MyHook\",\n  \"pausable\": false,\n  \"currencySettler\": true,\n  \"safeCast\": true,\n  \"transientStorage\": false,\n  \"shares\": { \"options\": false },\n  \"permissions\": {\n    \"beforeInitialize\": true,\n    \"afterInitialize\": false,\n    \"beforeAddLiquidity\": false,\n    \"beforeRemoveLiquidity\": false,\n    \"afterAddLiquidity\": false,\n    \"afterRemoveLiquidity\": false,\n    \"beforeSwap\": true,\n    \"afterSwap\": false,\n    \"beforeDonate\": false,\n    \"afterDonate\": false,\n    \"beforeSwapReturnDelta\": false,\n    \"afterSwapReturnDelta\": false,\n    \"afterAddLiquidityReturnDelta\": false,\n    \"afterRemoveLiquidityReturnDelta\": false\n  },\n  \"inputs\": {\n    \"blockNumberOffset\": 1,\n    \"maxAbsTickDelta\": 100\n  },\n  \"access\": \"ownable\",\n  \"info\": { \"license\": \"MIT\" }\n}\n```\n\n**Field notes**:\n\n- `hook`: string — one of the 14 hook types from the decision table\n- `name`: string — the Solidity contract name (PascalCase, no spaces)\n- `pausable`: boolean — wraps the hook in OpenZeppelin `Pausable`; adds `pause()`/`unpause()` admin functions\n- `shares.options`: `false` | `\"ERC20\"` | `\"ERC6909\"` | `\"ERC1155\"`\n- `access`: `\"ownable\"` | `\"roles\"` | `\"managed\"`\n- `info.license`: SPDX license identifier — use `\"MIT\"` for open-source hooks\n- `inputs`: omit or pass `{}` for hook types that do not use `blockNumberOffset`/`maxAbsTickDelta`\n\n## Workflow: Gather → Configure → Write → Secure [reworded in this import: upstream said \"Gather → Configure → Generate → Secure\"]\n\nFollow these steps in order every time you use this skill.\n\n### Step 1: Gather Requirements\n\nInfer these from the assignment's objective and the repository; there is no user to ask, so record an assumption wherever the brief is silent: [reworded in this import: upstream said \"Ask the user (or infer from context):\"]\n\n1. What is the hook's primary goal? (Map to the decision table.)\n2. Which lifecycle events does the hook need to intercept? (Map to permissions.)\n3. Does the hook hold or move user funds? (Determines `currencySettler` and `shares`.)\n4. Who administers the hook? (Single owner, role-based team, or external governance?)\n5. Does the hook need to pass state between callbacks within a single transaction?\n6. Is this for a chain with EVM Cancun support? (Required for `transientStorage`.)\n\n### Step 2: Select Hook Type\n\nUsing the decision table, identify the single best hook type. If the goal maps to multiple types,\nchoose one and document the chosen type, the trade-offs and the reasoning. [reworded in this import: upstream said \"If the user's goal maps to multiple types, explain the trade-offs and ask them to confirm.\"]\n\n### Step 3: Configure All Six Decisions\n\nWork through the minimal decision checklist:\n\n1. Set `hook` to the chosen type.\n2. Set each permission flag — default `false`, enable only what the logic requires.\n3. Set `currencySettler`, `safeCast`, `transientStorage` based on utility library guidance.\n4. Set `shares.options` based on shares guidance.\n5. Set `access` based on access control guidance.\n6. Set `inputs` only if the hook type uses `blockNumberOffset` or `maxAbsTickDelta`.\n\n### Step 4: Write the Hook\n\nWrite the Solidity for the configuration from Step 3 yourself, to the paths the assignment allows.\nThe base hook types in the decision table are contracts in OpenZeppelin's `uniswap-hooks` library:\ninherit one only when the project already has that library, or the task may install it and commit it\nas ordinary files; otherwise build on v4-periphery's `BaseHook` and the v4-core interfaces.\n\nAfter writing it:\n\n1. Record the configuration from Step 3 in the README or your summary.\n2. Explain the key sections (constructor, `getHookPermissions`, enabled callbacks) there too. [reworded in this import: upstream said \"Step 4: Assemble and Call the MCP Tool — call the OpenZeppelin Contracts Wizard MCP tool ... 1. Display the code to the user. 2. Explain the key generated sections\"]\n3. Note any manual steps required (HookMiner for address mining, deployment script updates for\n   constructor args if `access` is `roles` or `managed`).\n\n### Step 5: Apply Security Foundations\n\nApply the `uniswap-v4-security` reference before submitting: [reworded in this import: upstream said \"**Always remind the user** — and invoke `v4-security-foundations` — before the code is deployed:\"]\n\n- Verify all enabled callbacks check `msg.sender == address(poolManager)`.\n- Review any enabled `*ReturnDelta` permissions for NoOp attack exposure.\n- Confirm delta accounting sums to zero for every execution path.\n- Run the full pre-deployment audit checklist from `uniswap-v4-security`. [reworded in this import: upstream said \"from `v4-security-foundations`\"]\n\n## Important Notes\n\n- **Access control changes constructor shape**: Choosing `ownable` adds an `initialOwner` parameter;\n  `roles` adds an `admin` parameter; `managed` adds an `authority` parameter. Update deployment\n  scripts and factory contracts accordingly.\n- **Permissions encode in the hook address**: Each enabled permission flag corresponds to a specific\n  bit in the lower bytes of the hook's deployed address. The PoolManager validates these bits on\n  every callback. Use `HookMiner` from `v4-periphery` to mine a deployment salt that produces a\n  matching address.\n- **You write the files**: nothing generates them for you. Write the Solidity to the paths the\n  assignment allows. [reworded in this import: upstream said \"MCP returns code only — it does not write files: ... You must write it to disk yourself (e.g., `packages/contracts/src/hooks/MyHook.sol`).\"]\n\n## Related Skills\n\n- `uniswap-v4-security` — **Apply this once the hook is written.** Security audit for Uniswap v4 hooks:\n  permission risk matrix, NoOp attack patterns, delta accounting, access control verification,\n  and the full pre-deployment audit checklist. Hook code should never be deployed without\n  completing this review. [reworded in this import: upstream named `v4-security-foundations`, \"Run this after generation\"]\n\n[removed in this import: pointers to upstream's `viem-integration` and `v4-sdk-integration` skills, which this catalog does not carry]\n\n---\n\n## Scope of this import\n\nThis import is knowledge only. It supplies the hook-type table, the permission, utility, shares and\naccess-control guidance and the workflow above, plus the floor suite declared in `reads`. It is not\na generator:\n\n- No MCP tools. Workers run with only their own tools and the ones the task hands them; the\n  OpenZeppelin Contracts Wizard `generate_hook` tool is not among them. Write the Solidity yourself.\n- No user to ask. Nobody answers questions or reads code shown to them during the task. Decide\n  from the assignment, record assumptions and the chosen configuration in the README or summary,\n  and put anything a person must act on there.\n- Upstream skill names map to this catalog: `v4-security-foundations` is the `uniswap-v4-security`\n  reference. Upstream's `viem-integration` and `v4-sdk-integration` have no equivalent here.\n- The assignment's objective, criteria, write budget and capabilities override this guide. It grants\n  no network, tools, keys or transaction authority, and a launch's own rules win over the options\n  above.\n\nFor IMD launches, enable and implement beforeInitialize or afterInitialize, even if your trading logic does not need it. The callback must return the correct selector and accept calls only from PoolManager. The factory deploys the hook and initializes its pool in one transaction; the required callback prevents anyone from initializing that pool while the hook has no code. A beforeSwap-only hook cannot launch. This requirement applies to new launches; historical manifests remain readable.\n\nFor IMD launches, take the PoolManager as a constructor argument and never hardcode it; in launch.json write it as \"$poolManager\". A hook that needs the launch token reads it from the PoolKey in beforeInitialize, or takes it as a constructor argument written \"$token\". The deployer fills in both for the launch's chain.\n\nFor IMD launches, the launch factory deploys the hook and calls `PoolManager.initialize`, so it is both the constructor's `msg.sender` and `beforeInitialize`'s `sender`. With `ownable` access, the `initialOwner` argument is written \"$owner\" in launch.json (the owner the request named, else the wallet that paid), never `msg.sender` or `tx.origin` (IMD's launch wallet). The factory collects the pool's fees with a zero liquidity change, which v4 treats as a removal: beforeRemoveLiquidity and afterRemoveLiquidity must let it through, return no delta for it, and have no owner switch that can block it. A hook that checks who initializes its pool takes the factory as an argument written \"$factory\". A hook that needs its launch's number, for the factory's `positionOf` or `claimFees`, takes a uint64 written \"$launchNumber\"; the deployer fills in the number the factory launches it under. Never the zero address, `0x…dEaD` or another stand-in for an address you were not given: the manifest check refuses them.\n\nOn an IMD hook launch, the LP fee is the manifest's `pool.fee`, which admission holds to the hook launch policy's tier: 12500 (1.25%) on every chain today, the fee the chain's `LaunchFees` sets for project pools, split 80% to the payer and 20% to the network; never 0 or the dynamic flag. A hook's own fee comes on top of it. \"No fees\" in a brief means no hook fee, not a zero LP fee; beforeInitialize must accept the listed fee. On a project or custom token launch the factory opens the pool at the chain's `LaunchFees` fee whatever `pool.fee` says; write the `pool.fee` the manifest assignment names.\n\nA contract that pays the PoolManager for its caller, such as a router, pulls the caller's tokens in its entry point with `transferFrom(msg.sender, address(this), amount)` (or takes `msg.value`), then in `unlockCallback`, which only the PoolManager may call, settles from its own balance: `poolManager.sync(currency)`, then `currency.transfer(address(poolManager), amount)` and `poolManager.settle()` for an ERC-20, or `poolManager.settle{value: amount}()` for ETH, which the PoolManager cannot receive by transfer. It refunds what the swap did not use. A `transferFrom` from any payer but `msg.sender`, such as one decoded from the callback data, is rejected by the verifier's Slither run as arbitrary-send-erc20 whatever gates it, and workers cannot run Slither first: four attempts from 2026-10-06 to 08 (3d06ba1a, 541703af, a7b7b7f4, e08ee63b).\n\nA hook fee paid out during the swap is paid from the PoolManager's own balance. `poolManager.take(currency, to, amount)` transfers at once, and in `afterSwap` the swapper's router has not settled its input yet, so the transfer is funded by whatever the manager already holds of that currency. On a fresh manager, or one holding less native ETH than the fee (a launch pool seeded with tokens only puts no ETH in), every fee-bearing swap reverts with `NativeTransferFailed`, although the trade itself was fine. Three auditors and the judge of a 4% ETH-fee hook launch found exactly this on 2026-10-01, and fixing it cost the job a full revision round. Do one of these from the first build:\n\n- Mint instead of transferring: `poolManager.mint(address(this), currency.toId(), fee)` credits the hook an ERC-6909 claim and needs no balance (a claims take, `CurrencySettler.take` with `claims = true`, does the same). Add a function anyone may call that unlocks the manager, burns the claim and takes the currency to the fixed recipient: redeeming needs an unlock callback, which a wallet recipient does not have.\n- When the brief asks for the fee to be sent on the swap, send it directly only when `currency.balanceOf(address(poolManager))` covers it, mint the claim otherwise, and give the recipient a way to redeem it.\n\nEither way, test a buy on a freshly deployed PoolManager whose pool was seeded with tokens only, beside the ordinary funded case. Also say in the README what happens when the recipient cannot receive ETH: a direct transfer to a contract that rejects ETH halts every fee-bearing swap, and a claim does not.\n\nOn an IMD launch, a brief's \"tax\", \"buy/sell fee\" or \"fees\" is this hook's fee on swaps, and unless it says otherwise it is settled in ETH inside the swap that paid it. Take it from the pair currency's side, never the launch token. When the pool pairs with a token rather than ETH, sell the fee for ETH on that token's ETH pool within the same unlock (exact input, bounded by an owner-set price limit, the unsold rest kept as a claim for the next swap), so no later convert call is needed and the fee never sits in a token whose price can move or whose transfers are locked."},{"path":".imd/reads/skills/uniswap-v4-hooks/LICENSE","digest":"75a59fbc77e5ff2a1442d50bb1bdf2fbd46405617fe443373455b4fa9225c40e","content":"MIT License\n\nCopyright (c) 2026 Uniswap Labs\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n"}]}