cAppDeveloper docsStart with one responsibility
Build a product around the capability it needs, not around a copy of the Lab. Conduit reads configured RPC data; Compass shapes intents and requests; Circuit retains operation identity; Sentinel checks policy and exact transaction bytes; Latch owns wallet authority; Dispatch retains and submits an authorised attempt; Witness observes and verifies evidence.
Solana Edge composes a reviewed payment lifecycle. It is an application-side coordinator, not a hosted RPC gateway. Accord, Switchyard and Arena provide separate collective-review, allocation and deterministic-simulation capabilities. You do not need all eleven components for a balance view or a payment request.
| Product goal | Start with | First observable result |
|---|---|---|
| Show a wallet's balance | Conduit | An observed balance, network, genesis and slot; a failed read is not zero. |
| Present exact payment terms | Compass or portable payment helpers | A saved request with an atomic amount, reference and expiry; no signing or sending. |
| Make one reviewed devnet payment | Edge and its six peers | One saved operation, explicit approval, one retained submission attempt and matching evidence. |
| Verify a customer's payment | Witness and a trusted merchant boundary | Actual recipient credit matches the saved invoice; delivery remains a separate decision. |
| Rehearse uncertain outcomes | Arena, Circuit, Dispatch and Witness in simulation modes | The same retained attempt is observed after a lost reply, with simulated: true. |
| Explore group review or resource reuse | Accord / Switchyard | A message-bound simulated quorum or local allocation record, not custody or settlement. |
Choose the execution mode deliberately
Local simulation uses repeatable local outcomes without chain execution. Devnet uses actual test-network transactions and needs a working provider, a suitable wallet, funds and explicit approval. A devnet failure must not silently turn into a simulated success. A simulation's word “confirmed” is not an on-chain confirmation.
The supplied Edge signing flow supports native SOL and original SPL Token Program transfers on devnet. Mainnet signing, Token-2022, wrapped SOL, arbitrary swaps and general trading execution are not supplied by this recipe. Some read-only helpers and payment verification support mainnet observations when explicitly configured; that does not enable Edge mainnet signing.
Public documentation and the hosted Lab preview have no wallet/runtime authority. In an installed app, the selected package supplies the runtime. A standalone application can deliberately bundle a compatible runtime, but the thin portable client does not install providers and must not replace a selected-but-failed installed provider.
First integration checklist
- Choose a concrete result and the smallest composition. Start with read-only inspection or a labelled simulation before introducing signing.
- Check selected package versions, target support and provider modes. Read component status; method discovery alone is not readiness or an RPC connection test.
- Verify the configured network and choose a devnet payer and recipient deliberately. Preserve the payer's backup independently of operation receipts.
- Save your business request and stable operation ID before effects. Bind sender, recipient, exact amount, asset and network; do not regenerate them on every retry.
- Exercise success, declined approval, missing provider, a lost reply and a reload. Observe the same operation after an uncertain send rather than preparing another payment.
- Decide which evidence the product needs. A sender-side bound receipt, independently verified recipient credit and a durable order fulfilment record are different results.
Follow a path
Start with composition, then the reviewed payment recipe. Keep recovery beside the implementation, not as an afterthought. Recipient-side products should use independent payment verification with their own trusted request storage and durable delivery claim.
The provider guide covers connection setup, client-token exposure, rate limits and external adapters. Explore the Lab for concrete scenarios, then use the portable client and component references in your own application. Your application owns orders, entitlements and product outcomes; reusable Sidecars supply bounded capabilities rather than a complete business backend.