update api

[ex-peter-parker]

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

• Yes
• No

Dependencies

none

Description

none

---

Note

Medium Risk
Changes request/response shapes and limit validation for a live swap provider, so mismatches with Exolix API expectations could break quoting or cause incorrect limit errors, especially for EVM/token swaps.

Overview
Updates the Exolix swap integration to use Exolix’s newer network/address-based API parameters: requests now send networkFrom/networkTo (including an evmGeneric path with evmChainId) plus optional token coinAddressFrom/coinAddressTo, and the /rate response now requires a rateId that is passed through to /transactions.

Replaces the previous currency-code transcription path and the hardcoded $70k USD cap with min/max enforcement directly from Exolix (minAmount/maxAmount and withdrawMin/withdrawMax), throwing SwapBelowLimitError/SwapAboveLimitError accordingly.

^{Written by Cursor Bugbot for commit f4ddc64. This will update automatically on new commits. Configure here.}

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1213596310518725

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Zero default for withdrawMax breaks 'to' quotes

Medium Severity

The withdrawMax field defaults to 0 when not provided by the API via asOptional(asNumber, 0). When performing a 'to' quote, the code checks if request.nativeAmount is greater than nativeMax (derived from withdrawMax). If withdrawMax is 0, any positive withdrawal amount will trigger a SwapAboveLimitError with a max of '0', effectively breaking all 'to' quotes for trading pairs where Exolix doesn't return this field.

Additional Locations (1)

• src/swap/central/exolix.ts#L313-L322

 

[samholmes]

Solution for this is to keep withdrawMax optional with no default and case the check under the condition where withdrawMax is present.

[ex-peter-parker]

fixed

[cursor]

Undefined values sent as strings in API request

High Severity

When constructing quoteParams for the GET request to /rate, optional fields like coinAddressFrom, coinAddressTo, networkFromChainId, and networkToChainId can be undefined. When this object is passed to new URLSearchParams(params), JavaScript converts undefined values to the literal string "undefined". This results in the API receiving malformed query parameters like coinAddressFrom=undefined instead of omitting the parameter, which will likely cause API errors or incorrect behavior when swapping native coins (non-token assets) or non-EVM chains.

 

[samholmes]

The concern seems valid here. Perhaps the fix is to use conditional spreads:

const quoteParams: ExolixQuoteParams = {
  ...(coinAddressFrom != null ? { coinAddressFrom } : {}),
  ...(networkFromChainId != null ? { networkFromChainId } : {})

[ex-peter-parker]

fixed

[samholmes]

Issue: The 422 fallback uses asMaybe(asRateResponse), but this cleaner now requires fields like maxAmount and rateId. If Exolix returns a partial 422/minimum payload, parsing fails and this path throws SwapCurrencyError instead of returning a precise limit error.

Recommendation: Use a dedicated looser cleaner for 422 limit payloads, and reserve asRateResponse for successful quote payloads.

[samholmes]

Warning: This change removes the prior local $70k USD guardrail. If that cap was a product/risk requirement, behavior has changed and large swaps now rely solely on partner-provided limits.

Recommendation: Confirm policy intent and keep a local cap if still required.

[ex-peter-parker]

I confirm this — it was necessary for the old functionality; now all limits are calculated automatically.

[samholmes]

Warning: This PR materially changes Exolix quote behavior (new request shape, max/min handling, and 422 parsing) without corresponding automated tests.

Recommendation: Add targeted tests for quoteFor: from/to, missing withdrawMax, and 422 minimum responses to prevent regressions.

[samholmes]

From the API requirements angle, this PR does move the integration in the right direction in a few meaningful ways: it updates the request shape to use chain-aware identifiers (evmGeneric plus chain IDs for EVM assets), includes token contract addresses, and adds explicit destination-side quoting support via quoteFor: 'to'. Those are all improvements toward the chain/token identification and bi-directional quoting requirements.

The highest-priority remaining concern is whether the new destination-side quoting path is fully reliable in practice. Because quoteFor: 'to' is new here and limit handling now depends on withdrawMin / withdrawMax, I would want confidence that Exolix always returns the necessary limit fields or that the plugin tolerates missing fields without manufacturing false over-limit failures.

Beyond that, the other material API-requirements items are provider capabilities that matter to user experience and ops, but are not really proven by this plugin diff: an unauthenticated status page, a transaction-status API by orderId, and reporting data that can be matched back to Edge orders. I would not block this PR on every last detail of error-shape perfection or extra hardening if the Exolix team has already confirmed those behaviors, but before treating the integration as compliant with the API requirements, I would want those core capabilities explicitly confirmed somewhere in the PR or supporting notes.