Encoding

The first step to executing a trade on-chain is encoding.

Our Rust cratearrow-up-right converts your trades into calldata that the Tycho contracts can execute.

See this Quickstart section for an example of how to encode your trade.

Models

These are the models used as input and output of the encoding crate.

The Solution struct defines your order and how it should be filled. This is the input to the encoding module.

Attribute
Type
Description

sender

Bytes

Address of the sender of the token in

receiver

Bytes

Address of the receiver of the token out. If set to the TychoRouter address, these funds will be assigned to the user's Vault.

token_in

Bytes

The token being sold

amount_in

BigUint

Amount of the input token

token_out

Bytes

The token being bought.

min_amount_out

BigUint

Minimum amount the receiver must receive at the end of the transaction

swaps

Vec<Swap>

List of swaps to fulfil the solution.

user_transfer_type

UserTransferType

How user funds are transferred into the router (see below)

Encoder

TychoRouterEncoder prepares calldata for execution via the Tycho Router contract. It supports multi-hop and split swaps.

Builder

Builder options:

  • swap_encoder_registry — Registry of protocol-specific SwapEncoder s used during encoding. Use add_default_encoders for built-in support, or add custom encoders for protocols you've implemented locally.

  • router_address — Router address for execution. Defaults to the deployed address for the given chain ( see Tycho addresses).

Builder Example Usage

Swap Encoders

Each protocol needs its own SwapEncoder to define how the protocol encodes swaps into calldata.

The SwapEncoderRegistry manages these encoders. Call add_default_encoders() to use the built-in implementations. This method accepts an optional executors_addresses JSON string with executor addresses for encoding. Pass None to default to config/executor_addresses.json.

If you need to add custom protocol support, register your own encoder implementation:

Encode

Convert solutions into calldata:

This returns a Vec<EncodedSolution> containing only the encoded swaps. It does **not ** build the full calldata. You must encode the full method call yourself. If you use Permit2, you also need to sign the permit object.

The full method call includes the following parameters, which act as execution guardrails:

  • amountIn and tokenIn — the amount and token to be transferred into the TychoRouter from you.

  • minAmountOut and tokenOut — the minimum amount you want to receive. For maximum security, determine this from a * third-party source*.

  • receiver — who receives the final output. Set this to the TychoRouter address to credit output tokens to the vault.

  • nTokens(split swaps only) the number of distinct tokens in the split routing graph.

  • clientFeeParams — controls fee-taking and client contribution (see Client Fee Signature below). Pass all-zero values if you don't need fees.

The ClientFeeParams struct is defined as:

Field
Description

clientFeeBps

Fee percentage in basis points. 100 = 1%. Set to 0 to disable.

clientFeeReceiver

Address that receives the client's portion of the fee (credited to their vault balance).

maxClientContribution

Maximum amount the client is willing to pay out of pocket if slippage causes the output to fall below minAmountOut. If the shortfall exceeds this value, the transaction reverts. Set to 0 if the client should not subsidize.

deadline

Unix timestamp after which the signature is no longer valid.

clientSignature

EIP-712 signature over all other fields, signed by clientFeeReceiver.

These execution guardrails protect against MEV exploits. Setting them correctly gives you full control over swap security.

Refer to the quickstart for an example of converting an EncodedSolution into full calldata. Tailor the example to your use case. See the TychoRouter contract functions for reference.

Client Fee Signature

If you don't want fees, pass all-zero values: clientFeeBps: 0, clientFeeReceiver: address(0), maxClientContribution: 0, deadline: 0, and an empty clientSignature.

If you do want fees, the clientFeeReceiver must sign the fee parameters using EIP-712. This prevents third parties from spoofing fee configurations. The signature covers the following typed struct:

The EIP-712 domain is:

with name = "TychoRouter", version = "1", and verifyingContract set to the TychoRouter contract address.

chevron-rightSign fee parameters examplehashtag

Example of signing the fee parameters in Rust using alloy:

The returned 65-byte signature is passed as the clientSignature field in ClientFeeParams.

Run as a Binary

Installation

Build and install the binary:

After installation, you can use the tycho-encode command from any directory in your terminal.

Commands

The command lets you choose the encoder:

  • tycho-router: Encodes a transaction using the TychoRouterEncoder.

The commands accept the same options as the builder (more here).

chevron-rightExamplehashtag

Encodes a swap from DAI to WETH using Uniswap V2 on Ethereum:

Last updated

Was this helpful?