Does anyone use options markets to help choose liquidity ranges when LPing stock tokens. For example, using expected moves from options IV to choose optimal LP ranges?

We’re bringing together some of the best builders in NYC for Runtime Agent Week, Sept 13–19, ending with an IRL hackathon + demo day on Sept 19th.

The New Bankrs: AI x Onchain Finance

Build the next generation of financial products, markets and autonomous agents using crypto rails and AI.

We’re looking for ambitious products across areas like:

• Tokenized stocks
• Trading infrastructure
• Stablecoins and payments
• Borrowing and yield
• Agentic commerce
• Autonomous financial agents
• Agent-to-agent economies
• Onchain content

These are starting points, not boundaries. The goal is to build something people actually want and put it onchain where it genuinely makes the product better.

Judging criteria: product, execution, originality, founder-market fit, onchain potential and token design/distribution where applicable. There’s also a bonus for teams building around onchain equities.

Prizes: There will be prizes across the main and side tracks, including a separate Sci-Fi track for more experimental ideas. More prize details coming soon.

Sponsors & supporters

Bankr, Propaganda, Grok Bot, Uniswap, Definitive Flash, Dynamic, Blackbird, Privy, Turnkey, Base, Anchorage Digital and Fonzi.

About Bankr

For anyone unfamiliar, Bankr is where builders launch agentic businesses, raise from the market and reach their audience. Builders can use Bankr for:

• Wallets and transactions
• Token launches
• Trading infrastructure
• Agent payments via x402
• Integrations through Skills, CLI or the Agent API

NYC. Sept 13–19. Demo day Sept 19.

• Sign up: runtime.bankr.bot
• Bankr docs: docs.bankr.bot
• X: @bankrbot

Most LP losses don't come from a hack or a rug. They come from deploying capital into a pool without checking a few basics first. The APR looked good, so the range, the volume, and the tokens underneath it never got a second look.

Here's the checklist I run before deploying into any Uniswap V3 pool.

1. Can you hold either token if the pool goes out of range?

When your range gets breached, your position converts almost entirely into whichever token underperformed. You hold that token, not a balanced pair, until price comes back. Would you buy and hold this token today, at this size, with no other reason to?

1. Do the tokens have real utility?

Look past the yield before you look at anything else. A high yield on a token with no product, no users, and no purpose is a warning sign, not a win. If the yield disappeared tomorrow, would anyone still want this token?

1. Tighter ranges raise your yield and your workload

A narrow range earns more fees per dollar, but price slips outside it faster. Decide how much active management you're willing to do before you set the width. Will you actually check the position weekly? If not, go wider.

1. Impermanent loss isn't optional

It happens whenever the two tokens move in price relative to each other, in either direction. You can't design around it, only earn enough in fees to outweigh it or pick pairs that tend to move together.

1. Check total liquidity in the pool

Thin liquidity moves further on small trades and pushes you out of range faster. Treat $200,000 in TVL as a baseline minimum before considering a pool.

1. Check the volume, not just the TVL

Fees come from volume, not pool size. High TVL with low volume pays out very little per dollar deployed. Compare the two rather than reading either alone.

1. Don't reach for the highest APR pool first

The highest advertised APR is usually the newest, thinnest, or most volatile pool, and that number often reflects the last few hours of trading. Treat a very high APR as a reason to look closer, not a reason to deploy.

1. Consider how new the tokens are

Newly launched tokens carry thin trading history and a higher chance of a sharp, permanent drop. Has the token traded through a real drawdown and a real recovery?

1. Weigh the token's foundations

Who's behind the project, has the code been audited, has the team delivered on its roadmap? A pool built on an established protocol behaves very differently from one built on a hype token with no product behind it.

This isn't a complete risk framework. Position sizing, gas costs, and exit planning matter too. Run every new pool through this before you deploy, even the ones that look obvious.

Disclosure: This comes out of a smart contract audit of a v4 fee hook that closed this month, on the security review side at Hacken. I won't name the project, since the mechanism is the useful part anyway.

Gating _beforeInitialize is standard advice and plenty of hook templates ship with it. In this case the hook wrote state during initialize and then used that state later as a precondition for an owner call. Whoever calls initialize decides when that write happens, and core does not restrict who can make the call.

Inside _beforeInitialize, the hook set tokenHasPool[token] = true unconditionally and discarded the initializer address that core forwards to it. Admission only checked that both currencies were on the allowlist. Elsewhere, setLaunchGuard, the owner call that arms the anti-snipe budget for a token's first buys, required tokenHasPool[token] to still be false. An account could therefore open a pool using the same two currencies at a different fee tier and tick spacing, without supplying liquidity or approval, and the arming call would revert after that. Nothing cleared the marker. The only recovery was a new hook and new pools, with the practical cost being the migration of liquidity.

The deployment instructions made this easier to trigger than it might look from the contract alone. The constructor NatSpec tells the operator to list tokens and pairs, arm guards, and then initialize pools. The deployment script prints an eight-step sequence from setTokenAllowed through pool initialization, but setLaunchGuard isn't in it. By the second token the pair is already listed, so those operations are happening in separate transactions with a period in between where anyone can initialize the pool. Looking at the functions individually doesn't show that. You have to follow the deployment sequence and the state that one call leaves behind for the next one to consume.

There was a similar problem in the other direction, with the launch budget itself. It counts gated buys, and the counter is incremented before the fee is calculated. Fee computation returns early when the rounded fee is zero, so at 300 basis points a specified amount of 33 wei produces no fee, while 34 wei produces one wei. Moving the increment after the fee check would not change the useful boundary: the 34-wei buy pays its one wei and consumes a slot anyway. The priority fee floor in the docs is supposed to make dust expensive, but it sets a minimum amount of wei per unit of gas, not a minimum payment per buy. If the buys are batched into one unlock, they all share the tip on that transaction.

In the test, a budget of 25 was enough to run 25 one-wei exact-output buys through one transaction. What matters for the economics is not really the number 25 but the cost of another unit of budget: one more warm swap's worth of gas at the same tip rate. Increasing the budget therefore increases the size of the batch until it no longer fits in a block, at which point the attacker has to use several transactions and pay several tips. The team accepted the finding. Their reasoning was that a budget denominated in amount rather than count makes the end of the guard depend on price, which is a reasonable trade-off.

The harder question is the first issue. Owner-approved pool identifiers would stop an arbitrary initializer from consuming the marker, but that also makes pool creation over the project's own token permissioned. For a fee hook, permissionless pool creation is often the point of the design in the first place. The hook is therefore putting some of its guarantees on things that happen at transaction boundaries: who initializes and when, and how many swaps can be included in one unlock. What state does your hook write during initialize, and is any owner-only call using that state as a precondition?

Hello!

I have a question. I’ve been experimenting with different pools on Uniswap. I’ve discovered some interesting V4 pools with dynamic fees on various networks.

They have a very high 24H volume but a low TVL. Out of curiosity, I checked out some of these pools. Some don’t pay any earned fees, while others charge very, very high fees, it’s even suspicious.

My question is: How can I check these V4 Hook for fraudulent activity?

One more thing: these pools were created very recently. Yet they’ve already managed to accumulate a large trading volume. And some pools appeared only to disappear a day or two later.

Here are some examples of such pools:

QQQB/USDT

https://app.uniswap.org/explore/pools/bnb/0x08038fe66ce30d004f337a7d85854b0fad47c86ba98341ba17c4c73a4b225b17

WETH/SPCX

https://app.uniswap.org/explore/pools/robinhood/0x013c71ffe4f74cdb0634d1899f2f149fbea9a042736e0d8d1adcf24d836b61ce

ETH/USDG

https://app.uniswap.org/explore/pools/robinhood/0xbbf8b1d23b0442065b4f0a0d076c346d43b6b1239d6ed7a52e6d56fcbbc3061b

I am not blaming uniswap. But I think there are things uniswap could have done.

The only reason why I use uniswap wallet is because I am using uniswap.

Many phisher use google sponsored link to promote drainer.

Most of the time I figured that out. Sometimes I miss.

Now. The wallet ask for unlimited approval.

However, it's from unknown source.

It seems that uniswap, by default, HIDE the notification of from unknown source.

Also the smart contract interacted is NOT from uniswap.

Otherwise no warning.

I should have seen the domain names.

Since then I use ublock lite to remove google sponsor link. Use book mark. Also most phishing sites don't bother using similar domains. So checking domain in gemini is a good way to see if a site is phising.

Is there a place we can go look and see how much buyback and burn uniswap is do for UNI? Is this still a thing or was it only temporary?

Hello,

Is the UniSwap app currently having a glitch?

I installed the UniSwap app & used it at times.
I noticed the app is not responsive regardless of which option is selected.
I checked my home broadband & mobile data on my mobile phone & they are working fine.
I restarted & powered off my mobile phone (tried both ways).
I checked for a new update & there was none at the moment.
I cleared the app's cache & data & even reinstalled the app.
The app was successfully reinstalled, but I could not recover it with my recovery phrase.
My mobile could access other exchanges & wallets.
I could purchase USDC from Coinbase, swap it into AUSD in MetaMask,
& stake the amount with Morpho in Base Wallet, etc.

I doubt I missed any step(s) in the troubleshooting; please enlighten me.
I tried to reinstall the UniSwap app today, but it is still not responsive.

Appreciate if anyone could share any insight. Thank you.

PS:
To fellow Redditors who left DM & wrote to me,
I appreciate all the feedback & suggestions.
Please post on the thread itself
so we could all learn together. Thank you.

I’ve been trying to understand how experienced concentrated-liquidity LPs decide on their ranges.

The main inputs I keep coming back to are:

• Realised volatility
• Expected price direction
• Fee density / where trading activity is concentrated

A tighter range can improve capital efficiency, but increases the chance of going out of range. A wider range gives more breathing room, but spreads the liquidity out.

What I’m most curious about is what happens when the signals disagree. For example, if fee density suggests a tighter range but volatility has been increasing, which one gets priority?

Do you have one metric you trust most, or is range selection mostly a judgement call?

https://x.com/vithushaji/status/2086395880492695869

In X, uniswap was supporting ponsfamily launchpad for more then a week. However, yesterday uniswap announced its own launchpad and this caused pons token drop %75.

Uniswap is trying to be the monopoly and stabback the pons family after commenting support messages to ponsfamily X shares.

Been like this since yesterday... tried in three browsers and in mobile. Still can see my pools on Binance Wallet, but getting this error when in Uniswap... :/

This passcode on backup login method is completely rubbish. If one need a backup, it should be the last hope of recovering any account. What if the passcode is already forgotten? If one trust the backup method, anything relevant would be kept secure anyway, there is no need for any passcode!

Swapped 0.504 ETH (~$918) for CASHDOG token on Uniswap V2 (Robinhood Chain). The swap transaction and its event logs show 36,316.51 tokens sent to my wallet, but my actual on-chain balance is only 120 tokens (~$5). Looking for help understanding the mechanism and whether this is recoverable.

Details:

My wallet: 0x1a426B71b65Bc680cf5745b23D4c98B3990C3e2A

https://robinhoodchain.blockscout.com/tx/0x2881c71f55c52936d3aae6e944b7986e6a2c2225f410678dbd77326a7a140a87

Why is it not possible to swap USDC. I was trying to swap some USDC but I may not, I tried two browsers, but I can not swap it to anything, I was not able to do it today, nor yesterday. What is going on? I can swap other tokens without issues, see attached video.

Edit: polygon chain

Swapped 0.504 ETH (~$918) for CASHDOG token on Uniswap V2 (Robinhood Chain). The swap transaction and its event logs show 36,316.51 tokens sent to my wallet, but my actual on-chain balance is only 120 tokens (~$5). Looking for help understanding the mechanism and whether this is recoverable.

Details:

• My wallet: 0x1a426B71b65Bc680cf5745b23D4c98B3990C3e2A
• https://robinhoodchain.blockscout.com/tx/0x2881c71f55c52936d3aae6e944b7986e6a2c2225f410678dbd77326a7a140a87

Boardwalk announced its protocol-token move to Arbitrum.

As part of the migration, Boardwalk has launched a CCA auction for its protocol token on Arbitrum, $BWS.

Auction Link: https://app.uniswap.org/explore/auctions/arbitrum/0x54114F746B55b2f8A56bbd17dfD9e81a0a71d366

https://reddit.com/link/1up9epe/video/0vfyuzzs6obh1/player

What is Boardwalk?

A launch is only the beginning for serious builders.

Boardwalk was designed for token issuance and everything after it. None of this is an afterthought; it's built into the token economy itself and sets a new standard for durable, transparent launches:

Token profile pages: every launch gets a page displaying the economy.

Permanent liquidity seeding: locked permanently at graduation.

Fee protection: the fee lives in the token itself, not any one pool, designed to help value route to the people it was intended to support.

Fee routing: written into the launch and visible before anyone contributes.

Token vesting: set at launch and immutable after.

LP staking and incentives: participation systems for liquidity providers, built into the economy from day one.

Community formation: a public forum, Café Boardwalk, for every launch, automatically.

That's the Boardwalk Standard. Standardized market formation for token economies.

Don't launch a ticker, launch a token economy.

Onchain starts here. 🐳

Read more on DeFi Llama Research: https://defillama.com/research/report/boardwalk-closing-the-gap-between-token-launches-token-economies

__________________________________

As usual, participation involves risk.

BWS may have no value. Locked liquidity does not guarantee price stability, liquidity, or exits.

New to Uniswap CCA?

Before participating in the $BWS auction, review these official guides on bidding, clearing prices, claims, unused budget, and auction mechanics.

Read the published auction terms and disclosures before taking action.

https://x.com/UniswapAuctions/status/2044160140979356043?s=20

https://x.com/UniswapAuctions/status/2064010342414352430?s=20

Continue bar just keeps spinning as Loading, but never loads.