(TL;DR) It is really encoding for a ETH-SHIB Reverse Jade Lizard as hinted (!)
We'll show below how it encodes for:
• 1 long put @ 7509 x 10^-12
• 1 short put @ 8070 x 10^-12
• 1 short call @ 8936 x 10^-12
2/ So first of all, let's get back to how positions are tracked by the UniswapV3Pool.sol smart contract
Any liquidity deployed by 𝚘𝚠𝚗𝚎𝚛 between a 𝚝𝚒𝚌𝚔𝙻𝚘𝚠𝚎𝚛 and 𝚝𝚒𝚌𝚔𝚄𝚙𝚙𝚎𝚛 is stored in a mapping defined by the keccak256 hash of (owner, tickLower, tickUpper)
2/ The hash returns a struct that stores several quantities, including the liquidity owned by the user.
The struct also contains information about the fees accumulated and the tokens owed to owner when the position was last touched.
3/ However, users do not directly interact with the UniswapV3Pool smart contracts.
Instead, they will mint a position by directly interacting with the NonFungiblePositionManager.sol smart contract.
The NFPM contract helps track liquidity and issues a ERC721 NFT to the minter.
4/ The minter receives a cool on-chain generated NFT that can be seen on the app.uniswap.org website.
Also, each NFT position has a unique 𝚝𝚘𝚔𝚎𝚗𝙸𝚍, which increases *sequentially* at every mint --look at the (𝚝𝚘𝚔𝚎𝚗𝙸𝚍 = _𝚗𝚎𝚡𝚝𝙸𝚍++) in the code above.
5/ In @Panoptic_xyz, users sell options by adding liquidity in a Uni v3 pool, and buy options by removing liquidity from the pool
Panoptic users "bypass" the NFPM and use instead the SemiFungiblePositionManager.sol to trade options
LPs can still use either for "vanilla" LPing
6/ One key distinction between the NFPM and the SFPM is that the SFPM issues an ERC1155 token to track users' positions.
The balance of the ERC1155 represents the amount of liquidity for that position, we call that the 𝚙𝚘𝚜𝚒𝚝𝚒𝚘𝚗𝚂𝚒𝚣𝚎.
7/ The 256bit 𝚝𝚘𝚔𝚎𝚗𝙸𝚍 of the ERC1155 position is also different: it is not sequential, but instead encodes information about the position.
It turns out that a *lot* of information can be encoded in 256bits.
8/ Back to the riddle: 282537063832542939627736618700216160083437754282540792586635888
What is encoded in that number?
First, let's look at it as a hex:
AFD2C04800AFD2808200AFD253870111
2F62F2B4C5FCD7570A70 -< 𝚙𝚘𝚘𝚕𝙸𝚍
The last 80 bits is the 𝚙𝚘𝚘𝚕𝙸𝚍
9/ The 𝚙𝚘𝚘𝚕𝙸𝚍 is the first 20 characters of the Uniswap v3 pool, and in this case, that's the SHIB-ETH-30bps, whose address is:
0x2F62f2B4c5fcd7570a709DeC05D68EA19c82A9ec
-> first 20 characters
12/ The ratios are all 1 for each leg: the position mints 1 option for each leg.
Let's unwrap Leg0: this one corresponds to a long put at strike -187080.
13/ Similarly, upwrapping Leg1 we get that it encodes for a short put at strike -186360
Leg2 encodes for a short call at strike -185340
Each leg also has a "width" of 10, which means each LP positions is 30*10 ticks wide.
14/ So, 28253706383... encodes for a specific, multi-legged option position
Decoding it revealed that it consists of a long put, a short put, and a short call in the ETH-SHIB 30bps pool.
15/ Why track position that way?
The key here is that users can 1) track complex positions using a single number and 2) they will receive a number of ERC1155 token that corresponds to the amount of liquidity deployed in that position.
16/ This also means a 4626 vault could easily be created for any options strategy
Simply point the vault to the 2825370... tokenId and all added liquidity will be automatically deployed as a Reverse Jade Lizard in the Uni v3 pool
That tokenId could also be updated over time 👀
Stay tuned for more updates about THE perpetual, oracle-free options protocol, and don't forget to follow @Panoptic_xyz for updates, AMAs, alpha leaks, and much more!
The current Uniswap UX for LPs is at a weird intersection: too complex for passive LPs and yet not feature rich enough for active LPs.
In my view, we need a separate protocol for each role —ie. we need active-passive LP separation.
Hasn’t this been tried before? Not quite👇
While several protocols have released univ3 managed liquidity vaults, such products still rely on a single (or a few) managers to handle the fund’s deployment/rebalancing.
Like most vault products, however, using a single strategy for all the funds leaves little room for error.
Even if the vault strategies find a way to perfectly optimize the entry-exit points, a single bad trade means that everyone suffers.
LPing is risky, and passive LPs should not be exposed to the same risks as active LPs.
The width of a position should match your risk tolerance. A narrow position will rapidly convert between token and ETH in a way that is similar to pin risk in options.
Use r<1.07 if active traders and 1.07 < r < 1.75 for most traders, with r=√(Pb/Pa)