Skip to main content

Documentation Index

Fetch the complete documentation index at: https://grat.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Grat eliminates gas friction by acting as a trusted intermediary that pays network fees on behalf of your users. It uses a Stellar-native feature called Fee-Bump Transactions (CAP-0015) to achieve this without requiring access to user private keys or complicated smart contract wrappers.

​
The Problem: Fees and Sequences

In a standard Stellar transaction, the account that initiates the transaction must pay the fee in XLM. This account must also have the correct sequence number. This creates two hurdles: users need XLM, and your app must manage sequence numbers for every user in real-time.

​
The Solution: Fee-Bump Transactions

A fee-bump transaction allows a separate “sponsor” account to pay the fee for an “inner” transaction. Grat takes your user’s signed transaction, wraps it in a fee-bump envelope, and signs it with a relay-controlled account. The network deducts the XLM from Grat, while the inner transaction logic executes as if the user had paid for it.

​
The Transaction Flow

  1. User Signs: Your user signs a transaction that performs the desired action (e.g., sending USDC).
  2. App Sends to Grat: Your app sends the XDR to the Grat relay server.
  3. Grat Acquires Channel: Grat pulls an available “channel account” from its internal pool.
  4. Builds Fee-Bump: Grat builds the fee-bump envelope using the channel account as the fee-paying source.
  5. Signs and Submits: Grat signs the outer envelope and submits it to the Stellar RPC.
  6. Result Returned: The relay polls for confirmation and returns the transaction hash and final result back to your app.

​
Channel Accounts and Parallelism

To handle many transactions simultaneously, Grat maintains a pool of channel accounts. Stellar requires transactions from the same account to be submitted sequentially. By using multiple channels, Grat can submit transactions in parallel, significantly increasing throughput and preventing sequence number bottlenecks.

​
Classic vs Soroban

Grat provides unified support for both Stellar Classic and Soroban Smart Contracts.
  • Classic: Sponsoring simple payments, trustline creation, and account configuration.
  • Soroban: Sponsoring host function invocations, including the complex resource fees (CPU, Memory, and Storage) required by smart contracts.

​
Protocol 26 (Yardstick) Support

Stellar Protocol 26 introduces significant changes to how the network handles resource metering and fee structures, particularly for Soroban smart contracts. It refines the calculation of execution costs and updates the baseline for storage and compute pricing. Grat is designed to absorb these complexities automatically. The relay handles the updated resource fee estimation and ensures that fee-bump envelopes are built according to the latest protocol requirements. Developers using Grat do not need to manually adjust their transaction logic for protocol upgrades, as the relay and SDK adapt to network-level fee changes in real-time. View on GitHub