npm package: @openzeppelin/adapter-stellar
Description: Stellar Adapter for UI Builder
Author: Aleksandr Pasevin
Latest version: 2.0.0

# Stellar Adapter (`@openzeppelin/adapter-stellar`)

This package provides the **Stellar ecosystem definition** for OpenZeppelin UI: Soroban-focused capability factories, network metadata, and **`createRuntime`** to obtain an `EcosystemRuntime` for Stellar networks.

It is responsible for:

- Exposing **`ecosystemDefinition`** (`EcosystemExport`) with `networks`, `capabilities`, and `createRuntime(profile, networkConfig, options)` aligned with `@openzeppelin/ui-types`.
- Defining and exporting Stellar network configurations (Public Network and Testnet) as `StellarNetworkConfig` objects in `src/networks/` (Horizon URL, Soroban RPC URL, network passphrase, explorer URL, icon, etc.).
- Loading Stellar contract definitions and metadata and transforming them into the builder’s chain‑agnostic `ContractSchema`.
- Mapping Soroban value types to builder form fields and validating user input.
- Parsing user inputs into Soroban `ScVal` types for transaction execution and formatting view results.
- Transaction execution using an execution strategy pattern (EOA and Relayer strategies).
- Wallet integration and UI via the `src/wallet/` module.
- Adapter‑specific configuration and validation helpers (RPC resolution, explorer URLs, execution configuration validation).

---

## Transaction Execution

The Stellar adapter uses an execution strategy pattern similar to the EVM adapter to handle transaction submissions.

### Supported Strategies

1. EOA (Externally Owned Account): Uses the connected Stellar wallet (via Stellar Wallets Kit) to sign and submit Soroban transactions directly.
2. Relayer: Uses the OpenZeppelin Relayer service to submit transactions. The adapter exposes a `StellarRelayerOptions` React component to configure strategy‑specific options in the Builder UI.

The adapter selects the strategy at runtime based on the `ExecutionConfig` provided by the application.

### Configuration in the Builder

The Builder application’s “Customize” step passes an `ExecutionConfig` into the execution capability’s transaction flow (`signAndBroadcast` on the runtime’s **`execution`** capability for transactor-style profiles). The implementation uses a factory to instantiate the appropriate strategy and reports live status updates via the provided `onStatusChange` callback.

---

## Access Control Support

The Stellar adapter includes first-class support for OpenZeppelin Access Control and Ownable contracts through a dedicated service module.

### Features

- **Feature Detection**: Automatically detects contracts implementing AccessControl, Ownable, or both
- **Role Management**: Query current roles, grant/revoke roles, check permissions
- **Ownership Management**: Transfer ownership, query current owner
- **Dynamic Role Discovery**: Automatically discover role IDs via indexer when not explicitly provided
- **Historical Queries**: View complete history of role changes and ownership transfers via SubQuery indexer
- **Server-Side Filtering**: Filter events by contract, role, account, and limit (when indexer is available)

### Role Discovery

Since OpenZeppelin's Stellar contracts don't expose a `get_all_roles()` method, the adapter supports multiple ways to obtain role identifiers:

#### 1. Explicit Role IDs (Recommended for known contracts)

```typescript
const accessControl = runtime.accessControl;
if (!accessControl) {
  throw new Error('Access control capability not available for this profile');
}
accessControl.registerContract(contractAddress, schema, ['admin', 'minter', 'burner']);
```

#### 2. Dynamic Discovery via Indexer

If no role IDs are provided, the access control capability automatically queries the indexer for historical `ROLE_GRANTED` and `ROLE_REVOKED` events:

```typescript
// Register without role IDs - discovery happens automatically
accessControl.registerContract(contractAddress, schema);

// Or explicitly discover roles
const roles = await accessControl.discoverKnownRoleIds(contractAddress);
// => ['admin', 'minter', 'burner']
```

#### 3. Adding Roles Manually

For newly created roles that haven't been granted yet (no historical events), you can add them manually:

```typescript
// Add roles that may not exist in historical events
accessControl.addKnownRoleIds(contractAddress, ['new_role', 'another_role']);
```

Role IDs are validated against Soroban Symbol constraints:

- Must start with a letter or underscore
- Can contain only alphanumeric characters and underscores
- Maximum 32 characters

### Indexer Integration

For historical queries (e.g., `getHistory()`), the adapter integrates with the [Stellar Access Control Indexer](https://github.com/OpenZeppelin/stellar-access-control-indexer), a SubQuery project that indexes Access Control and Ownable events.

#### Configuring the Indexer

Add `indexerUri` to your `StellarNetworkConfig`:

```typescript
const stellarTestnet: StellarNetworkConfig = {
  // ... other config
  indexerUri: 'https://api.subquery.network/sq/openzeppelin/stellar-access-control-indexer',
};
```

#### Deployment

The indexer is production-ready and compatible with:

- **SubQuery Network** (decentralized, recommended for production)
- Self-hosted infrastructure (Docker)

For deployment instructions, see the [Indexer Deployment Guide](https://github.com/OpenZeppelin/stellar-access-control-indexer/blob/main/DEPLOYMENT.md).

#### Graceful Degradation

If no indexer is configured or the indexer is unavailable:

- On-chain queries (roles, ownership) work normally
- Historical queries return an empty array with a warning
- UI remains functional for all current-state operations

---

## Wallet Integration & UI

All wallet integration logic, UI components, facade hooks, and the UI context provider for Stellar are located in `src/wallet/`.

Stellar wallet and UI kit behavior is exposed through the **`wallet`** and **`uiKit`** entries on the `EcosystemRuntime` from `createRuntime` (for example `StellarWalletUiRoot`, facade hooks, and wallet components resolved via the UI kit capability).

For full documentation on the wallet module, see `src/wallet/README.md`.

---

This adapter follows the standard module structure outlined in the main project Adapter Architecture Guide.

## Package Structure

```text
adapter-stellar/
├── src/
│   ├── access-control/          # Access Control & Ownable support (service, indexer)
│   ├── configuration/           # Adapter-specific configuration (RPC, explorer, execution)
│   ├── contract/                # Contract loading & metadata
│   ├── mapping/                 # Soroban ↔ form field mapping & generators
│   ├── networks/                # Stellar network configurations
│   ├── query/                   # View function execution
│   ├── transaction/             # Transaction execution system (EOA, Relayer)
│   │   ├── components/                # React components for configuration
│   │   ├── formatter.ts               # Build Soroban tx data from form inputs
│   │   ├── execution-strategy.ts      # Strategy interface
│   │   ├── eoa.ts / relayer.ts        # Strategy implementations
│   ├── transform/               # Input parsing and output formatting
│   ├── types/                   # Adapter-specific types
│   ├── utils/                   # Utilities (artifact handling, formatting, etc.)
│   ├── validation/              # Validation utilities (addresses, configs)
│   ├── wallet/                  # Wallet integration (see wallet/README.md)
│   │   ├── components/                # Wallet UI components
│   │   ├── context/                   # Wallet context
│   │   ├── hooks/                     # Facade & low-level hooks
│   │   ├── implementation/            # Stellar Wallets Kit implementation
│   │   ├── services/                  # Config resolution for wallet UI
│   │   ├── stellar-wallets-kit/       # Kit-specific helpers
│   │   ├── README.md                  # Detailed wallet documentation
│   ├── adapter.ts               # Internal composition helpers (not the primary public API)
│   └── index.ts                 # ecosystemDefinition, createRuntime, networks, capabilities
├── package.json
├── tsconfig.json
├── tsup.config.ts
├── vitest.config.ts
└── README.md
```

---

## Usage (runtime creation)

**Consumers should use `ecosystemDefinition.createRuntime`** with a `ProfileName` and a `StellarNetworkConfig`. That returns an `EcosystemRuntime` whose optional fields (`wallet`, `query`, `accessControl`, …) depend on the profile.

```typescript
import type { ProfileName } from '@openzeppelin/ui-types';
import { ecosystemDefinition, stellarTestnet } from '@openzeppelin/adapter-stellar';

const profile: ProfileName = 'composer';
const networkConfig = stellarTestnet; // or stellarPublic

const runtime = await ecosystemDefinition.createRuntime(profile, networkConfig, {
  /* optional: UI kit overrides, indexer options, etc. */
});

// Example capabilities
const { wallet, networkCatalog, accessControl } = runtime;
```

Network configurations for Stellar networks are exported from `src/networks/index.ts` (`stellarPublic`, `stellarTestnet`, arrays `stellarMainnetNetworks`, `stellarTestnetNetworks`, and `stellarNetworks`).

> **Note:** Legacy docs or examples may still reference the old monolithic adapter class, but **npm documentation and app code should treat `ecosystemDefinition` + `createRuntime` as the stable integration surface**.

## Soroban RPC URL Configuration

Each `StellarNetworkConfig` specifies a default `sorobanRpcUrl`.

This URL can be overridden at runtime by the consuming application through the central `AppConfigService`. Configuration is loaded from environment variables (for the Builder app) or a `public/app.config.json` file (for exported apps).

To override a RPC URL, define an entry in `rpcEndpoints` keyed by the network’s string ID (e.g., `"stellar-testnet"`).

In `.env` for the Builder app:
`VITE_APP_CFG_RPC_ENDPOINT_STELLAR_TESTNET="https://your-custom-soroban-rpc.testnet.example"`

In `public/app.config.json` for an exported app:

```json
{
  "rpcEndpoints": {
    "stellar-testnet": "https://your-custom-soroban-rpc.testnet.example",
    "stellar-public": "https://your-custom-soroban-rpc.public.example"
  }
}
```

The Stellar runtime resolves Soroban RPC in this order:

1. User-provided RPC config from `UserRpcConfigService` (advanced user input)
2. RPC override via `AppConfigService.getRpcEndpointOverride(networkId)`
3. Default `sorobanRpcUrl` from the active `StellarNetworkConfig`

## Explorer URLs

Stellar explorers are used for display only. The runtime constructs URLs using `explorerUrl` from the network config:

- `getExplorerUrl(address)` → `.../account/{address}` or `.../contract/{id}` (Soroban contracts)
- `getExplorerTxUrl(txHash)` → `.../tx/{hash}`

No explorer API keys are required for adapter functionality.

## Network Configurations

Stellar networks are exported from `src/networks/`. Each `StellarNetworkConfig` includes:

- `id`: Unique network identifier (e.g., `"stellar-public"`, `"stellar-testnet"`)
- `name`: Display name
- `ecosystem`: Always `"stellar"`
- `network`: Always `"stellar"`
- `type`: `"mainnet"` or `"testnet"`
- `isTestnet`: boolean
- `horizonUrl`: Horizon endpoint for the network
- `sorobanRpcUrl`: Soroban JSON-RPC endpoint
- `networkPassphrase`: The network passphrase used by Wallets Kit / SDK
- `explorerUrl`: Base URL for the explorer (display only)
- `icon`: Icon identifier

See `src/networks/README.md` for details on adding networks and overriding RPC.

## Stellar Asset Contract (SAC) Support

The adapter fully supports Stellar Asset Contracts (SACs), which are special contracts that wrap native Stellar assets. SACs are automatically detected via RPC ledger entries and their specifications are loaded dynamically.

### How SAC Support Works

1. **Detection**: When loading a contract, the adapter checks its executable type via RPC
2. **Specification Loading**: For SAC contracts, the adapter fetches the official SAC specification from GitHub
3. **XDR Encoding**: The JSON spec is converted to XDR format using `@stellar/stellar-xdr-json`
4. **UI Generation**: The contract-loading / schema pipeline generates the same UI fields as regular WASM contracts

### Technical Implementation Details

#### WASM Loading Strategy

The `@stellar/stellar-xdr-json` library requires a ~3MB WebAssembly module for XDR encoding. After extensive testing with various Vite bundling approaches (including `vite-plugin-wasm`, `vite-plugin-top-level-await`, and `?url` imports), we encountered persistent issues where Vite would serve HTML instead of the WASM binary, resulting in WebAssembly instantiation errors.

**Solution**: The WASM module is loaded from CDN (`unpkg.com`) rather than bundled. This approach:

- Avoids Vite bundling complexities and errors
- Reduces bundle size by 3MB for users who don't use SAC contracts
- Loads the WASM only when a SAC contract is actually detected (lazy loading)
- Simplifies the build configuration

---

This adapter generally follows the standard module structure and developer experience provided by the EVM adapter, while keeping the core app chain‑agnostic.