Can prepaid GalaChain credit lock the fee for later operations?

Prepaid credit funds a channel fee balance without fixing the fee schedule for later operations. The applicable charge follows the operation and its channel configuration. An authorization amount establishes funding; it does not establish a permanent price per transfer or guarantee a particular number of future operations.

Does a GalaChain fee exemption apply automatically to every account?

A fee exemption applies to an identity covered by the channel's exemption configuration. The SDK supports exemptions for cases such as application-service identities that follow another fee arrangement. The configured exemption determines eligibility and any limits on the fees that it covers.

Will reading a gSwap balance or obtaining a quote incur GalaChain gas?

Read-only gSwap operations, including balance queries and swap quotes, do not incur its GalaChain gas fee. Write operations that change blockchain state follow a different charging rule. A quote therefore establishes an available estimate without making the eventual swap gas-free.

What happens when concurrent GalaConnect writes affect the same wallet?

Concurrent write operations that affect the same wallet can produce serialization failures in GalaConnect. The API identifies this condition with a 409 Conflict response. Inspect the error before retrying and avoid overlapping writes to the same wallet.

How should a GalaConnect retry avoid paying for a duplicate operation?

Retaining the original operation's uniqueKey prevents two transactions with that key from committing. A duplicate submission can return a conflict instead of repeating the operation. An integration should reconcile the original transaction before issuing a replacement with a fresh key, because a fresh key identifies a new operation.

Galagames

Galagames GalaChain automatic fees and prepaid channel credits

Last updated · Sunday 11 October 2026

Galagames GalaChain supports automatic GALA fees and prepaid credits for certain operations outside the asset channel. An automatic fee comes from the wallet balance when its operation commits. Prepayment burns GALA on the asset channel and funds fee credit on the target channel. The operation and channel determine which mechanism applies. Ownership of the token that you want to transfer and funding for its transaction fee satisfy separate requirements.

Automatic deductions and prepaid credit serve different operations

Automatic charges

An operation with the fee type galachain_automatic deducts its GALA charge when it commits to GalaChain. The wallet needs the balance that pays that charge. This mechanism attaches payment to the operation itself, so the fee does not require a separate cross-channel authorization. Sending currency and transferring NFTs appear among the actions covered by the network's gas-fee system.

Prepaid channel credit

The type galachain_cross_channel_authorization identifies a payment that needs advance funding for certain operations outside the asset channel. Some NFT operations use this arrangement because their tokens reside on other channels. Prepayment can cover several subsequent fees, while each asset operation retains its own requirements. Because the fee response identifies the operation and its channel, an integration can determine the required payment method without assuming that every NFT transfer needs prepaid credit or that every token transfer uses an automatic fee.

The target channel determines the usable fee balance

GalaChain is a Layer 1 blockchain built on Hyperledger Fabric, with token contracts that support operations such as minting, transfers, allowances and swaps within individual channels. In the cross-channel fee design, GALA resides on the asset channel, while the secondary channel records fee credit derived from an authorization because this payment flow does not assume a local GALA balance there. Fund prepaid credit on the channel specified by the operation's fee response.

Credit belongs to the channel that records it. A wallet's asset-channel GALA balance and its secondary-channel fee balance therefore describe different accounting entries. An NFT balance identifies the assets available to an account, while the applicable fee balance covers charges for eligible operations.

Fee estimates reflect the intended operation

For a GalaConnect fee estimate, append /fee to the operation's endpoint and supply its request parameters, with signature and uniqueKey omitted. The returned feeInGala gives the charge in GALA. An operation can return several fee entries, so its total requires accounting for every applicable entry. The response also identifies the fee type and channel, which determine how the charge must be funded.

Channel configuration matters. The SDK's fee definition includes baseQuantity, usage thresholds, acceleration settings and maxQuantity. These fields describe configurable charging behavior rather than one permanent network-wide price. An estimate applies to the request that produced it. A different operation, altered parameters or a different applicable fee schedule can change the amount required.

Cross-channel authorization parameters bind the payment

A signed AuthorizeFee request includes the GALA amount and authorizing identity in its body. The endpoint path selects the target channel. The following parameters apply to the GalaConnect API Beta 1.0.0 interface.

Cross-channel authorization parameters bind the payment
Parameter	Accepted value	Purpose	Authorization constraint
`channel`	Target channel name	Selects the credit destination	Matches the fee response
`X-Wallet-Address`	Signer's GalaChain address	Identifies the signing wallet	Required request header
`authority`	Authorizing wallet address	Identifies the payer	Matches the signing key
`quantity`	Decimal string in GALA	Sets the amount to burn	No trailing fractional zeroes
`signerPublicKey`	Base64-encoded compressed secp256k1 public key	Identifies the verification key	Matches the request signature
`signature`	Base64-encoded DER signature of the request body	Authenticates the authorization	Valid for the signing wallet
`uniqueKey`	Globally unique string	Identifies the write operation	Prevents duplicate commitment
Payment scope	Selected channel	Prepaid operation fees	Asset operation remains separate

The GALA burn precedes the target-channel credit

Fee prepayment contains an asset-channel burn and a target-channel credit record. The commitment to spend GALA occurs before the later token operation.

Asset-channel authorization

GALA burn

AuthorizeFee burns the authorized GALA quantity on the asset channel. A committed burn changes the wallet's funds even when the later asset operation has not happened. Signing a draft expresses authorization; successful on-chain commitment establishes the burn. You can revise an unsubmitted request; any change to an already signed body requires a new signature.

View image file

Authorization record

The burn also writes a FeeAuthorization entry containing the authorizing identity, quantity and transaction identifier. This record supplies details for the next phase. Its identifier concerns the authorization transaction. It does not establish that a recipient has received the token associated with a later transfer.

Target-channel credit

An authorized channel identity validates the asset-channel authorization and executes CreditFeeBalance in the secondary channel. That call records a pending fee balance for the payer. These chain-level phases can share one GalaConnect API request.

Recorded credit and token balances answer separate accounting questions

FetchFeeBalances retrieves existing fee credit for a specified owner and channel. Before submitting an operation that requires prepaid fees, confirm that the returned balance covers its estimated charges. It does not establish ownership of a transferred NFT or the recipient's final token balance. Those belong to the asset operation, whose result must correspond to the intended token and recipient.

Prepaying several charges combines their funding without combining all subsequent asset operations into a single transfer. The authorized amount records the initial GALA commitment; the remaining fee balance reflects credit available for later charges. Reconciliation needs to distinguish that remainder from fees already consumed.

Unused credit follows a separate settlement process

The SDK includes a settlement mechanism for unused cross-channel credit. A secondary-channel operator uses settleFeeBalances to zero positive unspent balances and create FeeBalanceCreditReceipt records. Each receipt represents GALA due back on the asset channel. Creating that receipt establishes a refund obligation within this mechanism; it does not by itself show that the wallet has received the returned GALA.

After verification that the asset-channel credit has occurred, settleFeeCreditReceipts marks the secondary-channel receipt as settled. A receipt awaiting settlement and a settled receipt therefore describe different stages of the refund. Only the unused balance enters this process. Fees that an operation already consumed fall outside the unspent-credit refund mechanism.

Application charges and bridge costs extend the fee boundary

GalaChain gas pays for blockchain operations, while an application can attach a separate charge to its own service. The gSwap SDK includes input-based protocol fees in its quote calculations and accounts for GalaChain gas separately. The distinction matters when a quoted trading amount appears affordable but leaves insufficient GALA for the network charge.

Bridging from GalaChain to an external blockchain adds costs associated with the destination network and the asset that moves. A GalaChain fee estimate should not stand in for the complete external bridge cost. For an operation confined to its home channel, the next funding decision follows the returned fee type. For an external bridge or application purchase, account for any additional charges that apply before commitment.

Galagames GalaChain - your questions answered

Can prepaid GalaChain credit lock the fee for later operations?: Prepaid credit funds a channel fee balance without fixing the fee schedule for later operations. The applicable charge follows the operation and its channel configuration. An authorization amount establishes funding; it does not establish a permanent price per transfer or guarantee a particular number of future operations.
Does a GalaChain fee exemption apply automatically to every account?: A fee exemption applies to an identity covered by the channel's exemption configuration. The SDK supports exemptions for cases such as application-service identities that follow another fee arrangement. The configured exemption determines eligibility and any limits on the fees that it covers.
Will reading a gSwap balance or obtaining a quote incur GalaChain gas?: Read-only gSwap operations, including balance queries and swap quotes, do not incur its GalaChain gas fee. Write operations that change blockchain state follow a different charging rule. A quote therefore establishes an available estimate without making the eventual swap gas-free.
What happens when concurrent GalaConnect writes affect the same wallet?: Concurrent write operations that affect the same wallet can produce serialization failures in GalaConnect. The API identifies this condition with a 409 Conflict response. Inspect the error before retrying and avoid overlapping writes to the same wallet.
How should a GalaConnect retry avoid paying for a duplicate operation?: Retaining the original operation's uniqueKey prevents two transactions with that key from committing. A duplicate submission can return a conflict instead of repeating the operation. An integration should reconcile the original transaction before issuing a replacement with a fresh key, because a fresh key identifies a new operation.