feat: add metric rfq integration by zach030 · Pull Request #1000 · propeller-heads/tycho

zach030 · 2026-05-08T05:53:34Z

No description provided.

claude

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.

_{Tip: disable this comment in your organization's Code Review settings.}

zizou0x · 2026-05-12T14:36:37Z

+            tokens: HashSet::new(),
+            tvl: 0.0,
+            quote_tokens: None,
+            base_url: "http://54.199.103.16:8080".to_string(),


What is this URL?

This is metric API endpoint

Can we make this configurable somehow? If they change this URL - which is not unlikely, we'd need to release another version and users won't be able to fix until we act

This is configurable now: users can override it with .base_url(...) function, and I also added env config for the default URL.

zizou0x · 2026-05-12T15:11:04Z

+        let (amount_out_human, max_output) = match direction {
+            MetricDirection::ZeroForOne => {
+                let price = self.bid_ask.bid_price()?;
+                (amount_in_human * price, self.bid_ask.total_token1_available()?)


There is no price impact depending on the amount_in?

I went back to the docs and realized I had missed the depth field from the /bid_ask endpoint.

Metric exposes orderbook-like depth bins on both the bid and ask sides. The volume is cumulative across bins, and within each bin the price follows a linear segment instead of staying flat.

I updated the implementation to handle those bins properly, and added comments with the formulas used for calculations.

You can also refer to the Metric docs for the depth description [here].(https://oracle-based-omm.gitbook.io/metric/RSm94m71kqtGICv4iKRj/developers/api#depth)

tvinagre · 2026-05-14T15:26:31Z

+        let zero_for_one = zero_for_one(swap)?;
+        let price_limit_x64 =
+            if zero_for_one { Bytes::zero(32) } else { u256_bytes(&BigUint::from(u128::MAX)) };
+        let oracle_update = if self.request_oracle_update {


Does this mean that, on Mainnet, the user will always pay for its transaction + the Oracle Update TX? If that's the case, can't we make this configurable?

Or, it would be nice to try to swap without the oracle update and, if the TX reverts because the oracle didn't update, send the oracle update. Not sure how much that would add in gas or if that's feasible

tvinagre · 2026-05-14T15:43:10Z

+                .unwrap_or_default()
+                .into(),
+        );
+


let entries: [(&str, Vec<u8>); 9] = [ ("bid_adj", bid_ask.bid_adj.as_bytes().to_vec()), ("ask_adj", bid_ask.ask_adj.as_bytes().to_vec()), ("total_token0_available", bid_ask.total_token0_available.as_bytes().to_vec()), ("total_token1_available", bid_ask.total_token1_available.as_bytes().to_vec()), ("latest_block", bid_ask.latest_block.to_string().into_bytes()), ("block_ts", bid_ask.block_ts.to_string().into_bytes()), ("server_ts", bid_ask.server_ts.to_string().into_bytes()), ("quote_expiration", bid_ask.quote_expiration.to_string().into_bytes()), ("depth", serde_json::to_vec(&bid_ask.depth).unwrap_or_default()), ]; for (key, bytes) in entries { attributes.insert(key.to_string(), bytes.into()); }

is easier to read IMO - what do u think?

tvinagre · 2026-05-14T15:44:55Z

+    async fn fetch_bid_ask(&self, pool: &Bytes) -> Result<MetricBidAskResponse, RFQError> {
+        let endpoint =
+            format!("{}/{}/bid_ask", self.chain_endpoint, bytes_to_address_string(pool)?);
+        let http_client = Client::new();


By recreating the client here every time, you need to always redo TLS handshake and that adds latency. If you create the client once and reuse it you will get a performance increase on the requests

fixed, now the client is cached with OnceLock, so we create it once and reuse it across requests.

tvinagre · 2026-05-14T15:47:17Z

+
+#[async_trait]
+impl RFQClient for MetricClient {
+    fn stream(


Shouldn't this be async fn?

stream returns a BoxStream directly and does the async work inside the stream

tvinagre · 2026-05-14T15:48:48Z

+    Ok(biguint_to_u256(&value))
+}
+
+fn stable_decimals(address: &Bytes) -> Option<u8> {


Not a big fan of this - if the RFQ adds a new stable we'd need to release a new Tycho-Simulation version?
Can we use Tycho data here?

yes, agreed. I changed this so we can pass token metadata in from tycho data via .token_metadata(...).

tvinagre · 2026-05-14T15:50:44Z

+            tokens: HashSet::new(),
+            tvl: 0.0,
+            quote_tokens: None,
+            base_url: "http://54.199.103.16:8080".to_string(),


Can we make this configurable somehow? If they change this URL - which is not unlikely, we'd need to release another version and users won't be able to fix until we act

tvinagre · 2026-05-14T15:58:33Z

+        let res = GetAmountOutResult {
+            amount: capped_amount.clone(),
+            gas: BigUint::from(170_000u64),
+            new_state: self.clone_box(),


Shouldn't we calculate the depth impact of this swap and update the new_state with it?

Hum, I’m not sure how a Metric swap should update the state, and the other RFQ sims also leave new_state unchanged.

tvinagre · 2026-05-19T17:16:00Z

+    fn encoder(oracle_address: &Bytes) -> MetricSwapEncoder {
+        MetricSwapEncoder::new(
+            Bytes::zero(20),
+            Chain::Ethereum,


Should chain be hardcoded here?

this is hardcoded for testing, and the test tokens are also on mainnet, so I think it should be fine.

tvinagre · 2026-05-19T17:18:20Z

+        };
+        let candidate = if &pool.token0 == token && quote_tokens.contains(&pool.token1) {
+            let Some(quote_token) = token_metadata.get(&pool.token1) else {
+                continue;


Aren't these else cases an error? Shouldn't we log something here?

fixed, I added some logs when there's no candidate.

zizou0x · 2026-06-03T12:11:33Z

+    #[serde(skip_serializing, default)]
+    secret_key: Option<String>,
+    #[serde(skip, default = "OnceLock::new")]
+    http_client: OnceLock<Client>,


Why is it a OnceLock?

just to reuse the same Client across requests, address this comment

Couldn't we reuse it if it was just http_client: Client?

github-project-automation Bot added this to Tycho May 8, 2026

github-project-automation Bot moved this to Todo in Tycho May 8, 2026

claude Bot reviewed May 8, 2026

View reviewed changes

zizou0x reviewed May 12, 2026

View reviewed changes

tvinagre reviewed May 14, 2026

View reviewed changes

tvinagre reviewed May 19, 2026

View reviewed changes

zach030 added the protocol integration label May 21, 2026

zach030 force-pushed the feat/metric-rfq branch from 5e034a2 to 0ebca5f Compare May 25, 2026 03:50

zach030 added 14 commits June 2, 2026 08:31

feat: add metric rfq integration

bbae35f

refactor: clean up metric rfq

3ab9731

test: add live metric api coverage

b938968

feat: add metric rfq oracle update encoding

8ce1d70

feat: add metric executor

354ba45

feat: add metric executor contract

2406cf3

fix: silence metric slither warning

416845c

fix: update metric executor slot

883a932

feat: support Metric depth quotes

750de77

feat: normalize Metric TVL with token metadata

944ac80

fix(metric): harden oracle update target

35a257e

chore: log missing Metric one-hop TVL prices

042ac33

refactor(metric): simplify component state and swap calldata

06a570f

feat: add PAMM RFQ protocol mode

f4f2758

zach030 force-pushed the feat/metric-rfq branch from 0ebca5f to f4f2758 Compare June 2, 2026 03:06

fix: add Base protocol config entry

282f2eb

zizou0x reviewed Jun 3, 2026

View reviewed changes

zach030 added 3 commits June 3, 2026 21:31

fix: enable PAMM RFQ protocols by default

1736528

feat: encode Metric oracle updates as args

2fd087f

Merge branch 'main' into feat/metric-rfq

9e992d5

Conversation

zach030 commented May 8, 2026

Uh oh!

claude Bot left a comment

Choose a reason for hiding this comment

Claude Code Review

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants