Skip to main content

​
The problem

When teams build stablecoin payment or token transfer features on Solana, the wallet problem and the gas problem usually land at the same time. The wallet problem is familiar: how do users create and manage a Solana wallet without it feeling like a blockchain tutorial? Teams typically reach for an embedded wallet provider — Turnkey, Privy, Crossmint, Dynamic, or a similar service. These providers handle authentication, key custody, and signing UX, so users never see a seed phrase or a browser extension. The gas problem is harder to see at first. Solana transaction fees are small, but they still require the user’s wallet to hold a SOL balance. A user with a freshly provisioned embedded wallet can authenticate and sign — but the moment they try to submit a transaction, the network rejects it because the fee payer account has no SOL. The experience breaks before it starts. Altude Gas Station solves the gas problem without touching the wallet problem. Your wallet provider stays exactly where it is. Gas Station adds relay and fee sponsorship: your application builds a transaction, the user signs it locally, and Gas Station validates it, attaches the sponsored fee payer, and relays it to the network.

​
Where Gas Station fits

Gas Station is not a wallet provider. It does not hold user keys, it does not decide who can transact, and it does not authenticate users. Those responsibilities stay with your chosen wallet infrastructure. The wallet provider — Turnkey, Privy, Crossmint, Dynamic — loads as an iframe inside your app and handles authentication and signing in that context. From the relay perspective, your app is the origin: it holds the signed transaction and sends it to Gas Station. The boundary is clean:

​
How the flow works

1

Your app builds a transaction

Construct the Solana transaction in your application. Include Altude’s fee payer address as the fee payer — this is returned by GET /api/transaction/config using your API key.
2

The user signs locally

Your wallet provider prompts the user to sign the transaction. The user’s private key never leaves the wallet provider’s secure environment.
3

Gas Station validates and sponsors

Your app sends the signed transaction to the Gas Station API. Altude validates it, attaches the sponsored fee payer signature, and prepares it for relay.
4

Gas Station relays to Solana

The fully signed transaction is submitted to the Solana network. Your app receives the transaction signature for confirmation tracking.

​
When to use this pattern

You should pair Gas Station with a wallet provider when:
  • You want users to transact with stablecoins or SPL tokens without holding SOL for gas
  • You already have a wallet provider chosen and do not want to replace it
  • You are building an embedded wallet experience and want mainstream UX (no gas dialogs, no SOL top-up flows)
  • Your users may be new to Solana or may not know what a transaction fee is
Gas Station is not the right fit if your application needs users to pay their own transaction fees, or if you are building infrastructure that explicitly manages its own fee payer accounts.

​
Security and custody considerations

  • Altude does not access user keys or key shards. The wallet provider holds custody. Gas Station only ever receives a signed transaction — the same payload that would be submitted to any Solana RPC node.
  • Altude does not control who can transact. Access control is your application’s responsibility. Gas Station validates that a transaction is well-formed and relays it; it does not authenticate users or enforce application-level permissions.
  • Users sign locally before relay. The transaction is valid only if the user’s wallet signature is present. Gas Station adds the fee payer signature; it cannot alter the transaction instructions.
  • Do not expose API keys client-side. Your Altude API key should live in a server-side environment or a secure secrets manager. Treat it like any other backend credential.

​
Integration patterns

All four provider demos follow the same adapter pattern. The wallet integration is isolated in a single module (src/wallet/). Swapping wallet providers requires changing one import line — the rest of the application, including the Gas Station relay logic, is unchanged.
This separation is intentional: Gas Station does not depend on the wallet provider, and the wallet provider does not depend on Gas Station. They are composed at the application layer.

​
Choose your provider

Turnkey

Passkeys, email OTP, SMS, and social login. Hardware-backed key custody.

Privy

Embedded wallets with email, SMS, and social auth. Minimal onboarding friction.

Crossmint

Wallets provisioned from email or OAuth. API-first embedded wallet platform.

Dynamic

Multi-chain embedded wallets with a rich auth kit and developer dashboard.
Not using one of these providers? The demos are built on a provider-agnostic adapter pattern — any wallet that can sign a Solana transaction can be wired into Gas Station using the same approach.