Skip to content
Jorvi
Blog

Supported tokens

There is no hardcoded list of supported tokens, and that is deliberate. A mint becomes usable by passing two checks, in order.

Two tiers

Section titled “Two tiers”

1. The platform registry. Every mint has to be present and enabled platform-wide. If it is not, the request fails:

{ "error": { "type": "invalid_request_error", "code": "mint_not_allowed",
             "message": "This token is not supported by the platform.", "param": "mint" } }

2. Your account. A mint that the platform allows still has to be accepted by your merchant account. Some are on by default; others you enable yourself. If it is allowed but not enabled for you:

{ "error": { "type": "invalid_request_error", "code": "mint_not_enabled",
             "message": "Enable this token for your account first.", "param": "mint" } }

The distinction matters when you are debugging. mint_not_allowed is not something you can fix from your side. mint_not_enabled is.

Mints, not currency codes

Section titled “Mints, not currency codes”

Tokens are identified by SPL mint address, never by a symbol:

await jorvi.mandates.create({
  payer,
  payee,
  mint: usdcMintAddress,   // an address, not "USDC"
  amountPerPeriod: '2000000',
  periodSeconds: 2592000,
});

Symbols are not unique on-chain. Anyone can mint a token called USDC, so an address is the only unambiguous identifier, and resolving a symbol on the payer’s behalf would be a way to route money to the wrong asset.

Amounts are atomic strings

Section titled “Amounts are atomic strings”

amountPerPeriod is a string in the token’s smallest unit. USDC has six decimals, so:

Amount Value to send
2.00 USDC '2000000'
0.50 USDC '500000'
1234.56 USDC '1234560000'

Strings, not numbers. A JavaScript number cannot hold large token amounts exactly, and a rounding error in a payments system is a lost or duplicated payment.

Section titled “Related”