> ## Documentation Index
> Fetch the complete documentation index at: https://docs.altude.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Gas Station with your wallet stack

> How Altude Gas Station fits alongside wallet infrastructure providers like Turnkey, Privy, Crossmint, and Dynamic — without replacing them.

## 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.

```mermaid theme={null}
%%{init: {'theme': 'base', 'themeVariables': {'fontFamily': 'Inter, ui-sans-serif, sans-serif', 'fontSize': '13px', 'primaryColor': '#0d2233', 'primaryTextColor': '#e2e8f0', 'primaryBorderColor': '#3DBFF2', 'lineColor': '#3DBFF2', 'edgeLabelBackground': 'transparent', 'clusterBkg': 'transparent'}}}%%
flowchart LR
    A([Your App]) -->|sign| B([Gas Station API])
    B -->|relay + fee| C([Solana Network])

    style A fill:#0d2233,color:#e2e8f0,stroke:#3DBFF2,stroke-width:1.5px
    style B fill:#3DBFF2,color:#071922,stroke:#049DD9,stroke-width:1.5px
    style C fill:#049DD9,color:#ffffff,stroke:#037dac,stroke-width:1.5px
    linkStyle default stroke:#3DBFF2,stroke-width:1.5px,fill:none
```

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:

| Layer               | Responsibility                                   | Provider                               |
| ------------------- | ------------------------------------------------ | -------------------------------------- |
| Authentication      | Sign-in, session, user identity                  | Wallet provider (Turnkey, Privy, etc.) |
| Key custody         | Private key creation, storage, and access        | Wallet provider                        |
| Transaction signing | Producing a valid signature                      | Wallet provider                        |
| Fee sponsorship     | Paying the Solana transaction fee                | **Altude Gas Station**                 |
| Transaction relay   | Submitting the signed transaction to the network | **Altude Gas Station**                 |

***

## How the flow works

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Gas Station relays to Solana">
    The fully signed transaction is submitted to the Solana network. Your app receives the transaction signature for confirmation tracking.
  </Step>
</Steps>

***

## 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.

```ts theme={null}
// src/wallet/index.ts — change this one line to swap providers
export { WalletProvider, useWallet, WalletButton } from '@/wallet/dynamic'
//                                                              ^^^^^^^ swap to 'turnkey', 'privy', 'crossmint', etc.
```

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

<CardGroup cols={2}>
  <Card title="Turnkey" icon="key" href="/integrations/turnkey">
    Passkeys, email OTP, SMS, and social login. Hardware-backed key custody.
  </Card>

  <Card title="Privy" icon="shield" href="/integrations/privy">
    Embedded wallets with email, SMS, and social auth. Minimal onboarding friction.
  </Card>

  <Card title="Crossmint" icon="credit-card" href="/integrations/crossmint">
    Wallets provisioned from email or OAuth. API-first embedded wallet platform.
  </Card>

  <Card title="Dynamic" icon="bolt" href="/integrations/dynamic">
    Multi-chain embedded wallets with a rich auth kit and developer dashboard.
  </Card>
</CardGroup>

<Note>
  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.
</Note>
