Airswap contract choice by token type and adapter support

ERC-20 specialization and adapter-based settlement

SwapERC20 specializes in exchanges where both sides transfer ERC-20 tokens through their token contracts. Its order identifies each wallet, token address, and amount without separate token-kind or item-ID fields. It does not express the individual asset identifiers that an NFT transfer may require.

Swap gives each side a richer description, including a token kind and an ID. It passes transfers to adapters that implement the relevant token interface. A deployment that registers ERC20Adapter can also handle ERC-20 transfers within its configured rules. The choice therefore involves the order format and deployment configuration as well as the token standard.

Both designs place the required token transfers in one atomic transaction. If a required transfer reverts, settlement reverses its token transfers. Ethereum still charges for the gas that the failed execution used.

How does Swap decide which token kinds it accepts?

Swap requires a registered adapter for each token kind and a sender kind that matches the deployment's requiredSenderKind setting. An adapter handles the transfer interface, while the sender restriction determines which kind the transaction sender may supply. Supporting an asset on the signer's side does not automatically permit it on the sender's side.

The contract looks up adapters through the order's kind field. That field identifies the transfer interface, rather than a particular token collection. The token address separately identifies the asset contract.

Swap rejects an order when its sender token kind differs from requiredSenderKind. This restriction gives the two sides different compatibility boundaries. An application must preserve which wallet supplies which asset when preparing the order, even when adapters exist for both token kinds.

An adapter also defines checks for balance, permission, and valid transfer parameters. A recognized kind establishes the transfer mechanism; the actual token and order values must satisfy that mechanism. A registered adapter alone cannot establish that every proposed transfer will succeed.

Token identifiers and amounts describe different things

A token address identifies the contract, while an item ID distinguishes an asset within a token contract that uses IDs. The amount describes the quantity to transfer. Swap keeps these values separate in each party's order data, so a token symbol alone cannot describe the exchange.

ERC20Adapter requires an ID of zero because ERC-20 balances do not use item identifiers. Its parameter check enforces that rule, and its transfer function independently rejects a nonzero ID.

Other token kinds require the parameter rules of their own registered adapters. Swap's transfer interface carries an ID for standards such as ERC-721 and ERC-1155. That shared interface does not establish that every deployment registers adapters for those standards or permits either standard on both sides.

Amounts also need the token's correct unit scale. ERC-20 order quantities use atomic units, which depend on the token's decimals. An asset identifier has a different purpose: changing it selects a different item, while changing an amount changes the quantity.

Approval belongs to the settlement spender

ERC-20 approval must cover the contract that actually spends the tokens during settlement. Swap's ERC20Adapter checks allowance from the token owner's wallet to the calling Swap contract. During transfers, Swap executes the adapter through delegatecall, so the token sees Swap as the spender. The adapter's separate address does not become the approval target merely because it supplies the transfer code.

Both sides need the permissions that their respective transfer paths require. A sufficient balance cannot replace a missing allowance. Likewise, permission for one settlement contract does not authorize a different deployment. The required amount must cover every applicable debit, including additional charges that the selected contract collects from that wallet.

Signing domains keep contract formats distinct

A signature binds the order data to its signing domain, including the network and verifying contract. The SwapERC20 implementation using domain version 4.3 names its domain SWAP_ERC20. The adapter-based Swap implementation uses SWAP with domain version 4.2. Those values identify different signing formats; they are not interchangeable labels for a single order.

The application must construct the fields that the selected contract expects before requesting a signature. Copying amounts into another contract's layout does not preserve the original authorization. Request-for-quote negotiation can supply an order, but the settlement contract determines its required structure.

Native-token handling uses a separate component

The native currency of an EVM network does not expose the ERC-20 transferFrom interface. The protocol includes a separate Wrapper component for native-token handling. An ERC-20 order still identifies token contracts, so a native balance and a wrapped-token balance have different roles. The selected application must support the relevant native-token wrapper arrangement.

Protocol fee payers and NFT royalties affect the required balance

The two contract implementations collect protocol fees from different sides of the exchange. In SwapERC20's SWAP_ERC20 4.3 implementation, the signer funds the protocol fee in the signer's token, using signerAmount as its base. In the regular swap method, the caller's balance in a configured staking token can determine a bonus. A positive bonus redirects part of that same signer-funded fee to the caller, while the fee wallet receives the remainder.

Swap's SWAP 4.2 implementation instead collects its protocol fee from the sender, using the sender's amount and token. An optional affiliate payment also comes from that side when the order specifies an affiliate wallet. These charges increase the sender's debit beyond the amount that goes to the signer. The signer supplies the asset amount that the order specifies.

If the signer's token reports EIP-2981 royalty support, Swap requests royalty information for its token ID and the sender's amount. A positive royalty adds another sender-side payment in the sender's token. The execution call supplies maxRoyalty and rejects a royalty above that limit. These conditions make the selected contract and method relevant to the balance and permission requirements, even when the principal token amounts match.

Which contract matches the proposed exchange?

SwapERC20 matches an ERC-20-only order format; Swap matches an adapter-based order only when the deployment supports its exact asset roles. Compare the proposed exchange against the conditions that control those formats:

• Both assets use ERC-20 transfers: SwapERC20 provides the specialized order layout; a compatible Swap deployment may also support their transfers.
• An asset needs an item ID: the adapter-based format must carry that ID and have the appropriate registered adapter.
• The sender supplies a particular token kind: it must match Swap's requiredSenderKind, even if the deployment registers another adapter.
• Settlement uses ERC20Adapter: allowance must name the Swap deployment that executes the transfer.
• The exchange involves native currency or an NFT royalty: the supported wrapper arrangement or royalty conditions must fit the selected path.

When an application changes the settlement contract, it must also match that contract's order format and spender permissions.

View image file