DEV Community: Typelex

Address-Specific OTC Orders: A Simpler Way to Settle Private On-Chain Deals

Typelex — Wed, 29 Jul 2026 13:51:44 +0000

Public DEXs are designed for open trading.

A user selects two assets, accesses shared liquidity, and receives a price calculated during execution.

But some transactions are not meant for the open market.

A project may sell tokens to a specific investor. A DAO may exchange treasury assets with an approved partner. Two funds may agree on a private stablecoin swap.

In these cases, the participants already know the counterparty, assets, amounts, and exchange rate.

Typelex converts those negotiated terms into an address-specific on-chain OTC order.

The Problem With Open Orders

Not every offer should be available to every wallet.

Consider a private token allocation:

the project has selected an investor;
both sides have agreed on the price;
the receiving wallet is already known;
the allocation is not intended for the public market.

Publishing this transaction as an unrestricted order creates unnecessary risk.

Another wallet could attempt to execute it, even though the agreement was made with a specific participant.

Typelex solves this by connecting the order to an authorized wallet address.

What the Order Defines

A Typelex OTC order can include:

the token offered by the maker;
the token expected in return;
the amount of each asset;
the fixed exchange rate;
the authorized counterparty;
the expiration time.

The smart contract does not negotiate or recalculate these conditions.

Its role is much simpler:

Verify the order and execute it exactly as agreed.

Wallet-Level Access Control

When a user attempts to fill the order, the contract checks the sender’s wallet.

Conceptually, the validation may look like this:

require(
msg.sender == authorizedCounterparty,
"Unauthorized wallet"
);

The actual implementation may differ, but the principle remains the same:

An on-chain order can be publicly visible without being publicly executable.

A wallet that is not included in the order cannot complete the transaction.

Fixed Terms, Not Dynamic Quotes

An AMM calculates the exchange result from current liquidity.

A Typelex OTC order starts with a result that has already been agreed.

For example:

Maker provides: Token A
Counterparty provides: Token B
Rate: Fixed before execution
Authorized wallet: Defined in the order
Expiration: Defined in the order

The amounts do not automatically change because:

another transaction was processed first;
liquidity moved in an external pool;
an aggregator selected a new route;
the market price changed before confirmation.

When the original terms can no longer be completed, the transaction is rejected or the order expires.

The contract does not replace the agreement with a different quote.

Both Transfers Happen Together

Access control alone is not enough.

The settlement must also ensure that one participant cannot receive assets while the other side gets nothing.

Typelex uses atomic execution.

There are only two possible results:

Both transfers are completed.
The entire transaction is reverted.

Before execution, the contract can verify:

wallet authorization;
token balances;
transfer approvals;
order status;
expiration time;
exact token amounts.

There is no partial settlement and no need to decide which participant should transfer first.

Negotiation Happens Off-Chain, Settlement Happens On-Chain

Typelex separates the deal into two stages.

Negotiation

The participants agree on:

assets;
volume;
rate;
wallet addresses;
execution period.

This can happen through an RFQ workflow, private communication channel, DAO decision, or existing business relationship.

Settlement

The agreed parameters are added to the on-chain order.

The smart contract then verifies the conditions and coordinates both transfers.

Participants define the deal. Typelex enforces the settlement logic.

Why Public Liquidity Is Not Required

The price has already been agreed, so the transaction does not need to search for liquidity inside an AMM.

The assets come directly from the participating wallets.

This avoids dependence on:

public pool depth;
intermediary tokens;
multi-hop routing;
dynamic AMM pricing;
several external liquidity venues.

The settlement remains recorded on-chain, but the exchange does not need to be executed as a public-market swap.

Where Address-Specific Orders Can Be Used
Strategic token allocations

Projects can create orders for selected investors or partners.

DAO treasury operations

A DAO can exchange assets with an approved counterparty under predefined terms.

Stablecoin rebalancing

Two participants can settle a direct stablecoin exchange without routing the transaction through public pools.

Fund and market maker settlement

Previously negotiated transactions can be completed between approved wallets.

Private token sales

A large holder can transfer an allocation directly to a specific buyer.

Non-Custodial Execution

Typelex does not require users to keep assets on a shared platform balance.

Participants connect their own wallets and approve the necessary transfers themselves.

The protocol does not need to:

hold private keys;
approve withdrawals manually;
maintain internal user balances;
decide which participant should send first;
release funds through a human operator.

The transaction result is determined by the order parameters and smart contract logic.

Final Takeaway

Not every on-chain deal should be open to the entire market.

Some transactions are created for specific participants under previously agreed conditions.

Typelex turns those agreements into fixed-rate, address-specific OTC orders.

The contract verifies the authorized wallet, checks the transaction parameters, and executes both transfers atomically.

Private negotiation. Defined counterparty. Transparent on-chain settlement.

Building Gas-Efficient OTC Orders With EIP-712: A Typelex Case Study

Typelex — Mon, 20 Jul 2026 14:45:16 +0000

Building Gas-Efficient OTC Orders With EIP-712: A Typelex Case Study

Creating every OTC order directly onchain is easy to understand.

The maker submits a transaction, the contract stores the order, and another participant fills it later.

But this model has an obvious weakness:

Every quote costs gas, even if nobody accepts it.

For an OTC or RFQ protocol, this can become inefficient very quickly.

A market maker may prepare dozens of short-lived quotes. A DAO may request offers from several counterparties before choosing one. A fund may receive a price that remains valid for only a few minutes.

Writing every quote into blockchain storage is often unnecessary.

A more efficient approach is to:

Create the order offchain.
Sign its structured data.
Send the signed order to the intended counterparty.
Submit it onchain only when the trade is ready to settle.

This article explores that architecture using Typelex as a practical case study.

We will build a simplified fixed-price OTC settlement system using:

EIP-712 typed data
Offchain maker signatures
Onchain signature verification
Nonce-based replay protection
Restricted taker wallets
Atomic ERC-20 settlement
Support for EOAs and smart-contract wallets

Important: The code below is educational. It is not production-ready and should not be deployed without extensive testing, independent review, and a professional security audit.

Why storing every quote onchain is inefficient

Consider a traditional order workflow.

The maker calls a function such as:

createOrder(
    sellToken,
    buyToken,
    sellAmount,
    buyAmount,
    taker,
    deadline
);

The contract records the order in storage.

This requires an onchain transaction before anyone can accept the quote.

That may be reasonable for long-lived public orders. It is less efficient for short-lived OTC quotes.

Imagine the following situation:

A treasury requests quotes from five market makers.
Each market maker prepares a different offer.
The treasury accepts only one.
The other four quotes expire.

With a fully onchain system, all five quotes may consume gas even though only one becomes a real transaction.

The blockchain does not need to store every unsuccessful negotiation.

It only needs enough information to verify the order that is eventually executed.

Moving order creation offchain

Instead of publishing the order through a transaction, the maker signs a structured message.

A simplified order may look like this:

struct Order {
    address maker;
    address taker;
    address sellToken;
    address buyToken;
    uint256 sellAmount;
    uint256 buyAmount;
    uint256 nonce;
    uint256 deadline;
}

The signature represents the maker’s authorization:

I agree to sell this exact amount of one token in exchange for this exact amount of another token under these conditions.

The signed order may be delivered through:

an RFQ interface;
a private API;
direct communication;
an encrypted message;
a backend quotation service.

The order reaches the blockchain only when the taker is ready to settle.

The workflow becomes:

Maker creates a quote offchain
              ↓
Maker signs the structured order
              ↓
Taker receives the order and signature
              ↓
Taker submits them to the contract
              ↓
The contract verifies and settles the trade

Unused quotes never create blockchain storage.

Why EIP-712 is useful

A wallet can sign an arbitrary hash, but raw hexadecimal messages are difficult for users to understand.

EIP-712 provides a standard for signing typed structured data.

Instead of showing an unreadable string, the wallet can display meaningful fields such as:

sellToken
buyToken
sellAmount
buyAmount
taker
deadline

The signature domain can also include:

the protocol name;
the protocol version;
the chain ID;
the verifying contract.

For Typelex, the frontend domain may look like this:

const domain = {
  name: "Typelex",
  version: "1",
  chainId: 42161,
  verifyingContract: "0xSettlementContract"
};

Each field serves a purpose.

name identifies the signing application.

version separates different versions of the protocol.

chainId helps prevent a signature created on one network from being reused on another.

verifyingContract binds the signature to one specific settlement contract.

However, EIP-712 does not automatically make an order single-use.

For that, the protocol still needs nonces or another replay-protection mechanism.

Defining the Typelex order

We start with the Solidity structure:

struct Order {
    address maker;
    address taker;
    address sellToken;
    address buyToken;
    uint256 sellAmount;
    uint256 buyAmount;
    uint256 nonce;
    uint256 deadline;
}

The corresponding EIP-712 type hash must contain exactly the same fields in exactly the same order:

bytes32 private constant ORDER_TYPEHASH =
    keccak256(
        "Order("
        "address maker,"
        "address taker,"
        "address sellToken,"
        "address buyToken,"
        "uint256 sellAmount,"
        "uint256 buyAmount,"
        "uint256 nonce,"
        "uint256 deadline"
        ")"
    );

This part is easy to underestimate.

A small mismatch between the frontend and Solidity definitions will produce a different digest.

For example, the signature will fail if:

the field order is different;
one field uses another type;
capitalization does not match;
the frontend omits a field;
the Solidity contract adds a field that the frontend does not sign.

The signature may still be cryptographically valid, but it will not be valid for the message the contract reconstructs.

A simplified Typelex settlement contract

Below is a complete educational example.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {
    EIP712
} from "@openzeppelin/contracts/utils/cryptography/EIP712.sol";

import {
    SignatureChecker
} from "@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol";

import {
    IERC20
} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";

import {
    SafeERC20
} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

import {
    ReentrancyGuard
} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

contract TypelexSignedOrders is EIP712, ReentrancyGuard {
    using SafeERC20 for IERC20;

    struct Order {
        address maker;
        address taker;
        address sellToken;
        address buyToken;
        uint256 sellAmount;
        uint256 buyAmount;
        uint256 nonce;
        uint256 deadline;
    }

    bytes32 private constant ORDER_TYPEHASH =
        keccak256(
            "Order("
            "address maker,"
            "address taker,"
            "address sellToken,"
            "address buyToken,"
            "uint256 sellAmount,"
            "uint256 buyAmount,"
            "uint256 nonce,"
            "uint256 deadline"
            ")"
        );

    mapping(address maker => mapping(uint256 nonce => bool used))
        public nonceUsed;

    event OrderFilled(
        bytes32 indexed orderHash,
        address indexed maker,
        address indexed taker,
        address sellToken,
        address buyToken,
        uint256 sellAmount,
        uint256 buyAmount,
        uint256 nonce
    );

    event NonceCancelled(
        address indexed maker,
        uint256 indexed nonce
    );

    error InvalidAddress();
    error InvalidTokenPair();
    error InvalidAmount();
    error OrderExpired();
    error NonceAlreadyUsed();
    error UnauthorizedTaker();
    error InvalidSignature();

    constructor() EIP712("Typelex", "1") {}

    function hashOrder(
        Order calldata order
    ) public view returns (bytes32) {
        bytes32 structHash = keccak256(
            abi.encode(
                ORDER_TYPEHASH,
                order.maker,
                order.taker,
                order.sellToken,
                order.buyToken,
                order.sellAmount,
                order.buyAmount,
                order.nonce,
                order.deadline
            )
        );

        return _hashTypedDataV4(structHash);
    }

    function fillOrder(
        Order calldata order,
        bytes calldata signature
    ) external nonReentrant {
        _validateOrder(order);

        if (nonceUsed[order.maker][order.nonce]) {
            revert NonceAlreadyUsed();
        }

        if (
            order.taker != address(0) &&
            order.taker != msg.sender
        ) {
            revert UnauthorizedTaker();
        }

        bytes32 orderHash = hashOrder(order);

        bool validSignature =
            SignatureChecker.isValidSignatureNow(
                order.maker,
                orderHash,
                signature
            );

        if (!validSignature) {
            revert InvalidSignature();
        }

        nonceUsed[order.maker][order.nonce] = true;

        IERC20(order.buyToken).safeTransferFrom(
            msg.sender,
            order.maker,
            order.buyAmount
        );

        IERC20(order.sellToken).safeTransferFrom(
            order.maker,
            msg.sender,
            order.sellAmount
        );

        emit OrderFilled(
            orderHash,
            order.maker,
            msg.sender,
            order.sellToken,
            order.buyToken,
            order.sellAmount,
            order.buyAmount,
            order.nonce
        );
    }

    function cancelNonce(
        uint256 nonce
    ) external {
        if (nonceUsed[msg.sender][nonce]) {
            revert NonceAlreadyUsed();
        }

        nonceUsed[msg.sender][nonce] = true;

        emit NonceCancelled(msg.sender, nonce);
    }

    function _validateOrder(
        Order calldata order
    ) internal view {
        if (
            order.maker == address(0) ||
            order.sellToken == address(0) ||
            order.buyToken == address(0)
        ) {
            revert InvalidAddress();
        }

        if (order.sellToken == order.buyToken) {
            revert InvalidTokenPair();
        }

        if (
            order.sellAmount == 0 ||
            order.buyAmount == 0
        ) {
            revert InvalidAmount();
        }

        if (block.timestamp > order.deadline) {
            revert OrderExpired();
        }
    }
}

The contract uses several OpenZeppelin components:

EIP712 for typed-data hashing;
SignatureChecker for EOA and smart-wallet signature validation;
SafeERC20 for safer token transfers;
ReentrancyGuard for protection against nested settlement calls.

Now let us break down the execution flow.

Step 1: Validate the order

The contract first rejects obviously invalid parameters.

_validateOrder(order);

The validation checks for:

zero maker address;
zero token address;
identical sell and buy tokens;
zero token amounts;
expired deadlines.

These checks belong inside the smart contract.

A frontend can perform the same validation to improve user experience, but frontend checks are not security controls.

Anyone can bypass the interface and call the contract directly.

Step 2: Check whether the nonce was used

if (nonceUsed[order.maker][order.nonce]) {
    revert NonceAlreadyUsed();
}

The nonce makes the order single-use.

Each maker has an independent nonce space.

That means:

Maker A, nonce 10

and:

Maker B, nonce 10

are two separate orders.

But Maker A cannot successfully settle nonce 10 twice.

Without this check, the same signed order could potentially be replayed until the maker’s allowance or balance was exhausted.

Step 3: Verify the taker

Some OTC orders may be public.

Others may be intended for one specific wallet.

The contract supports both:

if (
    order.taker != address(0) &&
    order.taker != msg.sender
) {
    revert UnauthorizedTaker();
}

When:

taker = address(0);

any wallet may fill the order.

When taker contains a specific address, only that wallet can execute it.

This is especially important for privately negotiated RFQ quotes.

A maker may offer a special rate to one approved counterparty. Without a taker restriction, anyone who receives the signed order could attempt to execute it.

A restricted taker does not make the order private. It only controls who can fill it.

Blockchain observers may still see the final settlement transaction.

Step 4: Reconstruct the signed digest

The contract hashes the complete order:

bytes32 orderHash = hashOrder(order);

The digest includes:

all order fields;
the Typelex domain name;
the protocol version;
the current chain ID;
the verifying contract.

This means a taker cannot modify one field and reuse the same signature.

Changing:

buyAmount: 500,000 USDC

to:

buyAmount: 490,000 USDC

produces a different digest.

The maker’s original signature will no longer be valid.

Step 5: Verify the maker’s signature

bool validSignature =
    SignatureChecker.isValidSignatureNow(
        order.maker,
        orderHash,
        signature
    );

The contract asks one question:

Did the maker authorize this exact order?

Using SignatureChecker provides support for two wallet types.

Externally owned accounts

Traditional wallets sign with an ECDSA private key.

Smart-contract wallets

Multisigs and smart accounts may validate signatures through ERC-1271.

This distinction matters because a contract wallet does not necessarily have one private key corresponding directly to its address.

Its authorization may depend on:

several owners;
a signing threshold;
installed modules;
custom validation logic.

The signature should therefore be validated during execution, not just once when the order is received by the frontend.

Step 6: Mark the nonce as used

nonceUsed[order.maker][order.nonce] = true;

The contract updates its internal state before calling external token contracts.

This follows the checks-effects-interactions pattern:

Perform checks.
Update state.
Call external contracts.

If a malicious token attempts to reenter fillOrder, the nonce has already been marked as used.

The nonReentrant modifier adds another layer of protection.

If a later token transfer fails, the complete transaction reverts, including the nonce update.

The order is not permanently consumed by a failed settlement.

Step 7: Transfer both assets

The taker sends the requested payment token to the maker:

IERC20(order.buyToken).safeTransferFrom(
    msg.sender,
    order.maker,
    order.buyAmount
);

The maker sends the offered token to the taker:

IERC20(order.sellToken).safeTransferFrom(
    order.maker,
    msg.sender,
    order.sellAmount
);

Both operations happen inside the same transaction.

The settlement has only two valid outcomes:

Both transfers succeed

or:

The entire transaction reverts

This is the atomic property of the exchange.

The maker should not lose tokens without receiving payment.

The taker should not send payment without receiving the purchased asset.

Signing the order with Viem

The frontend may use signTypedData to request the maker’s signature.

import type {
  Address,
  Hex,
  WalletClient
} from "viem";

type TypelexOrder = {
  maker: Address;
  taker: Address;
  sellToken: Address;
  buyToken: Address;
  sellAmount: bigint;
  buyAmount: bigint;
  nonce: bigint;
  deadline: bigint;
};

const orderTypes = {
  Order: [
    { name: "maker", type: "address" },
    { name: "taker", type: "address" },
    { name: "sellToken", type: "address" },
    { name: "buyToken", type: "address" },
    { name: "sellAmount", type: "uint256" },
    { name: "buyAmount", type: "uint256" },
    { name: "nonce", type: "uint256" },
    { name: "deadline", type: "uint256" }
  ]
} as const;

export async function signTypelexOrder(
  walletClient: WalletClient,
  maker: Address,
  settlementContract: Address,
  chainId: number,
  order: TypelexOrder
): Promise<Hex> {
  if (
    order.maker.toLowerCase() !== maker.toLowerCase()
  ) {
    throw new Error(
      "Connected wallet does not match the order maker"
    );
  }

  if (
    order.sellAmount <= 0n ||
    order.buyAmount <= 0n
  ) {
    throw new Error(
      "Order amounts must be greater than zero"
    );
  }

  const currentTimestamp =
    BigInt(Math.floor(Date.now() / 1000));

  if (order.deadline <= currentTimestamp) {
    throw new Error(
      "Order deadline has already passed"
    );
  }

  return walletClient.signTypedData({
    account: maker,
    domain: {
      name: "Typelex",
      version: "1",
      chainId,
      verifyingContract: settlementContract
    },
    primaryType: "Order",
    types: orderTypes,
    message: order
  });
}

The frontend definitions must match Solidity exactly.

Double-check:

Field names
Field order
Solidity types
Protocol name
Protocol version
Chain ID
Verifying contract

A single mismatch creates a different signature digest.

Example order

Imagine that the maker wants to sell 100,000 tokens for 500,000 USDC.

The order is restricted to one counterparty and expires after ten minutes.

const order: TypelexOrder = {
  maker: "0xMakerWallet",
  taker: "0xApprovedTaker",
  sellToken: "0xTokenAddress",
  buyToken: "0xUSDCAddress",
  sellAmount: 100_000n * 10n ** 18n,
  buyAmount: 500_000n * 10n ** 6n,
  nonce: 84n,
  deadline:
    BigInt(Math.floor(Date.now() / 1000)) + 600n
};

Notice the difference in decimals.

The example assumes:

the offered token uses 18 decimals;
USDC uses 6 decimals.

The contract works with integer units.

It does not understand a human-readable value such as 500,000 USDC unless the frontend converts it correctly.

A valid signature does not guarantee settlement

This point is critical.

A valid signature proves that the maker authorized the order.

It does not prove that the maker can still complete it.

Before settlement, the maker may:

transfer the tokens elsewhere;
revoke the contract allowance;
spend part of the balance;
become blacklisted by the token issuer;
sign several orders backed by the same funds.

A complete settlement check therefore includes more than signature verification.

Is the signature valid?
Is the nonce unused?
Is the order unexpired?
Is the taker authorized?
Does the maker have enough balance?
Is the allowance sufficient?
Are token transfers currently enabled?

A well-designed interface should simulate the transaction before asking the taker to submit it.

However, the smart contract must remain the final source of truth.

Why the maker needs an allowance

The example uses a non-escrowed model.

The maker keeps the offered tokens until the order is filled.

During settlement, the contract calls:

safeTransferFrom(
    order.maker,
    msg.sender,
    order.sellAmount
);

The maker must approve the settlement contract before execution.

This creates a trade-off.

Advantage

The maker does not need to lock assets when signing a quote.

Disadvantage

The quote may become unfillable if the balance or allowance changes.

A signature is therefore an authorization, not proof that liquidity is reserved.

Replay protection

Without replay protection, the same signed order could be executed repeatedly.

The contract prevents this with:

nonceUsed[maker][nonce] = true;

After a successful fill, the nonce cannot be used again.

The maker can also cancel an unused nonce:

function cancelNonce(
    uint256 nonce
) external {
    if (nonceUsed[msg.sender][nonce]) {
        revert NonceAlreadyUsed();
    }

    nonceUsed[msg.sender][nonce] = true;

    emit NonceCancelled(
        msg.sender,
        nonce
    );
}

This cancellation requires an onchain transaction.

That is one of the central trade-offs of offchain orders:

Creating a quote can be free, but guaranteed cancellation still requires an onchain state update.

Better cancellation models

A production protocol may use a more advanced cancellation system.

Minimum valid nonce

The maker stores a minimum acceptable nonce:

mapping(address => uint256)
    public minValidNonce;

If the maker raises the value from 100 to 200, every order below 200 becomes invalid.

Benefit: Many old orders can be cancelled in one transaction.

Trade-off: Nonce ordering becomes part of the protocol logic.

Nonce bitmap

Nonce states can be grouped into bitmaps.

This may reduce storage costs when large numbers of orders are filled or cancelled.

Benefit: Efficient storage.

Trade-off: More complex implementation and testing.

Order-hash cancellation

The contract stores the hash of each cancelled order.

Benefit: Precise cancellation.

Trade-off: A new storage entry is required for every cancelled order.

Short expiration windows

RFQ orders may expire after a few minutes.

Benefit: Stale quotes disappear quickly.

Trade-off: Expiration does not replace explicit cancellation while the order remains valid.

Smart-wallet signatures can change over time

An EOA signature normally remains valid for the same digest unless the private key is compromised.

A smart-contract wallet behaves differently.

Its validation rules may change after:

an owner is removed;
the signing threshold changes;
a module is disabled;
the wallet contract is upgraded;
recovery logic is triggered.

A signature that was valid earlier may no longer be valid when settlement occurs.

That is why ERC-1271 signatures should be checked at execution time.

Fixed price and zero slippage

The order defines exact quantities:

100,000 TOKEN
for
500,000 USDC

The contract does not query an AMM pool to calculate the output.

Therefore, the rate does not gradually deteriorate as the order consumes liquidity.

This provides:

Zero execution slippage relative to the signed order terms.

It does not guarantee:

the best market price;
a fair OTC quote;
future token value;
stablecoin peg stability;
economic profitability.

The smart contract guarantees execution consistency.

It does not evaluate the quality of the negotiation.

Fixed pricing reduces some MEV exposure

A traditional sandwich attack depends on changing the state of a public liquidity pool around a victim’s swap.

The attacker modifies the pool price before the victim’s transaction and trades again afterward.

A signed Typelex order does not use the external pool to determine its output.

A bot cannot change:

500,000 USDC for 100,000 TOKEN

into:

500,000 USDC for 95,000 TOKEN

by trading against a public AMM before settlement.

The order contains exact amounts.

However, this does not mean the transaction is fully MEV-proof.

An observer may still:

see the pending transaction;
compete for block inclusion;
attempt to delay the transaction;
identify the participating wallets;
trade on another venue;
react to later hedging activity.

The architecture protects fixed settlement terms from AMM-based repricing.

It does not provide complete privacy or eliminate every form of MEV.

Fee-on-transfer tokens

The contract assumes that transferring 100 units causes the recipient to receive exactly 100 units.

That assumption is not valid for every token.

A fee-on-transfer token may behave like this:

Requested transfer: 100,000
Recipient receives: 98,000

SafeERC20 helps with inconsistent ERC-20 return values, but it does not guarantee that the recipient received the nominal amount.

Possible protocol policies include:

Allowlisting reviewed tokens
Rejecting fee-on-transfer assets
Checking balances before and after transfers
Using token-specific adapters
Defining settlement by actual received amounts

Balance checks are also imperfect for rebasing tokens.

Token compatibility should therefore be a documented protocol decision.

Approval risk

Many applications ask users for unlimited token approvals.

That improves convenience, but it also increases the consequences of a contract vulnerability.

Safer alternatives include:

approving only the amount required for one order;
using permit-based approvals when available;
displaying active allowances in the interface;
separating settlement contracts by version;
resetting allowances after use.

There is no universal best option.

The protocol must balance:

user experience;
gas cost;
contract complexity;
approval exposure.

Overcommitted orders

A maker may sign several orders using the same balance.

For example:

Maker balance: 1,000,000 TOKEN

Order A: Sell 1,000,000 TOKEN
Order B: Sell 1,000,000 TOKEN
Order C: Sell 1,000,000 TOKEN

All three signatures may be valid.

But after Order A executes, Orders B and C may fail because the maker no longer has enough tokens.

Offchain signatures do not reserve inventory.

Possible solutions include:

using escrow;
creating very short-lived RFQ quotes;
exposing outstanding order liabilities;
limiting active nonce ranges;
accepting that signed quotes are not guaranteed liquidity.

Escrowed versus non-escrowed orders

Both approaches have advantages.

Non-escrowed signed orders

The maker signs offchain and keeps the assets until settlement.

Advantages:

no transaction is required to create an order;
unused quotes cost no gas;
funds remain available until execution;
the model works well for RFQ systems.

Trade-offs:

the maker may lose balance or allowance;
several orders may compete for the same assets;
the taker has less certainty that the order is fillable.

Escrowed orders

The maker deposits tokens into a smart contract before settlement.

Advantages:

the assets are reserved;
the taker has stronger execution certainty;
overcommitting the same balance becomes harder.

Trade-offs:

order creation requires gas;
funds remain locked;
unused orders still create onchain state;
escrow-contract risk becomes more important.

A hybrid protocol could support both models.

Short-lived RFQ quotes may use signatures, while large strategic transactions may use isolated escrow.

Security tests worth writing

A production implementation needs more than a few unit tests.

It should include:

unit tests;
fuzz testing;
integration tests;
invariant testing;
adversarial token mocks.

At minimum, the following properties should be tested.

The same nonce cannot execute twice

First fill: succeeds
Second fill: reverts

A cancelled nonce cannot execute

After cancellation, every signature using that maker and nonce must fail.

An expired order cannot execute

Test:

one second before expiration;
exactly at expiration;
one second after expiration.

The contract should clearly define its boundary behavior.

Changing any field invalidates the signature

Modify each field independently:

maker;
taker;
sell token;
buy token;
sell amount;
buy amount;
nonce;
deadline.

Every modified order must fail verification.

A signature cannot be replayed on another contract

Deploy two settlement contracts.

A signature created for Contract A should fail on Contract B.

A signature cannot be replayed on another chain

A different chain ID should produce a different digest.

Only the approved taker can fill a private order

Possessing the signed order must not be enough for an unauthorized wallet.

Failed transfers restore the nonce state

If either token transfer fails, the entire transaction should revert and the nonce should remain unused.

Reentrancy cannot settle the order twice

Tests should use malicious token contracts capable of making callback attempts.

Smart-wallet signatures work correctly

Test ERC-1271 validation and changes to wallet configuration.

What Typelex gains from signed orders

This architecture offers several practical benefits.

Lower cost for unused quotes

Quotes that expire without being filled never create onchain storage.

Faster RFQ workflows

Market makers can create quotes without waiting for a transaction to confirm.

Controlled distribution

A signed order can be sent directly to one intended counterparty.

Fixed settlement conditions

The signature commits the maker to:

exact token addresses;
exact quantities;
one nonce;
one deadline;
an optional taker wallet.

Flexible execution

The taker or an approved relayer can submit the final transaction.

Broader wallet support

The system can support:

ordinary wallets;
multisigs;
smart accounts;
contract-based treasuries.

These advantages do not remove the need for:

correct pricing;
sufficient balances;
token allowances;
replay protection;
token compatibility policies;
contract security.

Final thoughts

An onchain OTC protocol does not need to publish every quote to the blockchain.

EIP-712 allows Typelex to represent an order as structured data, collect the maker’s authorization offchain, and verify it only when settlement happens.

The full flow is:

Define the order terms
          ↓
Sign typed data offchain
          ↓
Send the order to the taker
          ↓
Verify the signature onchain
          ↓
Check nonce, deadline, and wallet
          ↓
Transfer both assets atomically

The signature itself is not the hardest part.

The difficult work is designing the complete order lifecycle:

Replay protection
Cancellation
Wallet restrictions
Allowance management
Smart-account support
Stale quote handling
Overcommitted balances
Nonstandard token behavior
Atomic state transitions

Typelex can use this architecture to separate two responsibilities.

Counterparties or RFQ systems determine the economic terms.

The smart contract verifies authorization and enforces settlement.

That separation can make OTC execution more gas-efficient without turning every offchain quote into a trusted manual exchange.

Disclosure: This article was prepared with AI assistance and reviewed before publication.

Bypassing AMM Slippage: How Typelex Uses On-Chain Atomic Swaps for MEV-Proof OTC Trading

Typelex — Wed, 15 Jul 2026 12:39:04 +0000

If you’ve ever built or interacted with DeFi protocols, you know the mathematical limitations of Constant Product Market Makers ($x \times y = k$). While AMMs are great for retail liquidity, executing a large transaction (e.g., $100,000+) directly against a liquidity pool triggers two major issues:

Severe Slippage: The marginal price of the asset degrades exponentially relative to the trade size.
MEV Exploitation (Sandwich Attacks): Public mempool transactions are highly vulnerable. Front-running bots will buy the asset ahead of your execution block, push the price up to your maximum slippage limit, and dump it immediately after.

To solve this without relying on centralized, custodial desks or risky off-chain escrow setups, we built Typelex—a decentralized, non-custodial P2P OTC protocol.

Here is a look at how we bypassed the AMM bonding curve entirely using on-chain atomic swaps.

The Architecture of an On-Chain Atomic Swap

Instead of routing trades through active liquidity pools, Typelex utilizes isolated smart contracts to execute peer-to-peer trades. The entire swap happens atomically: either all conditions are met within a single block execution, or the entire transaction reverts.

Conceptual Smart Contract Logic (Solidity-based)

To understand how the trustless escrow works under the hood, here is a simplified mental model of the swap execution logic:

struct Order {
    address maker;
    address taker; // address(0) if public
    address tokenA;
    uint256 amountA;
    address tokenB;
    uint256 amountB;
    bool active;
}

mapping(uint256 => Order) public orders;

function takeOrder(uint256 orderId) external {
    Order storage order = orders[orderId];
    require(order.active, "Order not active");
    if (order.taker != address(0)) {
        require(msg.sender == order.taker, "Unauthorized taker");
    }

    order.active = false;

    // Pull Token B from Taker to Maker
    IERC20(order.tokenB).transferFrom(msg.sender, order.maker, order.amountB);

    // Push Token A from Contract Escrow to Taker
    IERC20(order.tokenA).transfer(msg.sender, order.amountA);

    emit OrderExecuted(orderId, msg.sender);
}

Why This Design is Inherently MEV-Proof

By shifting the execution model from AMMs to fixed-rate P2P swaps, Typelex mitigates common mainnet exploits:

Zero Slippage Parameters: Because the exchange rate between Token A and Token B is hardcoded directly into the order struct, there is no price slippage to exploit. MEV searchers cannot sandwich the transaction because the contract will strictly revert if the exact amounts are not cleared.
No Spot Market Footprint: The transaction occurs entirely within the Typelex contract storage states, moving balances directly between the maker's and taker's wallets. No public liquidity pools are touched, meaning the spot price on external trackers remains completely unaffected.
Direct Cryptographic Access Control: For private trades negotiated off-chain, the maker can assign a cryptographic constraint (locking the swap to a specific taker address). Even if a malicious bot views the transaction pending in the mempool, any attempt to hijack or front-run the execution will fail the msg.sender validation check on-chain.

Primary Use Cases for Web3 Developers and DAOs

Treasury Diversification: DAOs can liquidize or diversify native project tokens into stablecoins without signaling market dumps or feeding MEV bots.
Strategic OTC Rounds: Projects can distribute allocations to early investors or partners securely on-chain, ensuring tokens are locked or routed directly to validated contributor wallets.
Gas-Optimized Settlement: By bypassing complex routing paths and multi-hop pool swaps, transactions consume minimal gas, keeping execution costs flat even during network congestion.

Conclusion

We designed Typelex to bring security and structural integrity back to high-volume on-chain trading. By moving OTC completely on-chain, we remove the need to trust intermediaries or centralized escrow services.