USDC decimals, lamports and the other Solana units, converted in one place.

How many decimals does USDC have on Solana?

USDC on Solana has 6 decimals. The number is not a convention: it is a field on the USDC mint account, and on 15 October 2026 a public mainnet RPC returned "decimals": 6 for the mint EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v. A mint is the account that defines a token; how to tell the real USDC mint from a lookalike is covered in checking real USDC on Solana.

A base unit is the smallest amount of a token that can exist, here 0.000001 USDC. Solana's token documentation describes the mint field as the "Number of base 10 digits to the right of the decimal place." It also shows that a token account stores its balance as amount: u64, a whole number. The chain never sees 25.5 USDC. It sees 25500000, and a wallet divides by a million to show you the dollars.

That one rule explains most unit bugs: the number on chain is always an integer, and the decimal point is something your code adds back for people to read.

What is a lamport, and how many are in one SOL?

A lamport is the smallest unit of SOL, and one SOL is 1,000,000,000 lamports. The Solana terminology page defines it as "A fractional native token with the value of 0.000000001 sol." So SOL works like a token with 9 decimals, and USDC like one with 6. Mixing the two scales is the classic mistake: treat a lamport figure as base units of USDC and you are off by a factor of a thousand.

Solana's fees are written in lamports. As of 15 October 2026, the Solana fees documentation lists a base fee of 5,000 lamports per signature, which is 0.000005 SOL. The optional priority fee is priced in micro-lamports, millionths of a lamport, per compute unit, and the same page gives the formula: ceil(compute_unit_price * compute_unit_limit / 1,000,000) lamports. A compute unit is the measure of work a transaction asks validators to do. Fianto's renewal bids in micro-lamports are worked through in payments during Solana congestion.

How do you convert USDC and SOL amounts to base units?

To convert, multiply the human amount by 10 to the power of the decimals; to read a base-unit figure, divide by the same. The rows below are real values you meet when you take USDC through Fianto, checked on 15 October 2026.

Do the conversion with integers or decimal strings, never with floating-point numbers. In JavaScript, 0.1 + 0.2 evaluates to 0.30000000000000004, and an integer above 9,007,199,254,740,991 (Number.MAX_SAFE_INTEGER) can no longer be stored exactly. Fianto's backend parses a price "by string arithmetic: a float never touches money", as the comment in its money module says, and stores the result as a BigInt.

Rent is the one row that moves. Solana's reduced-rent page gives the formula (128 + data_size) * lamports_per_byte and lists five steps that cut lamports_per_byte from 6,960 to 696, with the last three expected in November 2026. The 1,488,440 lamports we measured is (128 + 165) * 5,080. Read the live figure with getMinimumBalanceForRentExemption instead of copying it.

How does Fianto's API represent USDC amounts?

Fianto takes amounts in as decimal strings and sends them out as strings of USDC base units. When your server creates a checkout session with an amount, you send "12.50". Every amount Fianto returns in v1 responses and webhooks, including amount, fee_amount, network_fee_amount and total_amount, is a base-unit string. The webhook event reference states it plainly: "25000000" is 25 USDC.

Strings, not JSON numbers, so no parser on your side can round them. The Fianto SDK converts between the two forms without floating point; this is the example from its docs:

import { usdc } from '@fianto/sdk';

usdc.toBaseUnits('12.5'); // '12500000'
usdc.fromBaseUnits('12500000'); // '12.5'
usdc.format('12500000'); // '12.50 USDC'
usdc.format('12500000', { symbol: false }); // '12.50'

toBaseUnits throws for more than 6 decimals, a sign, or anything that is not a number. Store the base-unit string as it arrives, or as a big integer column, and convert only when you display it. The rest of the SDK and the API live on the developers page.

What price precision does Fianto accept?

A Fianto price must be between 0.01 and 1,000,000 USDC, with at most 6 decimal places. Those limits are the constants MIN_AMOUNT = 10_000n and MAX_AMOUNT = 1_000_000_000_000n in base units, and an amount must match up to 7 digits before the point and 6 after it. An API amount with a seventh decimal fails validation with 400 validation_failed; one outside the range gets 400 amount_out_of_range.

The six-decimal ceiling is USDC's own: 12.3456789 USDC cannot exist on chain. In practice you will price in cents, and pricing in USDC covers which price points make sense. Two other rules follow from base units:

• A discount cannot push a price under 10,000 base units. The discounted price must stay at 0.01 USDC or more, or the code is refused with coupon_not_applicable. More in discount codes for USDC payments.
• A percentage fee is rounded down to whole base units. Fianto's fee is amount times basis points divided by 10,000, in BigInt, which truncates, so any rounding favours the customer.

A worked example. There is no Fianto fee during the beta; after it, the customer pays about 0.1 to 0.5% on top, and the merchant pays nothing. At an illustrative 0.3% (30 basis points), a price of 12,345,677 base units gives 12,345,677 * 30 / 10,000 = 37,037.031, truncated to a fee of 37,037 base units, so the customer signs for 12,382,714 and the merchant receives exactly 12,345,677. Subscription charges also carry a flat network fee, today 10,000 base units (0.01 USDC) per charge on plans created since 6 October 2026; one-off payments carry none.

Where do lamports appear in a Fianto payment?

Lamports appear wherever SOL is spent: the customer's transaction fee and, for a subscription, account rent. The merchant pays neither. The customer pays the fee of the transaction they sign, which the checkout shows as under $0.01, and Fianto's own key pays the SOL for each renewal transaction.

A subscription's rent is read from the cluster in lamports when the customer subscribes, and the checkout shows it in SOL. As of 15 October 2026 the subscription account's rent was 1,437,640 lamports, about 0.00144 SOL, returned when the customer reclaims it after the subscription ends; the one-time wallet setup account was 1,188,720 lamports, about 0.00119 SOL, on a wallet's first subscription and not returned. The checkout shows the exact live amount before anyone signs.

When a wallet is short of SOL, Fianto reports what the transaction needs and what the wallet holds, both in lamports, and the page rounds the gap up to four decimals of SOL, in steps of 100,000 lamports. The payer reads a line such as "Not enough SOL for the Solana network fee and this wallet's minimum balance. Nothing has been charged. If you add about 0.0003 SOL to this wallet, try again." Why that minimum balance exists is in why you need SOL to send USDC, and what each transaction costs in how much a Solana transaction costs.

Which unit mistakes break a USDC integration?

1. Showing base units as dollars. A customer who sees "25000000 USDC" in an email has been sent a webhook value unconverted. Format it first.
2. Assuming every token has 9 decimals. SOL does; USDC does not. Read the decimals from the mint, or use a helper that knows USDC is 6.
3. Comparing amounts as floats. Check that a payment equals the price by comparing base-unit strings or big integers, never 25.0 against 24.999999999.
4. Hard-coding rent. The lamports per byte have changed twice in 2026 and more steps are planned, so a rent constant in your code goes stale.