@anywalletkit/protocol-swap2-lifi 0.4.0 → 0.6.0

package/README.md

@@ -24,9 +24,14 @@ do the same: a same-chain swap (GenericSwapFacet / V3) pays the reviewed recipie
 reviewed minimum, spending the input token and delivering the requested one; a bridge call must be
 one of LI.FI's listed `startBridgeTokensVia*` / `swapAndStartBridgeTokensVia*` entry points (packed
 calls are refused) and its `BridgeData` must name the reviewed recipient and chain and bridge the
-input token (or what its source swaps make of it). Refused, because the recipient cannot be read
-from the calldata: routes with a destination call, and EVM-source routes to a non-EVM chain.
-Unknown calldata is refused.
+input token (or what its source swaps make of it). Every refund, depositor or fallback address a
+bridge carries in its own data (Stargate's LayerZero fee refund, an expired Across deposit or LI.FI
+intent, a Mayan Swift order's trader, Chainflip's refund address, …) must be the sender or the
+recipient. Refused, because the recipient cannot be read from the calldata: routes with a destination call, EVM-source routes to a non-EVM chain, and the
+bridges whose facet does not bind the delivery to `BridgeData` (Relay, Garden, deBridge DLN,
+ThorSwap, Squid, Symbiosis) — cross-chain requests ask LI.FI to route around Relay, Garden, Squid
+and Symbiosis, and not to offer destination calls (`allowDestinationCall=false`), so their pairs get
+another bridge. Unknown calldata is refused.
 
 Every swap step is read, not only the ends: each must spend what the step before delivered, only
 steps that spend the input token may pull from the wallet (`requiresDeposit`), and together at most
@@ -36,9 +41,23 @@ bound to the asset kinds they move (`*ToNative` only for a native output, `*ToER
 bridge without source swaps must bridge the input, less at most a 1 % bridge fee. `apiUrl` must be
 `https:` (`allowInsecureApiUrl` for local development).
 
-Not checked: a bridge's output. The destination minimum — and for some bridges (Relay, Across)
-what finally reaches the recipient — sits in bridge-specific data, so on cross-chain routes the
-reviewed minimum relies on LI.FI's API (or your `apiUrl` proxy) answering honestly.
+Mostly not checked: a bridge's output. The destination minimum — and for some bridges (Relay, Across)
+what finally reaches the recipient — sits in bridge-specific data, so on most cross-chain routes the
+reviewed minimum relies on LI.FI's API (or your `apiUrl` proxy) answering honestly. Two bridges name
+it outright and are held to the quote: an Eco intent must run on the destination chain and its route
+must end in the destination token's `transfer` of at least the reviewed minimum to the recipient
+(a route of more than 16 calls is refused); an M0 order must ask for the destination token at a
+rate of at least the reviewed minimum. An M0 order can be filled in part: the recipient then gets
+that share at the order's rate and the rest of the input returns to the sender after the order's
+fill deadline. Neither can deliver the native token through this module: an Eco or M0 route whose
+destination token is native (ETH, POL, …) is always refused. The module does not ask LI.FI again
+without that bridge, so when LI.FI picks one of them for such a pair, the pair shows no LI.FI route.
+
+`routeWideSlippage: true` (default off) asks LI.FI for one slippage budget for the whole route
+(`slippageScope=route`) on EVM → EVM requests instead of one per step; when LI.FI can protect no
+route for a request (`ROUTE_SLIPPAGE_UNSUPPORTED`) or has route-wide slippage switched off
+(`ROUTE_SLIPPAGE_UNAVAILABLE`), it is asked again in its default scope, held to the same floor. That
+happens while quoting, so the quote the user reviews is the per-step one, with its own minimum.
 
 ## Behind `remoteProvider`
 
@@ -46,7 +65,7 @@ When the provider runs on your server, spread its pins into the app's stub:
 `remoteProvider({name: "lifi", baseUrl, ...lifiPins})`. The engine then lets the EVM route call and
 approve only the LI.FI Diamond of that chain, never an address the backend names, and `lifiVerifyQuote` decodes the
 server's Diamond call on the device with the same check the provider runs on LI.FI's answer (receiver, minimum, input
-token and amount, output token, destination chain; value and approval for the input kind). Without the pins the stub
+token and amount, output token, destination chain, refund addresses; value and approval for the input kind). Without the pins the stub
 gets no EVM calldata route (fail closed).
 
 ## Activity