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

# Stellar

> Network-specific features, signature kinds, supported assets, and integration requirements for Stellar wallets on the DFNS platform.

Stellar is a decentralized payment network designed for fast, low-cost cross-border transactions. This guide covers Stellar-specific features when using DFNS wallets.

## Account activation

On Stellar, a wallet address must be **activated** before it can receive assets or participate in the network. Activation requires funding the account with native XLM.

When sending to a new Stellar address, use the [Transfer Asset](/api-reference/wallets/transfer-asset) endpoint with `createDestinationAccount: true` to create the account if it doesn't exist.

<Note>
  If you send to an unactivated account without `createDestinationAccount: true`, the transaction will fail.
</Note>

## Receiving non-native assets (Creating trustlines)

Before a Stellar wallet can receive a non-native asset (like USDC), it must establish a **trustline** to that asset. This is a Stellar network requirement - without a trustline, the wallet cannot hold or receive the asset.

<Note>
  Learn more about trustlines in the [Stellar documentation](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/accounts#trustlines).
</Note>

Use the Broadcast API with a `changeTrust` operation. To remove a trustline and reclaim the reserve, set the limit to 0 (the asset balance must be 0 first).

```mermaid theme={null}
flowchart LR
    A[No trustline] -->|changeTrust| B[Trustline active]
    B -->|Receive assets| B
    B -->|Balance = 0| C[Can remove]
    C -->|limit = 0| A
```

See the [Stellar broadcast examples](/api-reference/broadcast/stellar) for complete implementation details.

## Reserve requirements

Stellar accounts must maintain a **minimum balance** to stay active. The formula is `2 base reserves + (subentries + ledger entries) × 1 base reserve`, where 1 base reserve = 0.5 XLM. See the [Stellar minimum balance documentation](https://developers.stellar.org/docs/learn/fundamentals/lumens#minimum-balance) for the full definition.

| Requirement                                                        | Amount  |
| ------------------------------------------------------------------ | ------- |
| Base account (2 base reserves)                                     | 1 XLM   |
| Per subentry — trustline, offer, extra signer, data entry          | 0.5 XLM |
| Per ledger entry — claimable balance, liquidity pool participation | 0.5 XLM |

For example, an account with 3 trustlines must maintain at least **2.5 XLM** ((2 + 3) × 0.5).

<Tip>
  You can reclaim trustline reserves by removing trustlines for assets you no longer hold.
</Tip>

## Transfers

Use the [Transfer Asset](/api-reference/wallets/transfer-asset) endpoint for all Stellar transfers:

* **Native XLM**: Use `kind: Native` with amount in stroops (1 XLM = 10,000,000 stroops)
* **Stellar assets**: Use `kind: Sep41` with the `assetCode` iand `issuer`
* **Memo**: Stellar supports an optional `memo` field, commonly used by exchanges for deposit identification

## Fee sponsorship

Stellar supports fee payers, allowing a separate account to pay transaction fees. This is useful for onboarding users who don't yet have XLM.

A fee-sponsored transaction is wrapped in an **envelope** that includes:

1. The inner transaction (signed by the source account)
2. The fee payer's signature

The fee payer receives the transaction, adds their signature and fee, then submits it to the network.

```mermaid theme={null}
sequenceDiagram
    participant S as Source Account
    participant F as Fee Payer
    participant N as Stellar Network

    S->>F: 1. Inner transaction (signed)
    F->>F: 2. Add fee + signature
    F->>N: 3. Submit wrapped tx
    N-->>S: 4. Transaction confirmed
```

<Note>
  Fee sponsorship on Stellar requires building custom transaction envelopes using the Stellar SDK and the Broadcast API.
</Note>

## Transaction expiration

DFNS builds Stellar transactions with a **24-hour** expiration: the transaction must be broadcast within 24 hours of being built, otherwise it expires and must be rebuilt and re-signed. This applies to all transactions, including transfers, and gives this much time to sign and broadcast even if the signing infrastructure is temporarily unavailable (for example an unreachable on-prem signer).

## SDK integration

For full transaction control, use the DFNS SDK with [stellar-sdk](https://stellar.github.io/js-stellar-sdk/). See the [Stellar integration example](https://github.com/dfns/dfns-sdk-ts/blob/m/examples/libs/stellar/basic-tx/main.ts).

## Related resources

* [Stellar broadcast examples](/api-reference/broadcast/stellar)
* [Stellar signing examples](/api-reference/sign/stellar)
* [Supported networks](/networks)
* [Stellar documentation](https://developers.stellar.org/)