On a direct route, Instaswap delegates execution to an integrated liquidity protocol. A combined route needs more than one swap leg, potentially joining a cross-chain conversion to a DEX swap on the destination network. The routing engine presents those legs as one quote, while escrow constrains the funds passing between them.

The intermediate asset is an output of one leg and an input to the next. Completion of that first conversion does not establish delivery of the asset the order requests.

According to the whitepaper, a factory deploys a small escrow contract for each order on the relevant chain. The rules restrict its swap funds to the next leg of that order or the committed refund destination, subject to the documented fee deductions. The refund address is fixed before the deposit address is shown; an operator cannot select a different recipient later.

Open full-size image

Onward fund movements require signatures from three of four independent approvers. Each signer rechecks the order against the protocol’s records before signing. Under this design, the backend cannot advance those funds by itself. Meeting the signature threshold permits an allowed movement; it does not establish that the full swap has settled.

A signed maximum caps the fee deducted on each leg. Any fee excess above that maximum is returned to the user’s refund destination in the same transaction. Fee collection is itself subject to approval.

Once the applicable refund timeout has elapsed, the whitepaper says anyone can trigger a refund to the committed destination. Opening the trigger to other callers does not let them redirect the payout. The document gives no single duration for every order’s timeout.

Open full-size image

Factory governance uses an owner key held on a hardware wallet. Changes that loosen security, such as replacing approver signers or changing the treasury, have a 48-hour public delay. Tightening actions can take effect immediately, including removing a signer, raising the approval threshold, and rotating or pausing the operator. That 48-hour delay applies to governance changes; it is not a swap completion or refund deadline.

Open full-size image

The October 2026 whitepaper reports a Hashlock audit of the escrow generation and says the report will be published on completion of the review of the live generation. It also describes verified contract sources and a public bug bounty covering live escrow contracts, approvers, and parts of the API and backend that can affect funds. These statements do not establish which contract generation an older order used.

• Distinguish a direct route from a multi-leg route before applying the escrow rules.
• For a multi-leg order, identify the final asset and receiving address before interpreting an intermediate conversion as completion.
• Confirm the committed refund destination before funding, and separate the applicable refund timeout from the 48-hour governance delay.
• Match approval, fee-cap, and audit claims to the contract generation used by the order.