Typelex: Fixed-Price P2P OTC Settlement Through Atomic Smart Contracts

Typelex: Fixed-Price P2P OTC Settlement Through Atomic Smart Contracts

A technical overview of direct wallet-to-wallet trades without AMM execution

Disclaimer

This thread is intended to explain the technical settlement model behind Typelex and collect feedback from the community.

It does not contain investment promises, guaranteed returns, a token sale, or claims that smart-contract trading is risk-free.

Typelex should not be described as completely private, entirely trustless, or immune to every form of MEV. The purpose of the protocol is narrower: to provide fixed-price atomic settlement for negotiated OTC trades without routing the order through a public AMM pool.

What is Typelex?

Typelex is a non-custodial P2P OTC protocol designed for direct onchain exchanges between two wallets.

The basic idea is simple:

Two counterparties agree on the assets and quantities before execution.
The agreed terms are recorded in an isolated smart contract.
The contract verifies the wallets, tokens, amounts, and other order conditions.
Both sides of the trade settle atomically.
If the conditions are not satisfied, the transaction reverts.

Unlike a conventional DEX swap, the order is not routed through a public liquidity pool.

Typelex therefore uses the blockchain primarily as a settlement layer. The protocol is not intended to calculate the market price through an AMM curve after the counterparties have already agreed on a price.

Why not execute every large trade through an AMM?

Automated market makers are useful because they provide continuously available liquidity without requiring a trader to negotiate with a specific counterparty.

In a simplified constant-product pool, the reserves are connected through the formula:

Code:

x × y = k

When a trader removes one token from the pool and supplies another, the reserve ratio changes. The price therefore changes during execution.

For small trades relative to the available liquidity, the difference may be limited.

For a large order, several issues become more important:

Execution slippage: the average execution price can become worse as the order consumes liquidity.
Direct pool impact: a large trade changes the token reserves and moves the pool price.
MEV exposure: bots may identify a pending swap whose output depends on the current pool state.
Execution uncertainty: the amount shown before confirmation may differ from the final output.
Complex routing: aggregators may divide the trade across several pools and intermediate assets.

An OTC trade begins from a different position.

The participants may already know:

which tokens they want to exchange;
the exact amount on each side;
the final exchange rate;
the approved counterparty;
the deadline for settlement.

Once these terms are fixed, the primary problem is no longer finding a price.

It is making sure that both sides settle correctly.

Separating negotiation from settlement

Typelex separates two processes that are often combined inside a DEX swap.

1. Negotiation

The participants determine the commercial terms of the trade.

The price may be based on an RFQ quote, market-maker offer, oracle reference, exchange price, or private agreement.

2. Settlement

The smart contract checks whether the transaction matches the agreed parameters.

The contract does not need to decide whether the price is attractive. It only needs to enforce the order that the participants accepted.

This distinction is important.

A smart contract can guarantee that a trade follows predefined conditions, but it cannot guarantee that those conditions represent fair market value.

Example of an order structure

A simplified Typelex-style order could contain the following data:

Code:

struct Order {
address maker;
address taker;

```
address sellToken;
address buyToken;

uint256 sellAmount;
uint256 buyAmount;

uint256 expiry;
OrderStatus status;
```

}

The parameters define:

Maker: the wallet creating the order.
Taker: the wallet authorized to accept it.
Sell token: the asset supplied by the maker.
Buy token: the asset requested in return.
Sell amount: the exact quantity offered.
Buy amount: the exact quantity expected.
Expiry: the point after which the order cannot execute.
[b>Status:[/b] whether the order is open, filled, or cancelled.

A real implementation may require additional parameters such as:

chain ID;
nonce;
fee information;
token allowlists;
signature data;
cancellation rules;
replay protection;
partial-fill settings;
settlement-contract version.

The more features a settlement protocol supports, the more state transitions and edge cases must be tested.

Atomic settlement

Atomicity means that both sides of the trade are completed inside the same transaction.

Consider an order where:

Code:

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

[list=1]

Both transfers complete successfully.
The entire transaction reverts.

There should be no final state where one participant has transferred the required asset but has not received the asset promised by the counterparty.

This is one of the main advantages of smart-contract settlement over manual wallet-to-wallet OTC execution.

Without atomic settlement, one party may need to send first and trust the second party to complete the deal later.

With atomic execution, the contract enforces both sides together.

What “no slippage” means in this model

The phrase “zero slippage” is often used too broadly.

A more accurate description is:

Quote

The transaction has no execution slippage relative to the fixed parameters of the accepted order.

Suppose the order specifies:

Code:

100,000 TOKEN for 500,000 USDC

The settlement contract expects those exact amounts.

It does not query an external AMM and gradually recalculate the output as the trade consumes pool liquidity.

The contract either executes the predefined exchange or rejects the transaction.

However, this does not guarantee that the OTC price is the best available price.

The external market may move after the order is created. One of the assets may become more volatile. A stablecoin may temporarily deviate from its expected peg.

Typelex can enforce the agreed price.

It cannot determine whether the participants negotiated a good deal.

Private orders and wallet restrictions

Some OTC orders are public and may be accepted by any wallet.

Other orders are negotiated for one specific counterparty.

A private order can include the approved taker address:

Code:

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

If the taker field contains a specific address, another wallet cannot execute the order.

This helps prevent a third party from taking a negotiated offer intended for someone else.

It also reduces the usefulness of transaction-ordering strategies that rely on filling the order before the approved participant.

The restriction should normally rely on

Code:

msg.sender

, not

Code:

tx.origin

, because multisig wallets, smart accounts, and relayers may interact through contracts.

MEV resistance has limits

A conventional sandwich attack depends on the output of a swap being affected by the state of a public liquidity pool.

The attacker changes the pool state before the victim’s transaction and trades again afterward.

A fixed-price Typelex order does not calculate its output from that external pool.

A bot cannot change:

Code:

500,000 USDC for 100,000 TOKEN

into:

Code:

500,000 USDC for 95,000 TOKEN

see the pending transaction;
compete on transaction fees;
attempt to delay its inclusion;
identify the participating wallets;
trade on another venue after observing the order;
react to later hedging or selling activity.

Typelex is intended to reduce exposure to AMM-based repricing and sandwich execution.

It does not provide full transaction privacy or eliminate every possible form of MEV.

Direct settlement and market impact

When a large swap passes through an AMM, it changes the reserves inside that pool.

A direct OTC transfer does not modify the reserves of an external pool because it does not use that pool for settlement.

The more precise claim is:

Quote

A Typelex OTC settlement does not directly consume external AMM liquidity or mechanically move its pricing curve.

This does not mean the trade has no broader market consequences.

The transaction may still be visible onchain. A counterparty may later sell the received tokens. A market maker may hedge the position elsewhere. Analytics platforms may identify and label the wallets.

The protocol reduces the direct execution footprint inside public liquidity pools.

It does not make large transfers invisible to the market.

Escrow and the meaning of non-custodial

Depending on the final implementation, the asset offered by the maker may be temporarily held by an isolated settlement contract.

During that period, the tokens are no longer inside the maker’s wallet.

The model is described as non-custodial because a centralized operator should not have discretionary control over the assets.

The contract releases the funds only according to predefined conditions, such as:

successful settlement;
maker cancellation;
expiration and refund;
explicit emergency procedures.

Users still depend on the security of:

the smart-contract code;
the deployment configuration;
administrative permissions;
upgrade mechanisms, if any;
the token contracts being exchanged;
the audit and testing process.

Non-custodial does not mean that there are no technical risks.

It means that settlement is governed by contract rules rather than the discretionary actions of a centralized OTC operator.

Token compatibility

Not every ERC-20 token behaves in the same way.

A settlement protocol must decide how it handles:

fee-on-transfer tokens;
rebasing tokens;
blacklistable tokens;
pausable tokens;
tokens with nonstandard return values;
upgradeable token contracts;
tokens that execute callbacks;
assets with unusual decimals.

For example, a token may deduct a transfer fee.

The order may specify a transfer of 500,000 units, while the recipient receives only 495,000.

Possible approaches include:

supporting only approved standard tokens;
maintaining a token allowlist;
checking balances before and after each transfer;
adding token-specific settlement adapters;
rejecting fee-on-transfer and rebasing assets.

Token compatibility should be defined explicitly rather than assumed.

Possible use cases

The settlement model may be relevant when two counterparties have already negotiated a large trade.

Potential examples include:

DAO treasury diversification

A DAO may exchange part of its native-token treasury for stablecoins or other reserve assets without routing the full order through its public liquidity pool.

Strategic token allocations

A project and an investor may settle a predefined token allocation and payment atomically.

Separate contracts may still be required for vesting or lock-up conditions.

Market-maker inventory management

A market maker may exchange one asset for another with an approved counterparty at a fixed quote.

Large stablecoin conversions

Funds and treasuries may negotiate direct exchanges between USDT, USDC, DAI, or other stable assets.

Treasury-to-treasury transactions

Two organizations may settle an agreed exchange without transferring both sides to a centralized OTC desk.

These examples describe possible settlement scenarios, not guaranteed outcomes or recommendations to enter any particular transaction.

What Typelex is not intended to replace

Typelex is not intended to replace every AMM or DEX aggregator.

Public liquidity pools remain useful when:

the trade is relatively small;
the pair has deep liquidity;
the user does not have a specific counterparty;
immediate permissionless execution is more important than a privately negotiated price.

OTC settlement is more relevant when:

the participants already know the trade terms;
the order is large relative to available liquidity;
the final quantities must be fixed;
the order should be restricted to an approved wallet;
direct AMM impact is undesirable;
atomic settlement is required.

AMMs and OTC protocols solve different problems.

Security questions that should be answered

Before a high-value settlement system is considered production-ready, several questions need clear answers:

Can an order be filled more than once?
Can a cancelled or expired order still execute?
Who can cancel an order?
Can an unauthorized wallet fill a restricted order?
What happens if one token transfer fails?
How are fee-on-transfer tokens handled?
Can a malicious token reenter the settlement function?
How are escrowed balances accounted for?
Are contracts upgradeable?
Who controls upgrades or emergency functions?
Are administrative actions protected by a multisig and timelock?
Have the contracts been independently audited?
Are deployed addresses and source code publicly verifiable?

These questions are more important than broad claims such as “fully secure” or “MEV-proof.”

Summary

Typelex is based on a straightforward architectural principle:

Quote

Negotiate the trade first and use the blockchain to enforce settlement afterward.

The order defines the assets, quantities, wallets, and deadline.

The smart contract checks the conditions.

Both sides settle atomically, or the transaction reverts.

Because the exchange does not depend on an AMM pricing curve, the predefined execution rate cannot deteriorate through pool slippage.

Because access can be restricted to a particular wallet, an unrelated participant cannot simply take a private order.

Because the transaction bypasses public liquidity pools, settlement does not directly alter their reserves.

At the same time, the protocol does not guarantee a fair negotiated price, transaction privacy, complete MEV elimination, or the absence of smart-contract risk.

Those limitations should be part of any serious discussion about onchain OTC infrastructure.

Questions for the community

I would be interested in hearing opinions from developers and experienced OTC users:

[list=1]

Would you prefer escrowed orders or offchain signed orders settled only when filled?
Should private OTC orders always be restricted to one taker wallet?
Should the protocol support only allowlisted tokens?
Are partial fills useful for OTC settlement, or do they add unnecessary risk?
Would a minimal proxy per order provide meaningful isolation compared with a shared settlement contract?
Which MEV risks remain most relevant when the execution price is fixed?

Constructive criticism of the architecture and its assumptions is welcome.