Skip to content

feat: LiquidityParty updated adapter#1005

Open
timolson wants to merge 10 commits into
propeller-heads:mainfrom
Liquidity-Party:main
Open

feat: LiquidityParty updated adapter#1005
timolson wants to merge 10 commits into
propeller-heads:mainfrom
Liquidity-Party:main

Conversation

@timolson

Copy link
Copy Markdown
Contributor
  • The swap() interface has changed, so a new Executor will need to be deployed.
  • The Substreams adapter handles Killed events by setting all pool token balances to zero. If we have to disable a pool, this workaround prevents solvers from attempting a swap that would revert, without us needing to support PC deletion.
  • swapToLimit() is no longer supported and was removed from the SwapAdapter.
  • swapAmounts() moved from PartyPool to PartyInfo
  • The new test pool has only 3 tokens instead of 10 for faster test runs.
  • Tightened bounds on LiquidityPartyExecutorTest with the exact amount outs expected.
  • Other trivial updates to contract addresses, swap test amounts, etc. PartyPoolSwapImpl is called PartyPoolExtraImpl now.
  • No major flags from slither just a loop warning
  • I absolutely could not get integration testing to run because Substreams keeps rejecting my JWT token for some reason. I created fresh ones. I used the CLI. I even tried hitting the API directly. Nothing. This happened to me before, and it's hella frustrating. Yes, I'm using JWT from The Graph and not API tokens from substreams.dev. All of the tests for each component pass, so I'm assuming integration testing will work, too.

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

Comment on lines +243 to +267
.for_each(|component| match components_store.get_last(&component.id) {
None => {
substreams::log::info!(
"killed component not found in store: {}",
component.id
);
}
Some(tokens_str) => match decode_addrs(&tokens_str) {
Err(e) => {
substreams::log::info!(
"failed to decode token addresses for killed component {}: {}",
component.id,
e
);
}
Ok(token_addrs) => {
for token in token_addrs {
builder.add_balance_change(&BalanceChange {
token,
balance: vec![0],
component_id: component.id.as_bytes().to_vec(),
});
}
}
},

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the substreams::log.

I don’t think setting the TVL to zero is a good way to make this pool untradable in Tycho. If a pool is killed, you can update a mutable entity associated with it and filter it out in tycho-simulation.
You can use the Curve filter as a reference. FYI, static attributes are immutable, so they’re not suitable for this kind of kill case.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, will do.

Any plans in the future to have a PC delete? Seems like the system was designed with CRUD in mind... I thought I saw a DELETE event somewhere although in the previous review I got the impression it wasn't supported. I'll match whatever Curve does.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it was designed around CRUD, and supporting deletion would take quite a bit of work. I wouldn’t expect it anytime soon.

Comment on lines 138 to 166

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Iterating over all ERC20 Transfer events would add a lot of indexing latency. Does the Liquidity Party pool emit any Swap / Mint / Burn events we could use instead to make the filtering and balance detection more efficient?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, all of those. I originally had a full suite of our events and switched it out for Transfers last time... You'll notice that this part of the code was not changed in this update. I'll rewrite this to use our custom events.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I didn’t notice that in my last review. Switching to the full suite of your events would be a big performance improvement.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yah makes total sense. Done.

@timolson

timolson commented May 13, 2026

Copy link
Copy Markdown
Contributor Author
  • Removed all Substreams logging
  • Removed excessive sanity checks in the interest of lower latency
  • Balance tracking updated to use only Liquidity Party events. TVL excludes protocol fees sitting in the pool awaiting collection
  • Killed pools set a dynamic attribute and are filtered out in protocol_stream_processor.rs. The Curve filter doesn't seem to be wired, so I followed the balancer_v2_pool_filter example.
  • Killed pools no longer track balances or send any other Substreams messages. A killed pool's Substreams will report balances at killed time, even if they are subsequently withdrawn by LP's. (Kill still allows LP's to burn() but for Tycho purposes no more Substreams messages will be sent for the pool after the kill.)

I'm going to test the new balance tracking tomorrow. Our test pool already has an "exercise" series of transactions that invokes one of every operation, so I just need to run Substreams on that sequence and verify the final balances.

@timolson

timolson commented May 13, 2026

Copy link
Copy Markdown
Contributor Author

I found a few more nits in our DEX I'd like to clean up as long as we're re-deploying. The current Tycho adapter should be good to review, but I will probably make one more update to the singleton contract addresses before we're really ready to merge. But no changes to API's or anything like that, just updated deployment addresses.

@timolson

Copy link
Copy Markdown
Contributor Author

I updated the contract addresses and start blocks. There was also an ABI touchup, but it doesn't affect anything in Tycho. That's all the updates I wanted to get in.

@timolson

timolson commented May 14, 2026

Copy link
Copy Markdown
Contributor Author

Our auditor found an issue and we're going to need to redeploy again. Minor issues, nothing close to value extraction. I'd understand if you want to pause review until the audit is complete; should be next week. But the ABI's are stable for swaps and there have been no issues found with swap. The adapter code should be stable as-is except for future contract addr changes.

@zach030

zach030 commented May 14, 2026

Copy link
Copy Markdown
Contributor

Our auditor found an issue and we're going to need to redeploy again. Minor issues, nothing close to value extraction. I'd understand if you want to pause review until the audit is complete; should be next week. But the ABI's are stable for swaps and there have been no issues found with swap. The adapter code should be stable as-is except for future contract addr changes.

Thanks for the heads up. I haven’t seen any other major issues so far, and I’ll take another look once the audit is done.

@timolson

Copy link
Copy Markdown
Contributor Author

Turns out we do need to make some pretty significant changes. It's gonna be a few weeks, and I'll probably write a native simulator instead of the EVM simulator. We're moving the bulk of the LMSR solving off-chain and just using an on-chain validation approach instead. Basically we found regimes where our on-chain math wasn't mathing, and the fix is too much gas. So it will be a swap() ABI change to use an offchain solver + on-chain validator model. Don't expect a proper PR for a while.

@zach030

zach030 commented May 20, 2026

Copy link
Copy Markdown
Contributor

Turns out we do need to make some pretty significant changes. It's gonna be a few weeks, and I'll probably write a native simulator instead of the EVM simulator. We're moving the bulk of the LMSR solving off-chain and just using an on-chain validation approach instead. Basically we found regimes where our on-chain math wasn't mathing, and the fix is too much gas. So it will be a swap() ABI change to use an offchain solver + on-chain validator model. Don't expect a proper PR for a while.

Thanks for the heads up! Sounds like you’re planning a native integration?
Before you start integration, please read this integration guide first to make sure Tycho supports it.
Feel free to ping me if you have any questions.

@timolson

timolson commented Jun 1, 2026

Copy link
Copy Markdown
Contributor Author

Our audit will likely wrap up this week, so I should have an updated adapter ready for your review next week.

There will not be any significant changes to the adapter. Should just be contract addresses, start blocks, etc.

@timolson

timolson commented Jun 8, 2026

Copy link
Copy Markdown
Contributor Author

Not going to be this week; we have a little more work to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

2 participants