DEV Community: Cabledex

Why Large OTC Trades Should Not Be Forced Through Public DEX Liquidity

Cabledex — Wed, 29 Jul 2026 13:52:48 +0000

Public DEXs are built for open-market swaps.

A user selects two tokens, the protocol finds available liquidity, and the final exchange result is calculated during execution.

That model is useful when price discovery is still needed.

But an OTC transaction usually begins from a different point:

The buyer and seller have already agreed on the assets, amounts, rate, and counterparty.

In this situation, routing the transaction through public liquidity may create complexity that the deal never needed.

Cabledex provides a separate on-chain settlement model for negotiated OTC transactions.

The Problem Is Not Finding a Price

Imagine two participants have already agreed on a direct token exchange.

They know:

which assets will be transferred;
the exact amount provided by each side;
the exchange rate;
the participating wallets;
the period during which the offer remains valid.

The price has already been negotiated.

The remaining task is settlement.

A public AMM still treats the transaction as an open-market swap. It calculates the result from pool conditions at the moment of execution.

That means the final result may depend on:

available liquidity;
transaction size;
pool balance;
aggregator routing;
intermediary assets;
transactions processed earlier.

Cabledex separates price negotiation from transaction execution.

Public Swap vs. OTC Settlement

The difference can be summarized simply:

Public DEX swap Cabledex OTC order
Price calculated during execution Rate defined before execution
Uses shared liquidity pools Assets supplied by counterparties
Open to the market Can be restricted to one wallet
May involve multiple routes Direct settlement path
Result depends on pool conditions Result depends on order conditions

Neither model replaces the other.

Public DEXs are useful for immediate swaps. OTC infrastructure is more suitable when the deal has already been defined.

What a Cabledex Order Contains

A Cabledex order can include:

the asset offered by the maker;
the asset expected in return;
the exact amount of each token;
the approved counterparty;
the expiration time;
the execution conditions.

The smart contract does not search for a better market rate.

It has a narrower role:

Check whether the agreed transaction can be completed exactly as defined.

If the conditions match, settlement proceeds.

If they do not match, the transaction is rejected.

A Direct Settlement Path

Large DEX swaps may be divided across several liquidity sources.

A single transaction can interact with:

Token A
↓
Liquidity Pool 1
↓
Intermediate Token
↓
Liquidity Pool 2
↓
Token B

This routing may improve open-market execution, but it also introduces more dependencies.

A negotiated Cabledex transaction follows a simpler structure:

Wallet A
↓
Cabledex smart contract
↓
Wallet B

The participants already know the assets and amounts, so the protocol does not need to search for a route across external pools.

The settlement path is defined by the agreement, not by available public liquidity.

Fixed Amounts Before Approval

An OTC order begins with predefined amounts.

For example:

Maker sends: Token A
Counterparty sends: Token B
Exchange rate: Fixed
Approved wallet: Specified
Expiration: Specified

These values do not automatically change because:

another swap was executed first;
liquidity moved inside an external pool;
an aggregator selected a different route;
market conditions changed before confirmation.

When the original terms are no longer acceptable, the order can remain unexecuted or expire.

The contract does not replace the agreed transaction with a new quote.

Atomic Execution

Direct manual transfers create a basic settlement problem.

One participant usually has to send first.

That side must trust the counterparty to complete the second transfer correctly and on time.

Cabledex uses atomic settlement.

There are only two possible outcomes:

Both asset transfers are completed.
The entire transaction is reverted.

There is no partial state where one side completes its obligation while the other keeps its original assets.

Before execution, the contract can verify:

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

Both sides settle together, or neither side settles.

Orders for Selected Counterparties

Some OTC transactions should not be available to every wallet.

A project may create an allocation for one investor. A DAO may select a specific treasury partner. Two funds may negotiate a direct stablecoin exchange.

Cabledex orders can be restricted to an approved address.

Conceptually, the access check may look like this:

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

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

An order may be visible on-chain without being executable by everyone.

This gives participants a way to combine private negotiation with verifiable blockchain settlement.

When This Model Is Useful
DAO treasury transactions

A DAO can exchange assets with a selected counterparty under predefined terms.

Strategic token allocations

Projects can transfer tokens to approved investors or partners without creating an unrestricted market order.

Stablecoin rebalancing

Two professional participants can exchange stablecoins directly between wallets.

Fund settlements

Funds can complete previously negotiated transactions without depending on the liquidity of one public trading pair.

Large-holder transactions

A token holder can transfer an agreed allocation to a specific buyer instead of routing the entire position through public pools.

Non-Custodial Settlement

Cabledex does not require participants to maintain funds on a shared internal platform balance.

Users interact through their own wallets and approve the required token transfers themselves.

The protocol does not need to:

hold private keys;
manually approve withdrawals;
release funds through an operator;
maintain off-chain user balances;
decide which participant should send first.

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

Users still need to verify token addresses, wallet permissions, transaction details, and the contracts they interact with.

Public Liquidity Is a Tool, Not a Requirement

On-chain trading is often treated as synonymous with AMM execution.

But a transaction can still be:

recorded on-chain;
executed through a smart contract;
transparent;
verifiable;
non-custodial;

without using a public liquidity pool to determine the exchange result.

That is the role of on-chain OTC infrastructure.

Cabledex is designed for transactions where the commercial agreement already exists and only settlement remains.

Final Takeaway

Public DEXs are useful when users need price discovery and immediate market liquidity.

Negotiated OTC deals require something different.

The participants already know the assets, amounts, rate, and counterparty. They need a settlement process that follows those exact conditions.

Cabledex turns a negotiated agreement into a fixed-rate, address-specific, and atomic on-chain transaction.

Terms agreed first. Settlement executed on-chain. No dependence on public liquidity during execution.

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

Cabledex — Mon, 20 Jul 2026 14:49:40 +0000

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

Creating every OTC order directly onchain is simple, but not always efficient.

A maker publishes an order, the contract stores it, and the counterparty fills it later. The problem is that every order consumes gas, including quotes that expire or are never accepted.

For an RFQ-based protocol, many quotes may exist for only a few minutes.

A more efficient model is:

Create the order offchain.
Sign the order using EIP-712.
Send it to the intended counterparty.
Submit it onchain only when settlement is ready.

This article uses Cabledex as a practical example of fixed-price OTC settlement with offchain signatures.

We will cover:

EIP-712 typed orders
Signature verification
Nonce-based replay protection
Restricted taker wallets
Atomic ERC-20 settlement

Note: The following code is educational and should not be used in production without extensive testing and an independent security audit.

Why move quotes offchain?

Imagine that a DAO requests quotes from five market makers.

Only one quote is accepted.

If every quote is created onchain, all five require gas even though four of them are never used.

With signed offchain orders, only the accepted quote reaches the blockchain.

The workflow becomes:

Maker creates a quote
        ↓
Maker signs the order
        ↓
Taker receives the signed quote
        ↓
Taker submits it onchain
        ↓
The contract verifies and settles

This is particularly useful for short-lived RFQ orders.

Defining the order

A simplified Cabledex order may contain:

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

The fields specify:

Maker: the wallet offering the asset
Taker: the wallet allowed to fill the order
Sell token: the asset offered by the maker
Buy token: the asset requested in return
Amounts: the exact quantities being exchanged
Nonce: a unique order identifier
Deadline: the expiration timestamp

The order does not need to be stored onchain when it is created.

The maker signs these parameters instead.

Why EIP-712?

EIP-712 allows wallets to sign structured data rather than an unreadable hexadecimal message.

The signing domain can bind the order to:

the Cabledex protocol;
a specific protocol version;
one blockchain network;
one settlement contract.

A frontend domain may look like this:

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

This reduces the risk of using the same signature in a different context.

However, EIP-712 does not automatically prevent replay attacks. The settlement contract still needs to track used nonces.

Simplified settlement contract

// 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 CabledexSignedOrders 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 => mapping(uint256 => bool))
        public nonceUsed;

    event OrderFilled(
        bytes32 indexed orderHash,
        address indexed maker,
        address indexed taker,
        uint256 nonce
    );

    error InvalidOrder();
    error OrderExpired();
    error NonceAlreadyUsed();
    error UnauthorizedTaker();
    error InvalidSignature();

    constructor() EIP712("Cabledex", "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 {
        if (
            order.maker == address(0) ||
            order.sellToken == address(0) ||
            order.buyToken == address(0) ||
            order.sellToken == order.buyToken ||
            order.sellAmount == 0 ||
            order.buyAmount == 0
        ) {
            revert InvalidOrder();
        }

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

        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.nonce
        );
    }

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

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

This example uses:

EIP712 to construct the typed-data digest
SignatureChecker to support ordinary and smart-contract wallets
SafeERC20 for safer token transfers
ReentrancyGuard to block nested settlement calls

How settlement works

When the taker calls fillOrder, the contract performs several checks.

1. Validate the order

The contract rejects invalid token addresses, identical token pairs, zero amounts, and expired orders.

Frontend validation may improve user experience, but the contract must enforce the actual rules.

2. Check the nonce

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

A successful order marks its nonce as used.

This prevents the same signature from being executed multiple times.

3. Verify the taker

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

When taker is the zero address, the order is public.

When it contains a specific wallet, only that wallet may fill the order.

This is useful for privately negotiated OTC quotes.

4. Verify the signature

The contract reconstructs the order hash and checks whether the maker authorized it.

Changing any signed field invalidates the signature.

A taker cannot secretly change:

500,000 USDC

to:

490,000 USDC

while using the original signature.

5. Transfer both assets

The payment token moves from the taker to the maker.

The offered token moves from the maker to the taker.

Both transfers occur inside one transaction.

The result is:

Both sides settle, or the complete transaction reverts.

Signing the order with Viem

A frontend may create the signature using signTypedData.

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;

const signature = await walletClient.signTypedData({
  account: maker,
  domain: {
    name: "Cabledex",
    version: "1",
    chainId,
    verifyingContract: settlementContract
  },
  primaryType: "Order",
  types: orderTypes,
  message: order
});

The frontend and Solidity definitions must match exactly.

Check:

Field names
Field order
Field types
Protocol name and version
Chain ID
Settlement contract address

Any mismatch will produce a different digest.

A signature does not reserve liquidity

The maker keeps the offered tokens until the trade executes.

That makes order creation cheaper, but it creates an important limitation.

Before settlement, the maker may:

spend the tokens;
revoke the allowance;
transfer the balance elsewhere;
sign several orders using the same funds.

A valid signature proves authorization.

It does not prove that the maker still has enough balance and allowance.

A Cabledex interface should therefore simulate the transaction before the taker submits it.

Fixed price and execution slippage

The order contains exact quantities.

For example:

Maker sends: 100,000 TOKEN
Taker sends: 500,000 USDC

The contract does not calculate the price through an AMM pool.

This means the trade has:

No execution slippage relative to the signed order.

However, this does not guarantee that the quote is fair or remains attractive until expiration.

The external market may move after the maker signs the order.

Cabledex enforces the agreed terms. It does not evaluate the economic quality of the deal.

What about MEV?

A standard sandwich attack depends on changing an AMM pool before and after a user’s swap.

A fixed-price Cabledex order does not use the pool to determine its output.

A bot cannot change the signed quantities by moving an external AMM price.

Still, this should not be described as complete MEV protection.

An observer may still:

detect the pending settlement;
compete for block inclusion;
delay the transaction;
identify the participating wallets;
trade on another venue.

The model protects the fixed execution terms, not the privacy of the transaction.

Important token edge cases

Not every ERC-20 token behaves normally.

A production protocol must consider:

fee-on-transfer tokens;
rebasing assets;
pausable tokens;
blacklisting;
upgradeable token contracts;
nonstandard return values.

For example, a transfer may request 100,000 units while the recipient receives only 98,000.

Possible solutions include:

supporting only reviewed tokens;
rejecting fee-on-transfer assets;
checking balance changes;
using token-specific adapters.

Token compatibility should be a documented protocol policy.

Signed orders versus escrow

Signed orders

The maker keeps the assets until execution.

Benefits:

No gas cost for unused quotes
No locked assets
Fast RFQ workflow

Trade-offs:

Balance or allowance may disappear
Several quotes may use the same funds

Escrowed orders

The maker deposits the offered asset first.

Benefits:

Liquidity is reserved
Greater certainty for the taker

Trade-offs:

Order creation costs gas
Funds remain locked
Unused orders still create onchain state

Cabledex could use signed orders for short-lived quotes and escrow for larger strategic trades.

Security properties to test

A production version should verify that:

A nonce cannot execute twice
A cancelled order cannot execute
An expired order fails
Changing any field invalidates the signature
Only the approved taker can fill a private order
A signature cannot be replayed on another contract or chain
Failed transfers revert the nonce update
Reentrancy cannot settle an order twice
Smart-contract wallet signatures work correctly

Tests should include malicious token contracts, not only standard ERC-20 mocks.

Final thoughts

EIP-712 allows Cabledex to keep OTC quote creation offchain while preserving onchain verification and settlement.

The complete flow is straightforward:

Create the order
       ↓
Sign it offchain
       ↓
Send it to the taker
       ↓
Verify it onchain
       ↓
Settle both assets atomically

The main benefit is not simply lower gas usage.

It is the ability to separate two responsibilities:

Counterparties determine the price and trade conditions.

The smart contract verifies authorization and executes settlement.

This model can make OTC and RFQ workflows more efficient, but it still requires careful handling of nonces, allowances, token behavior, signatures, and contract security.

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

Cabledex — Wed, 15 Jul 2026 12:49:24 +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 Cabledex—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, Cabledex 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, Cabledex 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 Cabledex 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 Cabledex 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.