Blog

Polaris Chain team

Deterministic finality vs. card settlement


When someone says a payment "went through," they usually mean the card reader beeped, not that the money actually moved. On card and bank rails, those are two different moments, sometimes days apart. On Polaris, they are close to the same moment. This post explains the difference and why it exists.

How a card payment actually settles

A card swipe triggers an authorization: the card network checks that the account can cover the charge and reserves the amount. That feels instant to the shopper. But authorization is not settlement. The merchant does not actually receive the funds that day. Card networks batch transactions and settle them between banks on a T+2 or T+3 basis, meaning two or three business days after the transaction date. Bank transfers over ACH rails follow a similar pattern, often described as T+1 or T+2.

During that gap, the transaction is not final. A cardholder can dispute the charge and trigger a chargeback, which can happen up to 180 days after the original transaction under common card network rules. The merchant can lose the funds, plus a chargeback fee, after they believed the sale was complete. This is a real cost of the deferred-settlement model: someone in the chain is always carrying the risk that a transaction reverses after the fact.

How Polaris settles instead

Polaris commits a transaction in seconds. Once it lands in the ledger, it does not get uncommitted. There is no batch window, no pending settlement period, and no post-hoc reversal built into the protocol. The transaction is either sequenced and final, or it never made it into the ledger at all.

This is a difference in kind, not just speed. A faster authorization still leaves a settlement gap behind it. Polaris removes the gap itself: the moment a payment is confirmed is the moment it is final.

No chargebacks, by design

Because there is no deferred settlement step, there is nothing equivalent to a chargeback at the protocol level. A transaction that lands in the ledger either succeeds and updates balances, or gets rejected with a written reason, such as insufficient balance or a compliance rule (see our post on real-world asset compliance for how that rejection works). Either way, the outcome is recorded once, and it does not flip afterward.

This does not mean fraud or disputes disappear as a general problem; it means the settlement layer itself carries no reversal window. Any dispute resolution has to happen off-chain, through whatever agreement the parties made, rather than by a card network unwinding a transaction weeks or months afterward.

Flat fees instead of a percentage cut

Card networks typically charge merchants a percentage of each transaction, often in the low single digits, plus a fixed per-transaction fee. That model scales the cost with the value of the purchase, not with the actual cost of processing it. Polaris is built around a flat, deterministic transaction cost structure instead, which does not scale with the dollar value being settled. The principle holds regardless of the exact fee schedule: cost ties to processing, not to a cut of the value moved.

What this means in practice

What Polaris has on the public testnet is the settlement characteristic that legacy rails cannot offer at any throughput: deterministic finality in seconds, with no multi-day settlement window and no chargeback risk built into the base protocol. See the milestones page for how Polaris scales this to card-network throughput.