Skip to main content

Checklist

First: prove you control the contract​

Nothing below can start until your institution has been shown to control the calling contract. A wallet can answer that question by signing. A contract holds no key, so what gets read instead is who controls it — and the authorization in the next section is blocked on the answer.

  • Your contract's owner() returns a wallet already proven for your institution. In the common case this is the whole check, and it costs nothing beyond deploying with the right owner. Where control sits with a multi-signature wallet or behind role-based access control, the equivalent controlling addresses are read instead.
  • You can prove ownership of that wallet. Ask your Sales Contact what proving it involves. It is part of onboarding, and it is the step everything below waits on.
  • Ownership is not renounced. A contract with no owner reads as uncontrolled and is not authorized in that state. Renouncing cannot be undone, so the address cannot become authorized later either.
  • You tell your Sales Contact before ownership moves. What gets recorded is the owner at the time of the check, not the contract itself, so it does not survive a transfer.
  • If your contract is upgradeable, the upgrade authority is read as well — whoever can upgrade it can change everything it does. On the template contract these are the same key.

Where the owner is itself a contract — a multi-signature wallet, most commonly — there is no key to sign with, so ask your Sales Contact what to provide instead.

What Franklin Templeton must do first​

None of this is self-service, and none of it starts before the section above is satisfied. The pair itself must be authorized before any call on it can succeed, and where the pair enforces per-account authorization — as the pairs in service do — your contract must be authorized as a trader on it too: the contract's address, not your wallet's. See Your contract is the trader.

What you need​

  • A deployed smart contract on the target network — this is the caller, not an externally owned account acting alone
  • The pool and token contract addresses for your network — provided during onboarding
  • An RPC endpoint for the target network
  • Native currency for gas in the wallet that signs the transaction
  • The token you are swapping from, held by the calling contract — not the destination, and not the signing wallet
  • An ERC-20 allowance granted to the pool by the contract, for the token you are swapping from
  • Only if the output goes to an address other than the calling contract: the destination is authorized on that pair (from Franklin Templeton — the same authorization your contract holds, applied to the destination address) and a per-destination approval your contract grants itself

Before you ship​

  • Your contract is the authorized trader, holds the input tokens, and grants its own destination approval
  • You request quotes as your contract's address — the fee is per-caller
  • You pass a floor derived from a fresh quote, taken immediately before you trade
  • You round your input down to the output token's precision, and read both tokens' decimals from the pool rather than from the token contracts
  • Your contract is onboarded on the fund token as well as on the pool
  • You keep your own list of permitted recipients and check it before granting anything
  • You handle refusals that do not decode as readable text — see When a swap is refused
  • You never send native currency with a call
  • You have decided how tokens leave your contract. A contract with no way to move tokens out will hold them indefinitely, and that function cannot be added later unless the contract is upgradeable.