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

# Wallets

Use organization wallets for EVM and Solana actions without exposing signing material.

B3OS wallets let workflows execute onchain actions from organization-controlled signing surfaces. Wallet-backed workflows should be explicit, testable, and protected by policy nodes.

**I Redeemed 27 Winning Polymarket Bets in One B3OS Workflow**

**Keep signing material out of workflows**

Wallet actions use organization wallet controls. Do not place wallet secrets, recovery phrases, or signing material in
  workflow props, connector data, or node payloads.

**Wallet-backed action guardrail**

**Read context**
  **Policy branch**
  **Simulate or test**
  **Wallet action**
  **Monitor outcome**
  **facts**
  **approved path**
  **validated payload**
  **result**

## Wallet Capabilities

| Capability | Notes |
| --- | --- |
| EVM execution | Contract calls, token transfers, approvals, swaps, and other EVM actions |
| Solana execution | Solana transaction and wallet actions supported by the action library |
| Wallet management | Organization wallet metadata and management surfaces |
| Nonce coordination | Runtime support for coordinating EVM transaction nonces |
| Gas and funding checks | Workflows can account for gas, balance, or auto-swap requirements where configured |
| Simulation support | Some transaction flows can be simulated before execution when provider support is configured |

## Workflow Design

**Read first**

Fetch price, balance, token, market, or policy context before building a transaction payload.
  **Add policy branches**

Check thresholds, allowlists, expected asset, destination, and amount before a wallet action.
  **Use explicit wallet selection**

Keep wallet IDs and chain choices visible in the workflow configuration or props.
  **Test with safe values**

Validate payload shape and branch logic before publishing.
  **Monitor results**

Track transaction hashes, sanitized errors, and run status after execution.

## Onchain Patterns

| Pattern | Recommendation |
| --- | --- |
| Token transfer | Validate token, recipient, amount, and chain before execution |
| Contract write | Fetch ABI or schema context, validate arguments, and simulate when possible |
| Swap | Validate slippage, route, balance, gas, and destination |
| Approval | Keep approval scope narrow and explicit |
| Rebalancing | Use read actions and policy branches before any write |

## Wallet Troubleshooting

| Symptom | Check |
| --- | --- |
| Transaction fails before submission | Missing fields, invalid address, wrong chain, insufficient balance, or policy branch |
| Transaction submitted but reverted | Contract condition, slippage, allowance, deadline, or chain state changed |
| Nonce error | Concurrent wallet activity or stale nonce coordination |
| Gas issue | Native token balance, gas limit, gas price, or funding route |
| Missing wallet option | Organization permission, wallet setup, or unsupported action chain |

**Treat public execution as high risk for wallet workflows**

Publicly executable workflows should not directly expose broad wallet operations. Use narrow input schemas, policy
  branches, limits, review steps, and explicit permissions.