E05 - Latino Winners of the Uniswap Hook
Incubator
The video, titled "E05 - Ganadores Latinos
de Uniswap Hook Incubator" (E05 - Latino Winners of the Uniswap Hook
Incubator), is an interview conducted by Camilo Sacanamboy with three
Latino developers who won the Uniswap Hook Incubator, a program by the
Uniswap Foundation and EthGlobal focused on learning and building with
Uniswap v4 Hooks.
The guests are Constantino (Mexico), Cristian (Colombia), and Camax
(Mexico), who share their journeys into the crypto world, their
experiences in the incubator, and the details of their winning projects.
1. Context and Incubator Experience
Personal Journeys: The guests have diverse backgrounds:
Cristian came from Web2 software development and discovered Web3
through communities and hackathons.
Constantino started with Bitcoin in 2016 and transitioned through
private blockchain consulting before dedicating himself to public Web3
projects and hackathons.
Camax had no technical Web2 background; he learned Solidity (Web3)
first to manage his risks as a DeFi investor.
Technical Challenges: All agreed that Uniswap v4 and the concept of
Hooks are technically complex and overwhelming, requiring them to "dust
off" advanced math and computer science concepts, such as bitwise
operations, Q-Numbers (for handling exponentials and square roots in
price calculations), and the correct configuration of liquidity pool
ticks and ranges.
2. Winning Projects (Hooks)
Each participant developed a "Hook" (a smart contract that "hooks into"
the lifecycle of a Uniswap v4 liquidity pool) to solve a specific
problem:
1. Prisma (by Cristian):
Concept: A Yield Maximizer hook.
Functionality: It automatically reinvests the fees generated by swaps
in a Liquidity Pool back into the pool itself, optimizing returns for
liquidity providers.
Challenge: Cristian faced significant difficulty in correctly
initializing the liquidity pool, ticks, and ranges to ensure swaps
executed without overflow errors.
2. Flashfy (by Constantino):
Concept: A Rehypothecation and Just-in-Time Liquidity (JIT) hook.
Functionality: It allows the Liquidity Provider's (LP) capital to be
deposited into other tokenized "vaults" (like Aave, Morpho, etc.) to
generate secondary yield. The hook only withdraws the liquidity from
the vault and injects it into the Uniswap v4 pool at the exact moment a
swap occurs (JIT), securing the swap commission, and then returns the
capital to the vault to continue generating yield.
Motivation: To optimize the opportunity cost for LPs and give greater
utility to capital that would otherwise be idle or subject to
impermanent loss in an inactive price range.
3. Simbi (by Camax):
Concept: Also a Rehypothecation and Just-in-Time Liquidity hook, but
specifically focused on integration with Aave.
Functionality: Similar to Flashfy, it routes liquidity to the Aave
protocol, ensuring the user can retain Aave functionalities (like
borrowing against the deposited collateral) and Uniswap features (like
choosing tick ranges).
Challenge: Ensuring accuracy in calculating active liquidity and
neighboring ranges so that the hook injected the exact amount of
liquidity at the moment of the swap and maintaining the alignment of
Aave's and Uniswap's accounting.
3. The Future of Hooks and DeFi
The participants agree that Uniswap v4, with its Hooks, represents a
tremendous opportunity for innovation, transforming Uniswap into a kind
of "operating system" for building new DeFi protocols.
Customization and Fragmentation: Hooks eliminate the need to "fork"
(copy and modify) the entire Uniswap code to make a small optimization.
Now, a Hook is enough to customize fees, liquidity logic, rebalancing,
etc. This should reduce liquidity fragmentation in the ecosystem.
TradFi Integration: There is great potential for using KYC (Know Your
Customer) Hooks, combined with technologies like Zero-Knowledge Proofs,
to allow DeFi to meet the regulatory requirements of the traditional
financial system (TradFi) without compromising user data privacy.
Opportunity for Latin America: The region, with its specific financial
needs, is well-positioned to find problems to solve and use this new
technology to create solutions with a global reach.
Uniswap V4; with a focus on
Uniswap Hooks
Directed at developers and programmers interested in the technical
architecture and features of Uniswap V4, focusing on the new Hooks
mechanism.
Uniswap V4 introduces significant architectural changes to its
Automated Market Maker (AMM) design, primarily centered around Hooks,
which are external, user-defined smart contracts that execute logic at
various points during a pool's lifecycle. These hooks allow for
on-chain customization of liquidity pools, enabling features like
dynamic fees, custom order types, or external oracle integrations that
were previously infeasible or required complex external routing.
A major innovation is the Singleton contract design, where all
liquidity pools reside within a single contract instance. This
approach, combined with a Flash Accounting system, drastically improves
gas efficiency, particularly for multi-hop swaps. Instead of
transferring tokens between dozens of external contracts, V4 tracks net
balance changes (Deltas) internally, minimizing external calls and
reducing transaction overhead [04:08].
To facilitate complex on-chain calculations, V4 mandates the use of
Q64.96 fixed-point notation for handling prices and liquidity
calculations. This numbering system is essential for accurately
representing the square root operations required by the concentrated
liquidity math in Solidity, circumventing the language's limitations
with floating-point precision [12:16]. Furthermore, V4 introduces
support for ERC-6909 Claim Tokens as an optimization. This allows
high-frequency traders and market makers to defer actual ERC-20
transfers—creating internal credit balances via minting and burning—to
avoid the unpredictable and often high gas costs of transferring
certain tokens that include custom logic or security checks [07:11].
The integration of custom logic follows a strict flow managed by a
Locking Mechanism. When an external router calls a function on the V4
core, the core executes an internal Unlock Callback back to the router,
ensuring the atomic execution of swaps and related logic under the
single contract. This process is where Hooks are triggered. Developers
can enable specific Hooks—such as beforeSwap, afterSwap, or returnDelta
(the No-Ops hook)—using a Hook Address Bitmap, which encodes the
enabled entry points into the pool's deployment address. The
returnDelta hook is particularly powerful, allowing the hook contract
to modify the final balance change of the swap, enabling custom fee
collection or token distribution [18:13].
A practical application demonstrated is the AMM Hook, which implements
an auction for the pool manager role, allowing the winning manager to
set dynamic swap fees for a defined period [23:26]. While this
optimizes returns for liquidity providers, it highlights potential
security and decentralization trade-offs. The architecture is
vulnerable to increased sandwich attacks or centralization risk, as the
pool manager possesses the unique ability to execute zero-fee swaps,
giving them an arbitrage advantage over external users who must pay the
dynamic fee [26:17]. Developers must carefully design and audit Hook
logic to maintain security and fairness within their custom V4 pools.
Developing a Hook on
PancakeSwap Infinity
PancakeSwap Infinity V4 Hooks: A Developer’s Guide
V4 Architecture Overview (Three Layers): PancakeSwap V4 (Infinity)
features a highly gas-optimized, three-layered architecture:
Accounting Layer (Vault): A single Vault contract stores all tokens
across all pools, enabling net settlement and reducing gas costs
significantly via "Flash Accounting."
AMM Type Layer: The architecture is now extendable, supporting new AMM
types without protocol re-implementation. V4 launches with Concentrated
Liquidity (similar to V3) and Bin Pool (utilizing an x+y=k model within
discrete price bins).
Hook Layer: This layer allows developers to extend pool functionality
using external smart contracts (Hooks) that are called back at specific
transaction points.
Hooks as Callbacks (Gating Logic): Hooks are external contracts that
execute logic at 10 possible callback points (before and after) across
5 key actions: Pool Initialization, Swaps, Liquidity related
(add/remove), and Donate.
Immutability of Permissions: Callback permissions (which hooks are
active) must be defined during pool initialization
(getHookRegistrationBitmap) and cannot be changed afterward. This
ensures consistent pool behavior.
Swap Execution Flow (Key Integration Points): When a user performs a
swap, the PoolManager is called. The PoolManager checks the hook
permissions and executes the logic:
It calls beforeSwap() if registered.
It performs the main swap logic.
It calls afterSwap() if registered.
The hook can perform any custom logic, including reverting the
transaction to prevent a swap.
Data Flow in beforeSwap():
This function expects three return values: a selector, beforeSwapDelta
(for taking/giving tokens before the swap calculation, often fixed
amounts), and LPC_OVERRIDE (a flag used to override the default swap
fee).
Data Flow in afterSwap():
This function is crucial for logic dependent on the swap outcome. It
includes the balanceDelta (the actual amount in/out of the swap) in its
parameters.
It expects two return values: a selector and an amount for
unspecifiedCurrencies (the token that was not a specified input
amount). This is used to transfer extra tokens to the user.
Example Implementation: V-KICK Membership Hook: The demo shows how to
implement a hook that provides 0% swap fee and 5% extra token out for
V-KICK holders:
afterInitialize: Used to decode and store the intended default swap fee
and the promotion end date from the hookData.
beforeSwap: Used to check the V-KICK holder status and the time,
returning the LPC_OVERRIDE flag to set the fee to 0%.
afterSwap: Used to calculate the 5% bonus from delta.amountOne. The
hook then calls key.currency1.settle() to transfer the extra 5% to the
Vault, and the Vault eventually nets the settlement with the user.
Development Setup: Developers can use the provided Hook template
repository, which is compatible with Foundry. The template provides
necessary helper methods and contracts (BaseHooks, PoolC/PoolBin),
facilitating the testing of callback assertions.
Exploring Hooks on
Uniswap V4, for Developers/Programers
Exploring Hooks on Uniswap V4: A Developer's Summary
V4 Architectural Foundation (Gas Efficiency): V4 is an extension of V3,
maintaining concentrated liquidity, but centralizing all tokens in a
single Vault contract (Singleton pattern). This architectural change,
dependent on EIP-1153 (T-Store), is the pillar for substantial gas
optimization, especially for multi-hop swaps [01:30].
Hooks Definition and Role: Hooks are external user-defined smart
contracts that act as plugins, allowing developers to inject custom and
executable logic into V4 liquidity pools [02:00].
Callback Execution Points: Hooks are called by the central PoolManager
contract at specific points in the pool's lifecycle: before/afterSwap,
before/afterAddLiquidity, before/afterRemoveLiquidity, and at pool
creation [02:21].
Developer Use Cases (Flexibility): Hooks transform Uniswap into a
development platform. Use cases include:
Implementation of On-chain Limit Orders (LP positions that
automatically unwind) [02:59].
Custom oracles (price tracking in afterSwap) [02:30].
Lending protocols and permissioned DEXs [03:23].
Custom AMM curves and fee mechanisms [03:46].
Dynamic Fee Hook Walkthrough (Example): The demonstration focused on
creating a hook to charge a fee (1%) only on Token0-to-Token1 swaps:
Interface: The hook must inherit IDynamicFeeManager and implement the
getFee() function, which returns the fee value in uint24 (e.g., 10,000
for 1%) [10:00].
Logic (T-Store Concept): the beforeSwap() function is used to check
swapParams.zeroForOne and update an internal state variable with the
trading direction. This is an ideal use case for Transient Storage
(T-Store), a new type of temporary storage with high gas efficiency
[19:17]. Fee Update: In beforeSwap, the hook calls
poolManager.updateDynamicFee(key) [23:21]. This forces the PoolManager
to call the hook's getFee() function, which returns the correct fee (1%
or 0%) based on the saved state [24:36].
Deployment and Configuration: For the PoolManager to recognize the
dynamic fee, the pool creation must use the FeeLibrary.DYNAMIC_FEE_FLAG
flag in the fee parameter, instead of a static value [40:47].
Key Developer Resources: Essential tools for bootstrapping and testing
are the V4 Template (a Foundry repository with testing helpers) and V4
By Example (a website with practical code snippets for various V4
functionalities) [51:00]
Damian Rusinek - Secrets
of Uniswap V4: A Deep Dive into Hooks Security
Uniswap V4 Hooks Security: A Deep Dive for Developers/Programers
(Summary of Damian Rusinek's presentation)
V4 Architectural Shift: Uniswap V4 adopts a Singleton architecture
where the Pool Manager contract manages all pools. This replaces V3's
one-pool-per-contract model.
Gas Optimization: Key to V4's efficiency is Flash Accounting and
dependency on EIP-1153 (T-Store), which introduces very cheap,
temporary storage (tstore/tload).
Hooks Mechanism: Hooks are external, user-controlled smart contracts.
They act as plugins called by the Pool Manager via callbacks before or
after critical pool operations (e.g., initialization, liquidity, swap).
Pool Operator Role: The Pool Operator is a helper contract (like the
Router) that initiates interactions with the Pool Manager on the user's
behalf. This contract often receives the unlockCallback.
Security Threat 1: Unprotected Hook Functions: Hook callbacks (e.g.,
beforeInitialize, beforeSwap) are external and can be called directly
by an attacker if unprotected.
Case Study: Initialization Override: Calling an unprotected
beforeInitialize directly can override the pool’s internal state, such
as creating a new ERC-20 liquidity token, effectively locking the
existing LPs' funds.
Protection 1: Pool Manager Restriction: All hook functions must be
restricted to be callable only by the trusted Pool Manager address to
prevent malicious external manipulation.
Security Threat 2: Pool Operator Callback Abuse: The Pool Operator's
unlockCallback—where it receives and processes user data—must also be
protected by checking if the caller is the Pool Manager.
Security Threat 3: State Overwriting in Multi-Pool Hooks: If a single
hook contract is designed to manage multiple pools, it must use
mappings (mapping(PoolKey => PoolData)) to store pool-specific data
(price, block number, etc.).
Protection 3: Mapping Required: Failure to use mappings means a second
pool initialization will overwrite the storage variables of the first
pool, leading to state corruption and transaction reverts for the
original users.
Security Threat 4: Sender Impersonation: In callbacks like afterSwap,
the sender parameter passed by the Pool Manager is the Pool Operator
contract, not the end user.
Mitigation 4: Hook Data Verification: If a hook needs the original
end-user's address for access control or logic, it must retrieve it
from the hookData parameter passed by a trusted Pool Operator. An
untrusted Pool Operator can send a victim's address in hookData to
steal funds via malicious operations executed on the victim's behalf
Security Threat 5: Dangerous Dynamic Fees: Dynamic fee logic must be
robust. If a calculation error causes the fee to exceed 100%, the pool
will permanently revert on all swaps, effectively rendering the pool
unusable
Security Threat 6: Upgradeable Hooks: Avoid making hook contracts
upgradeable. An upgradeable hook's logic can be changed by the owner to
include malicious functionality, such as draining the liquidity held by
the hook itself (if it acts as a Pool Operator).
Best Practice: Developers must ensure their hook's immutability (unless
explicitly justified and well-audited) and perform comprehensive
testing against reentrancy and manipulation attempts.
Security considerations
when building Hooks in Uniswap V4 | Jota Carpanelli (OpenZeppelin)
The presentation by Jota Carpanelli from OpenZeppelin dives into
essential security considerations for developers building custom
"Hooks" within the new Uniswap V4 architecture.
Uniswap V4 introduces a single Pool Manager contract utilizing
transient storage, which allows state to be preserved only for the
duration of a transaction, following an unlock call and concluding with
a lock. This structure facilitates flexible, complex, and gas-efficient
interactions.
Hooks are smart contracts that developers deploy to execute custom
logic immediately before or after core pool operations like swap,
initialize, or add/remove liquidity. They can implement almost any
feature, from simple oracles and advanced access control to full
lending/borrowing protocols. This immense flexibility, however,
introduces significant security surface area.
Key Security Considerations for Developers:
1. Multi-Pool Management: A single Hook contract instance can be used
by multiple pools. If a Hook stores pool-specific data in a non-mapped
storage slot, a call from one pool (Pool B) could inadvertently
overwrite the critical state data set by another pool (Pool A) [08:31].
Fix: Use mappings to properly manage and separate storage for each
interacting pool.
2. Access Control: All Hook functions are external and thus callable by
anyone, not just the Pool Manager [09:20]. An attacker could call an
exposed function to override a pool's storage state or configuration.
Fix: Implement an onlyPoolManager modifier to restrict critical
state-modifying functions to calls originating from the official Pool
Manager [10:11].
3. Logic and Bug Checks: Standard smart contract bugs, such as writing
a = b instead of a += b, are common in Hooks and can lead to unexpected
loss of data (e.g., overriding rewards instead of accumulating them)
[11:11].
Action: Treat Hook code as a critical protocol component and ensure
rigorous audits and testing [11:33].
4. Unexpected Reverts and DoS: A seemingly innocuous check or an
external call in a Hook function (e.g., beforeRemoveLiquidity) that
consistently reverts can lead to a denial of service, effectively
locking liquidity providers' capital indefinitely [12:19].
Action: Ensure paired operations (add/remove, etc.) remain functional
and resilient against external failures.
Further Risks: Developers must guard against classic DeFi exploits,
including: Arbitrary external calls (allowing token draining) [13:04],
Upgradability risks (if the hook is upgradeable without a secure
process) [13:25], Inefficient code (leading to high gas costs) [14:19],
and all forms of Oracle price manipulation [14:28]. Hooks essentially
allow a developer to build an entire new protocol, inheriting all the
known security challenges of DeFi [14:43].
Integrate Uniswap v4 (Trade logic and v4
Hooks)
The video details the Uniswap V4
architecture, a decentralized AMM protocol that allows the swapping of
ERC-20 tokens via liquidity pools. The highlight is its modularity and
the concept of Hooks, which offer contract-level logic extensibility.
I. V4 Contract Architecture
V4 uses a non-upgradable contract model, with its key components being:
Pool Manager: The main contract that governs the creation and
management of all liquidity pools, in addition to coordinating swap
operations.
Universal Router: The entry point for executing swaps and other
interactions, consolidating commands into a single transaction.
Quoter: Used to obtain price quotes before a real transaction, allowing
cost simulations using staticcall to prevent state changes.
State View: Provides an efficient way to query pool data, such as
existence, price, and liquidity, using the Pool ID as a unique
identifier.
Position Manager: Deals with the liquidity lifecycle (addition,
removal, fee claiming, burning of LP positions, which are represented
as NFTs).
Permit2: Essential for the swap flow, as it manages and authorizes user
token approvals so that the Universal Router can spend them.
II. The Innovative Concept of Hooks
Hooks are external contracts attached to a pool at the time of its
creation, allowing developers to inject custom logic (in Solidity) at
specific moments in the pool's lifecycle.
Lifecycle Events:
Hooks are triggered through standardized (fixed-name) functions before
or after critical events:
beforeSwap / afterSwap: To apply logic such as dynamic fees,
validations, or reward incentives after the swap.
beforeAddLiquidity / afterAddLiquidity: To implement requirements or
rewards for Liquidity Providers (LPs).
Others: The system covers events like initialization, liquidity
removal, and donations.
Development Flexibility:
Advanced Customization: Hooks enable complex use cases such as On-Chain
Limit Orders, volume- or volatility-based fees, and custom rewards.
Sync Swap Hooks: Allow developers to completely replace Uniswap's
internal core swap logic, enabling fully customized accounting systems.
Implementation: The developer deploys their Hook contract with the
standardized methods and passes its address as a parameter when
creating the pool via the Pool Manager.
The video concludes by demonstrating the integration flow: getting the
quote via the Quoter, approving the spend via Permit2, and finally,
executing the swap by encoding the command (e.g., swapExactInSingle)
for the Universal Router.
Secure By Design: Intro to Formal
Verification for Uniswap v4 Hooks with Certora
The session opens by framing the challenge
of building secure Uniswap v4 hooks — custom contracts that execute at
defined points in the pool lifecycle, such as beforeSwap, afterSwap,
beforeAddLiquidity, and afterAddLiquidity. Hooks extend the core
protocol, allowing developers to add dynamic fees, liquidity
management, or MEV-related logic, but they also expand the attack
surface and introduce new correctness risks.
Formal verification is presented as a step beyond traditional testing.
Unlike fuzzing or unit tests, which only sample inputs, formal
verification mathematically proves that defined properties hold for all
possible program states. Using the Certora Prover, developers can
specify and check invariants, pre- and post-conditions, ensuring their
hook logic behaves safely under all execution paths.
The video walks through how Certora works: developers write a formal
specification describing expected behavior — for example, ensuring
total token deltas net to zero after a swap — and the prover
automatically validates the contract against that specification. The
goal for Uniswap v4 hook authors is to verify critical invariants such
as correct delta settlement, absence of unauthorized calls, and no
state corruption between pools.
Pool creation in Uniswap v4 binds a specific hook address to the pool
identity, so hook logic directly affects core operations. A misbehaving
hook can revert transactions, freeze liquidity, or break pool solvency
if it mishandles virtual balances. Examples are shown where fuzz tests
failed to catch corner cases that formal verification later revealed —
such as hooks starting with non-zero token balances that produced
inconsistent deltas.
The instructor emphasizes that formal verification requires developers
to clearly define assumptions, constraints, and safety guarantees.
Overly narrow specs can miss bugs; overly broad ones can produce false
positives. Key design guidelines include enforcing msg.sender ==
poolManager checks, isolating state per poolId, validating token
addresses and fee tiers, and ensuring all deltas are settled before
transaction completion.
Good hook design is modular: internal bookkeeping and external
interactions should be separated to ease reasoning and verification.
Since hooks are executed within the atomic transaction of a pool
operation, developers must also handle rollback semantics and avoid
re-entrancy or recursion loops.
Certora’s workflow integrates into CI pipelines: specifications are
written alongside Solidity code, automatically verified on each update,
and counterexamples are analyzed through detailed state traces.
Developers are encouraged to iterate between refining specs and fixing
code until all properties are proven.
Formal verification doesn’t replace audits or fuzz testing — it
complements them. Fuzzing helps discover performance and gas edge
cases, while verification mathematically ensures functional
correctness. The combination provides both empirical and formal
confidence before deployment.
Throughout the video, examples of practical specs are given, such as
“After any beforeSwap hook execution, the pool and hook token balances
must net to zero” or “Only the PoolManager can invoke hook
entrypoints.” These rules formalize the intended invariants and are
enforced by the prover.
The presenter underlines that every deployed hook becomes part of
Uniswap’s trust surface. Publishing specifications and verification
results signals security maturity to LPs and integrators. When hook
logic changes, verification must be re-run to maintain validity of
guarantees.
Common risks discussed include reverts that freeze pools, incorrect
delta reconciliation leading to insolvency, and inefficient gas usage
causing transaction failures. Hooks must also handle flash accounting
correctly — ensuring temporary balances reconcile to zero within a
single atomic operation.
In closing, the session reinforces that Uniswap v4 hooks are powerful
primitives enabling innovation but demanding rigorous correctness.
Developers are urged to adopt formal verification early, write modular
and auditable code, define clear invariants, integrate the Certora
Prover into continuous development, and treat security as part of
design, not as an afterthought. The takeaway: a well-specified,
verified hook is safer, composable, and more trustworthy in the
high-value DeFi environment.
Introduction to Uniswap v4: Hooks,
Singleton Architecture & More | Octant DeFi Devs Day
The
presentation, "Introduction to Uniswap v4: Hooks, Singleton
Architecture & More," delivered at the Octant DeFi Devs Day,
introduced the key innovations of the newest version of the Uniswap
protocol. The Uniswap Foundation supports the ecosystem’s growth,
decentralization, and sustainability across five pillars: protocol
innovation, developers, governance, research, and security.
The Uniswap protocol functions as a peer-to-peer system designed for
exchanging ERC20 tokens. The evolution of the protocol was highlighted,
starting with V1 in 2018, which allowed ETH-only token trading with
fixed fees. V2, launched in 2020, expanded to ERC20-to-ERC20 trading,
still using fixed fees and a constant product curve.
A major shift came with V3 in 2021, which introduced concentrated
liquidity. This innovation allowed liquidity providers (LPs) to set a
specific price range for their liquidity, significantly improving price
execution for traders and enhancing profitability for LPs compared to
V2's full-curve deployment.
Uniswap V4 introduces several new features, including the Singleton
Architecture, continuous fee spectrums, flash accounting, and, most
notably, Hooks.
The Singleton Architecture simplifies the protocol by managing all
pools within a single contract. This approach drastically increases gas
efficiency for users. For developers, creating a new pool is no longer
a deployment of a new contract but a state update, which slashes the
average deployment cost.
The continuous fee spectrum gives developers the freedom to implement
dynamic fee structures, moving away from the fixed fee tiers of earlier
versions.
Hooks are external contracts or "scripts" that modify a pool's behavior
by executing custom logic at specific points in the swap
lifecycle—before or after key actions like initializing a pool,
adding/removing liquidity, or executing a swap. There are 14 different
hook functions available. Crucially, while a single pool can only
utilize one hook, that single hook can serve multiple pools, fostering
powerful composability across the ecosystem.
The speaker offered several inspiring ideas for implementing Hooks in
the public goods space during the hackathon. These included
implementing adaptive fees based on network volatility or congestion,
setting lower swap fees for tokens tied to social impact causes, and
automatically redirecting a portion of trading fees to public goods
funds. Other ideas involved triggering micro-donation functions upon
adding liquidity or ensuring yield farming rewards go only to
consistent participants, discouraging flash liquidity provision.
The main call-to-action for the Octant hackathon participants was to
focus on the implementation of existing hooks—leveraging resources like
the OpenZeppelin Hook Library—rather than building them from scratch,
to bring novel public goods solutions to life using V4’s new
capabilities. The session concluded with practical advice for hackers,
emphasizing clear communication, strategic use of libraries, and a
focus on explaining the core idea.