@sauce/token

// Pays `amount` of `token` from the Pot to `to` and returns `to`'s new balance.
function main(token: Address, to: Address, amount: Uint256): Uint256 {
  transfer(token, to, amount);
  return balanceOf(token, to);
}

import { balanceOf, transfer } from "@sauce/token";

// The same program with the functions imported by name.
function main(token: Address, to: Address, amount: Uint256): Uint256 {
  transfer(token, to, amount);
  return balanceOf(token, to);
}

​

On EVM chains

​

Reads

​

Writes

• Empty return data is success only from an address with code. A token that returns nothing, such as USDT, works. A write to an address with no code reverts, so a mistyped address cannot pass silently.
• A non-empty reply must contain at least 32 bytes, with the first word equal to 1. A false return, a shorter reply or a first word other than 1 fails the check.
• approve is forceApprove. It reads the Pot’s current allowance for the spender, and when that is not zero, sets it to zero before setting the new amount. USDT refuses to change one non-zero allowance to another, so an approve works only from zero.
• Writes return nothing. A write either succeeds or raises a failure. An unhandled failure reverts the cook; EVM programs can use the documented catch boundaries to handle one.
• transferFrom spends an allowance. from must have approved the Pot for at least amount.

​

Signatures: permit and permitTransferFrom

• permit submits an EIP-2612 permit(owner, spender, value, deadline, v, r, s) and then requires the token’s nonce for owner to have moved by exactly one. A token with no permit but a permissive fallback, such as WETH9, would otherwise pass for one that granted the allowance. A transferFrom then spends the allowance. The token must have nonces(address), or the nonce read reverts.
• permitTransferFrom calls Permit2’s signature transfer, moving amount from owner to the Pot on owner’s one-time signature. Permit2 spends nonce, rejects an expired deadline, and moves the tokens with the same empty-or-true check.

// Pulls `amount` USDC from `owner` into the Pot on a Permit2 signature, then pays it to `to`.
function main(owner: Address, amount: Uint256, nonce: Uint256, deadline: Uint256, signature: bytes, to: Address) {
  permitTransferFrom(USDC, owner, amount, nonce, deadline, signature, Permit2.Permit2);
  USDC.transfer(to, amount);
}

​

On Solana

​

Reads

• A token account must be owned by SPL Token, or by Token-2022 with the base account layout or an account-type byte of 2. A mint, a multisig or any other account is refused with not a token account, and an account of another mint with wrong mint.
• totalSupply and decimals take the mint as an Account, not an Address. The account must be an initialized mint of either program, or the read fails with not a mint or uninitialized mint.
• ownerOf returns the holder recorded in the token account, not the authority a write is signed by. SPL accepts the account’s delegate as the authority too, so a program that measures its own balance requires ownerOf(token, account) to equal the authority first.
• allowance reads the account’s single delegate. It returns the delegated amount when the account has a delegate and the delegate is spender, and 0 otherwise. A revoked delegate reads as 0.

​

Writes

• transfer, transferFrom and approve call SPL Token’s plain instructions. They require tokenProgram to be SPL Token (not the token program), source to be an SPL Token account (not a token account) of token (wrong mint), and amount to fit 64 bits (amount over u64). A Token-2022 callee or account is refused. transferFrom is transfer: SPL Token has one transfer instruction, and the authority you attach decides whether the owner or a delegate moves the funds.
• transferChecked and approveChecked carry the mint and its decimals. They require the callee to be SPL Token or Token-2022, the source, destination (for a transfer) and mint to be owned by that program, mint to be the named token, and decimals to be the mint’s own (wrong decimals).
• A Token-2022 mint whose transfer hook names a program is refused with transfer hook, before anything moves. The hook’s extra accounts cannot be carried in a fixed account list. A hook extension that names no program is no hook. An approval runs no hook, so approveChecked does not check for one.
• The other Token-2022 extensions are the token program’s to apply. A transfer fee is withheld from what the destination receives, so measure the balance that arrived. A paused mint or a frozen account refuses the transfer with the token program’s own error, and amounts are always raw base units.
• approve sets one delegate. SPL Token tracks a single delegate per account, so a second approve replaces the first, where an ERC-20 keeps an allowance per spender.
• Amounts are 64-bit. An approval of 2^256 - 1, which an ERC-20 accepts, reverts with amount over u64.

​

The token methods choose the write

// Pays `amount` PYUSD (a Token-2022 mint) from the Pot to `to`, and returns what arrived.
function main(to: Address, amount: Uint256): Uint256 {
  const before = to.PYUSD;
  PYUSD.transfer(to, amount);
  return to.PYUSD - before;
}

// Moves `amount` of `mint` from `source` to `destination` with the checked transfer, and
// returns what `destination` received.
function main(
  tokenProgram: Account,
  source: Account<Writable>,
  mintAccount: Account,
  destination: Account<Writable>,
  authority: Account<Signer>,
  mint: Address,
  amount: Uint256
): Uint256 {
  const before = balanceOf(mint, destination);
  transferChecked(mint, tokenProgram, source, mintAccount, destination, authority, amount, decimals(mintAccount));
  return balanceOf(mint, destination) - before;
}

​

Next steps

• @sauce libraries: importing, and the EVM and Solana implementations.
• @sauce/router: swaps at each venue, built on these writes.
• Names: token symbols, pot.<TOKEN> and the token methods.
• EVM and Solana: accounts, token programs and size limits on Solana.
• token namespace: the TypeScript API that emits these calls for a host program.