Hookable

The protocol for configurable hooks on Pons, built around native @Uniswap v4 liquidity.

CA: 0xebfe1c9ac846c5d3bbef0a08fccbc698ded4f516

[Hookable @HookableXYZ]

https://t.co/h2RnghP9Cu

[Hookable @HookableXYZ]

Hookable’s two staking modules distribute different assets. ETH staking streams collected creator-fee revenue; Buyback & distribute uses its allocation to buy the launch token on its Pons market, then streams those tokens to stakers. Each path has a separate contract and its rewards depend on actual funding and participation.

https://t.co/ZFlp1Edq2G

[Hookable @HookableXYZ]

V1 and V2 launches stay on the contracts they started with. V3 adds four modules for new Pons launches, while the project page continues to show each token's own allocations, controls and on-chain activity. New features can extend the launch flow without changing an existing project's settings.

https://t.co/tc0vEltlyq

[Hookable @HookableXYZ]

We are also exploring a fee-funded community grants mode. The design needs to settle who can receive funds, how allocations are chosen and what each claim proves before it belongs in the launch builder. We want the rules and funding path to be inspectable from the start.

https://t.co/fwgWwdkLiT

[Hookable @HookableXYZ]

One area we are exploring next is liquidity management around Pons markets. Before it becomes a Hookable module, we need to verify what Pons v4 permits and define how funds enter, move through a strategy and return. The contract path has to be clear before the feature is ready.

https://t.co/ngtvDZzBOE

[Hookable @HookableXYZ]

A launch's module shares are set before creation and must add up to 100%. V3 routes each share into its own accounting path, while the gateway version keeps existing launches on their original rules. Adding a module to the builder does not rewrite an older token's contracts.

https://t.co/Ehv4grVhGD

[Hookable @HookableXYZ]

Buyback & distribute keeps fee-funded token rewards separate from ETH staking. The keeper buys on the launch's registered Pons curve or graduated Uniswap v4 pool, then sends the tokens to a dedicated staking contract for 24-hour reward streams. Each purchase uses a fresh quote, minimum output and deadline.

https://t.co/xgaThYJNQd

[Hookable @HookableXYZ]

Burn rewards use a fixed ETH budget for each round. Participants choose how many tokens to burn; when a 1 to 30 day round closes, claims are proportional to each wallet's share of the tokens burned in that round. Fees received after it opens are held for a later round, so the current budget cannot change mid-round.

https://t.co/9TcJVmBfxj

[Hookable @HookableXYZ]

Contributor vesting routes its launch allocation into scheduled tranches. The keeper can fund a new tranche from available fees once a day; each tranche then vests linearly over the duration set at launch, and up to eight contributor wallets claim independently. Later fees do not reset earlier schedules.

https://t.co/RYmZptI8fh

[Hookable @HookableXYZ]

Holder rewards are built around a specific snapshot. Hookable records the block, builds a holder manifest from transfer history, and binds each claim to the chain, launch, round, wallet and amount. The creator publishes the root, so a proof confirms that a claim is included, not that the creator's allocation is fair.

https://t.co/zM8jvqjHlP

[Hookable @HookableXYZ]

The public docs don’t list a future roadmap. The project notes name four ideas under consideration, so we’ve framed them as exploration rather than promised features:

Hookable’s eight live modules cover buybacks, burns, staking, holder rewards, vesting, revenue sharing and treasury allocations.

Beyond those, we’re exploring liquidity management around Pons markets, community grants, paired-asset treasury support and sponsored transactions. These are design candidates, not modules in the builder yet; each needs a clear funding path, contract rules and permission model before it ships.

Liquidity automation in particular depends on confirming what Pons v4 allows. We’ll add a mode when its full flow can be defined and verified on chain.

https://t.co/cG89BqftZD

[Hookable @HookableXYZ]

GM

Since launch, we’ve shipped shareable project pages, on-chain activity feeds, cached creator stats and keeper automation with capped gas budgets. V3 adds four modules to the original four: holder rewards, buyback & distribute, contributor vesting and burn rewards.

All eight are configurable around Pons launches on Robinhood Chain. Tokens stay on their original Pons curve and Uniswap v4 graduation path, with fee allocations fixed at launch. V3 contracts are deployed and source-verified.

[Hookable @HookableXYZ]

Hookable V3 is live for Pons launches on Robinhood Chain.

Creators can now choose from eight fee-funded modules. The four new options are:
- Holder rewards: fund ETH rounds that holders claim through creator-published snapshot proofs.
- Buyback & distribute: buy the token on its original Pons curve or graduated Uniswap v4 pool, then stream the tokens to stakers.
- Contributor vesting: route fees into scheduled claims for up to eight contributor wallets.
- Burn rewards: let participants burn tokens and claim a pro-rata share of a fixed ETH round budget after it closes.

These join buyback & burn, ETH staking rewards, treasury and revenue sharing. Creators set the fee allocations at launch, and those shares are fixed in the launch contracts. Existing V1 and V2 projects keep their original rules.

We built around Pons because its launch and graduation flow already connects tokens to their market. Hookable adds configurable fee mechanics around that lifecycle, without moving the token to a separate pool.

The V3 contracts are deployed and source-verified. No V3 user token has launched yet; this update is about the modules now available to configure. Try it now:

https://t.co/yy363d62Lg

[Hookable @HookableXYZ]

Hookable gives trading activity a way to fund what comes next for a token: buybacks, holder rewards, contributor payments or a development treasury, using the creator fees its Pons market already generates.

That’s where we see the positives for the ecosystem: creators can commit revenue to useful mechanisms at launch, while communities can inspect the allocation and follow its execution on-chain.

The value still depends on trading activity and how the project uses those funds; the contracts make that relationship explicit and verifiable.

[Hookable @HookableXYZ]

The on-chain activity feed is now live on Hookable. Open a launch’s Activity tab to follow fee collections, buybacks and burns, reward streams, claims and treasury releases, with amounts, timestamps and a direct link to each transaction.

Communities can now follow how a token’s configured hooks have operated over time alongside its current balances and revenue allocation, all from the public project overview.

https://t.co/GMJose0EXw

[Hookable @HookableXYZ]

Next on Hookable: an on-chain activity feed for each launch, bringing fee collections, buybacks, burns and reward funding into its public overview.

Each entry will link to the transaction behind it, so communities can follow how a token’s configured hooks are being used over time, alongside its current balances and revenue allocation.

[Hookable @HookableXYZ]

Next on Hookable: an on-chain activity feed for each launch, bringing fee collections, buybacks, burns and reward funding into its public overview.

Each entry will link to the transaction behind it, so communities can follow how a token’s configured hooks are being used over time, alongside its current balances and revenue allocation.

[Hookable @HookableXYZ]

Hookable's latest update makes each launch easier to inspect and share: its public link opens the configured revenue split, current module balances and the addresses behind them.

Creators can send the same overview to their community, while holders can check the contracts before connecting a wallet. Staking and payout sections appear for the modules that launch actually enables, keeping the interface tied to its configuration.

https://t.co/tc0vEltTnY

[Hookable @HookableXYZ]

When reading a Hookable launch, its allocation and its execution history tell you different things:

• Revenue allocation shows how collected creator fees are divided.
• Available for buybacks shows ETH assigned to future purchases.
• Tokens burned shows the token amount already bought and sent to the burn address.

A 50% buyback allocation describes the rule; the balances show what has actually happened. Open the public overview and follow its contract links to inspect that distinction for each Hookable launch.

https://t.co/tc0vEltTnY

[Hookable @HookableXYZ]

Before a V2 buyback is signed, Hookable's keeper simulates the purchase to estimate token output, applies its slippage limit, then simulates the transaction again with that minimum output and a deadline.

The revenue contract enforces those execution limits on-chain. A fill below the minimum or a transaction arriving after its deadline reverts; a successful simulation does not guarantee that market conditions will remain unchanged before inclusion.

[Hookable @HookableXYZ]

Revenue sharing on Hookable gives each configured recipient a separate ETH balance to claim. When creator fees are collected from Pons, the revenue contract credits those wallets according to the shares fixed at launch.

A contributor can claim their accrued share without waiting for the creator to distribute it manually, and one recipient leaving funds unclaimed does not block the others. The same launch can reserve the rest of its creator revenue for buybacks, staking rewards or its treasury.

[Hookable @HookableXYZ]

Shareable project overviews are now live on Hookable. Open a launch and select Share project to send its community straight to the revenue allocation, module balances and on-chain addresses, with no wallet connection required to view them.

Contract links sit alongside the figures, so holders can follow the token, revenue and staking contracts directly from the same overview. Connect a wallet when you want to stake, claim or use the controls available to you.

https://t.co/tc0vEltTnY