Operations, quotes and fees

Every financial action is represented by an Operation, a durable resource with its own identifier.

The operation keeps:

• user and wallet;
• action type;
• accepted quote;
• amount and asset;
• network(s) involved;
• fees;
• authorization;
• executed steps;
• on-chain references;
• status;
• final result.

The API quickly returns an operation_id. The Partner later queries the status or receives events and webhooks.

When an operation needs several steps, it is split into OperationLegs or legs. Each leg represents an independent transaction or stage — for example, a token approval, a transaction on the source network, a bridge, a swap on the destination, or a final transfer — and keeps its own network, provider, amount, hash and status.

LI.FI is part of the initial scope, but ChatterPay keeps its own operation model. The identifier and states reported by LI.FI are stored as external references; the Operation and its legs keep ChatterPay's durable workflow and status.

The quote fixes the economic and technical terms the user is accepting:

• input amount;
• expected output amount;
• fees;
• slippage;
• network;
• asset;
• provider;
• execution mode;
• expiration.

The platform must not silently substitute a route or change the terms after confirmation. When the quote expires or a material condition changes, a new one is generated.

A direct transfer moves an asset within one network using that blockchain's native integration.

LI.FI is used when the operation requires:

• changing the asset;
• changing the network;
• executing a swap and a bridge;
• coordinating several on-chain steps.

The platform does not automatically sign any payload delivered by the provider.

It must check:

• source and destination networks;
• assets;
• amounts;
• recipient;
• contracts involved;
• spender and approvals;
• slippage;
• expiration;
• calldata;
• fees;
• relationship to the accepted quote.

The route must also be allowed by the Partner deployment's current configuration. If it cannot be verified sufficiently, it is not executed.

The platform separates:

• network_fee, the blockchain's cost;
• provider_fee, the cost of LI.FI or another provider;
• service_fee, the commercial fee;
• total_fee, the sum of charges;
• total_debit, the total amount debited.

Calculations are made in the asset's minimum units and round up when applicable. The quote keeps the breakdown, the applied policy version, and whether the recipient receives an exact amount or fees are deducted from the requested amount.

The reference policy establishes:

• direct transfers with 0 bps service_fee;
• swaps with 25 bps service_fee, plus provider fees;
• cross-chain transfers with 25 bps service_fee, plus provider fees;
• AAVE and NFT operations with no fee for the user under the published policy.

Each Partner can replace these values with its own versioned policy. The policy that prices an operation is resolved by (partner, chain, operationType), most specific first, and the lookup always terminates on the reference catalog above: a deployment that configures nothing prices exactly as that list describes.

A service fee is expressed either in basis points or as a fixed amount in USD, converted to the operation's asset when the quote is priced. A fixed_usd policy freezes the rate, its source and the instant it was read into the quote; a quote that cannot be priced within the freshness bound is refused by name rather than falling back to a stale rate, to zero, or to basis points.

The model declares three, and exactly one is selectable today:

• partner_sponsored, the Partner advances and absorbs or recovers the gas. The only one a policy can select, and the one every policy uses.
• user_paid, the user pays with the native asset. Declared by the type and selected by no policy.
• asset_fee, the Partner advances the gas and recovers its equivalent in another asset. Not a selectable mode: a derived reporting value that appears when the total fee is above zero.

The mode is fixed in the quote. It cannot be silently changed after acceptance.

Cardano is the exception. There the fee comes out of the transaction's own inputs and no third party can pay it without taking part in the transaction, so no sponsorship model applies until the platform subsidises it by adding an input of its own and co-signing.

Gas cost is presented as network_fee, regardless of who advances it. Infrastructure and third-party costs are accounted for separately, unless a contractual agreement folds them into the commercial policy.

The platform uses Partner-versioned fee policies. The initial proposal for Belo is a fixed fee of USD 0.08 per transaction originated by the integration, subject to validation and commercial close-out with Belo. Once agreed, it replaces the reference service_fee and is recorded as part of the quote and the operation.

Other Partners can use fixed amounts, basis points, subsidies, per-provider fees, or other combinations without modifying the public API.

The USD 0.08 is expressed as a fixed_usd policy of that Partner, and charging it or not charging it is the same configuration: a Partner with no policy of its own falls back to the reference catalog, which charges 0 bps on direct transfers.

Charging and collecting are two different things.

• Accrual. Every fee posting carries a counterpart credit to a collection account per (partner, asset). What the payer is debited, that account is credited, and the ledger's conservation invariant covers the fee the same way it covers the transfer.
• Collection. The accrued balance moves on chain by a sweep — scheduled or triggered by a per-asset threshold — into the Partner's ChatterPay collection wallet. A sweep is an operation like any other: durable, idempotent, reconciled against its own on-chain evidence.

Sweeping rather than charging on chain per operation is deliberate: moving the fee inside every operation would roughly double its gas for an amount usually smaller than that gas. Between accrual and sweep the fee sits at the payer's address, which is acceptable because the signing authority is the deployment's — those funds cannot leave except through the platform.

It is a ChatterPay wallet, configured per Partner rather than a constant of the deployment, and it is reported as a platform account of its own role alongside the relayer, the Paymaster and its EntryPoint deposit.

It is rotatable, and rotation is an administrative operation rather than a configuration edit. A collection address is a long-lived destination for revenue, so the case that matters is exactly that one: the key is exposed and it has to be replaced without a deployment, without downtime and without losing the audit trail. Rotation records the previous address, the new one, who ordered it and when. An accrual binds the address in force when it was booked, and an in-flight sweep to a rotated-out address is completed or explicitly failed — the destination a signature authorised is not retargeted afterwards.

Where the cost already is. The sandbox's cost panel, the SDK and the platform accounts report the collection wallet's balance per asset, what is accrued and not yet swept, and who bore each fee — whether it came out of the user's balance or the Partner absorbed it.