Setup & Authorization
A swap needs authorizations that Franklin Templeton grants for you. Please request these from your Sales Contact before you plan your first swap — the list of what we need is below.
Swapping iBENJI → stablecoin, send the output to the account that did the swap — which, in a contract-to-contract swap, is your calling contract. This is about recoverability: a misdirected stablecoin cannot be returned by anyone.
A pool may be configured to enforce this, in which case naming a different destination on that direction is refused. Design for the stablecoin arriving at your calling contract regardless — that always succeeds, and it does not depend on how the pool is configured. Holding it there is a perfectly good design; if your contract will ever need to move it onward, build that in before you deploy, since it cannot be added afterwards unless the contract is upgradeable.
Because that enforcement is configuration rather than a fixed property, do not treat a refusal as your only check on the recipient. Validate the destination in your own contract.
Swapping a stablecoin for iBENJI works differently — you may name another destination, subject to the two requirements below.
Sending output to a different address needs two things
If the destination is your own calling contract, skip this section — nothing extra applies.
If it is any other address, two separate permissions apply — we grant the first, and your contract grants the second:
| Requirement | Granted by |
|---|---|
| The destination is an authorized trader on that pair | Franklin Templeton, during onboarding |
| A per-destination approval exists on the swap contract | your own contract, at run time |
You can check this before you swap, with the same call you use to confirm your own authorization — see Check eligibility. So a destination being ready is something you read, not something a refusal tells you.
The swap contract keys that approval on msg.sender, so your contract grants it to itself — a grant sent from your owner wallet writes a record the swap does not read. So onboarding on its own will not complete the picture: without the approval in place, the swap is refused.
The approval also carries a budget and a deadline, both of which you set, and spending it reduces the budget. See Destination override approval for the full lifecycle and how to read the record before you swap.
Requesting authorization
Send your Sales Contact:
- The network you will operate on
- The token pair you want to trade
- Your calling contract address. If it is upgradeable, this is the proxy address, not the implementation — deploying produces both, and authorizing the implementation by mistake refuses every call as an unauthorized trader while the authorization still looks correct on our side. The caller contract template has a single call that tells the two apart. This applies to any contract address you send us, including any destination address below
- Any destination addresses that differ from the calling contract — these apply to stablecoin → iBENJI only, since the other direction delivers to your contract. Each is authorized on the pair exactly as your calling contract is; your contract still grants its own per-destination approval, as above
In return you will receive the swap contract address and the token addresses for that network.
Verify before you spend gas
Once your authorization is in place, you can confirm it by reading contract state — see Check eligibility. It is readable before you spend anything, so a failed transaction is never the only way to find out.