Content pfp
Content
@
0 reply
0 recast
0 reaction

lucky pfp
lucky
@lsankar.eth
https://x.com/Fiskantes/status/1861434712180592906 this is a good point. feels like a fundamental limitation on clanker coins that they can't be recovered if dev becomes unresponsive/too rich from fees to respond
2 replies
5 recasts
26 reactions

Jack Dishman pfp
Jack Dishman
@dish
token requestor / beneficiary will be able to claim fees directly from the locker with our next iteration of contract changes!
1 reply
0 recast
2 reactions

lucky pfp
lucky
@lsankar.eth
Isn’t the token requestor/beneficiary always the initial deployer? it’d be cool if there were a way for large holders to reset the address
1 reply
0 recast
1 reaction

Jack Dishman pfp
Jack Dishman
@dish
the current contracts have clanker as the deployer and requestor/beneficiary because of the salt in the deployToken method: https://basescan.org/address/0x250c9fb2b411b48273f69879007803790a6aea47#code#F1#L1 that'll be changed soon, after testing. RE: reset addr - curious what scenario this would be useful for
1 reply
0 recast
1 reaction

lucky pfp
lucky
@lsankar.eth
I mgiht be misunderstanding. I thought `_deployer` here: address lockerAddress = liquidityLocker.deploy( address(positionManager), _deployer, defaultLockingPeriod, tokenId, lpFeesCut ); is the address associated with the fc account who deployed (?) in which case, CTOs (community takeovers) are challenging. this feels like it's emerged as a valuable phenomenon in the sol meme world
0 reply
0 recast
0 reaction