Tristero's March 2026 MWEB announcement was more specific than a general claim that private swaps were available everywhere. The project described buying LTC with other assets and sending the output to an . That direction matters when deciding what the integration can actually do.
This is an updated account of the announcement and the documentation available on 25 October 2026. We have not executed a swap or tested an MWEB deposit or withdrawal through the live service.
What the March announcement actually promised
In its 17 March 2026 LitecoinTalk announcement, the Tristero account said users could buy LTC with BTC, ETH, SOL or XMR and receive LTC at their Litecoin address. It explicitly included sending to MWEB addresses. The same post described a fuller end-to-end MWEB implementation as a possible expansion if demand existed.
That is evidence of an announced MWEB output route. It does not establish that an MWEB input was accepted, that every listed pair had , or that all routes still operate unchanged. The earlier Foundation X link could not be read during this review; the operator's dated forum post now provides the directly inspected announcement.
| Claim | Evidence checked | What remains to verify |
|---|---|---|
| LTC output to an MWEB address was announced. | The March project post says so explicitly. | Whether the live route accepts your exact destination today. |
| Native LTC is documented as a supported asset. | The current Feather asset list includes LTC on Litecoin. | The selected pair, direction, amount, capacity and final quote. |
| MWEB can be used on the input side. | The output announcement and a generic LTC listing do not establish this. | Explicit current input instructions for that route. |
| Every swap uses the same execution architecture. | The documentation distinguishes smart-contract routes from Feather. | Which route the actual order uses and what happens after deposit. |
Read the documentation for the route you are using
The Tristero introduction covers several products. Its EVM trading material discusses signed orders and smart-contract execution. Its cross-VM section describes Feather, which supports native assets including LTC. Applying the smart-contract description to every native-LTC swap would miss an important operational distinction.
According to the Feather overview, the service observes a deposit on the input chain and sends the output from its reserves. Its documented model does not use a or cross-chain message for that . No connection is needed for this deposit flow, but the customer still depends on the service recognizing the deposit and delivering the output.
The project uses terms such as and trustless. Those labels are not a replacement for following the actual asset flow. This review has not independently established reserve sufficiency, route availability, a legal custody classification or a security guarantee.
The quickstart also says automatic chaining from Tristero's smart-contract routes to Feather is not currently supported. Two separately executed trades should be evaluated as two trades, with separate costs, deadlines and failure handling.
Keep the source payment, order and LTC receipt separate
There are three records worth preserving. The source-chain transaction shows what you sent. The service order identifies the promised exchange. The destination wallet or service shows what arrived. A reassuring state in one record does not fill a gap in the others.
| Record | Save before funding | Check afterwards |
|---|---|---|
| Source-chain payment | Input asset and network, exact service deposit address and intended amount. | Its transaction identifier and actual output to that deposit address. |
| Service order | Trade ID, quoted limits and output, expiry, return address and price-degradation setting. | The order state and the service's account of any return or output transaction. |
| Litecoin receipt | The full intended destination, its supported format and the receiver's policy. | The amount received by that destination and, where applicable, account credit. |
The create-trade reference documents distinct OutputAddress and ReturnAddress fields. The return address belongs on the input chain. It is not automatically the address where you want to receive LTC.
One counterintuitive detail deserves attention: that reference describes MaxSlippage as a fraction and says its default value of zero means no limit. Do not read a zero as zero tolerated price degradation without checking the exact interface and implementation. We checked the documented semantics, not their live enforcement.
What happens outside the quoted conditions?
The liquidity and returns page says an over-limit deposit is returned when a return address was supplied. It warns that without one, an excess deposit can cause loss. For insufficient output liquidity, it describes either a return or waiting, depending on whether a return address exists.
That makes the return route part of the transaction plan, rather than an administrative detail to add after a problem. Establish its supported network and format before funding. A return address supplied incorrectly does not become usable because the form accepted it.
The state-machine documentation describes expiry after two hours without a deposit and mentions a grace period for late deposits without giving its duration on that page. Its delivery assurances are the project's statements, not a guarantee supplied by this article. Do not rely on an unspecified grace period or treat an expired service order as cancellation of an payment.
The status endpoint reports the service's trade state. A timeout in your browser or script does not show that the original transfer failed. Preserve the trade ID and investigate the source payment and destination receipt before creating a replacement order.
Compare delivered LTC rather than the headline quote
A route can look cheaper before output charges, source-chain fees and execution changes are included. The quote reference documents price and capacity fields; it does not establish that every displayed number is the amount a particular receiver will obtain.
Here is a fictional comparison, not a Tristero quote. Route A displays 1.000 LTC but deducts a 0.006 LTC output charge, leaving 0.994 LTC. Route B delivers 0.995 LTC after its listed charges. B delivers 0.001 LTC more despite the smaller initial display. Source-asset costs still need to be compared separately on the same basis.
Save the conditions used for a comparison: pair, direction, amount, observation time and whether charges are included or additional. A quote for one small order is not evidence of capacity or execution cost for a much larger one.
An MWEB address is not a promise of exchange credit
MWEB's optional extension- design is described in LIP-0003; LIP-0004 adds the one-sided transaction design. These are protocol design documents. They do not define an exchange's deposit policy, a swap provider's input formats or the records a service retains.
A current counterexample is Kraken's deposit-processing policy, updated 22 October 2026: it says Litecoin deposits through MWEB, including peg-outs, are not credited and may be lost. A valid transparent output from a peg-out therefore does not, by itself, establish that a particular service accepts its route.
Use the receiving service's current, account-specific instructions and resolve any policy uncertainty before sending. This article does not propose a route around a restriction. The older Binance notice linked in the previous version was not available as a usable direct page during this review and is not being used as evidence of today's policy.
Privacy support does not close the security question
The developer postmortem records 2026 validation and service-availability incidents. The current stable Core release checked on 25 October was 0.21.5.8. Neither an MWEB logo nor that release's existence identifies the software operated by a particular service.
MWEB confidentiality also does not erase the quote, deposit address, order reference or other information given to a swap provider. Ask what the specific route reveals and retains. Do not infer a privacy policy, an independent audit, universal anonymity or a measurable adoption increase from an integration announcement.
Frequently asked questions
Did Tristero announce sending LTC to MWEB addresses?
Yes. Its March project post explicitly described that output capability. This review did not test whether a particular live route delivers it today.
Does that prove MWEB input deposits are accepted?
No. An output capability, an input capability and a generic native-LTC listing are different claims. Check the current instructions for the exact direction.
Does a swap status marked complete prove an exchange credited me?
No. Check the destination evidence and receiving-service account. A service's status is one record, not a substitute for every stage of the payment.
Review scope
Sources were checked on 25 October 2026. This is a review of the dated announcement, current documentation, release records and one current receiving-service policy. No wallet was connected, no quote or trade was created, no deposit was sent and no refund path was tested. The original publication date and URL remain unchanged.
