Silvana exposes typed services for market access, transaction execution, settlement, pricing, and agent inputs. Use this page to understand how the pieces fit, then move into the full technical reference for exact methods and schemas.
Typed services. Explicit authorization. Structured results.
The public service map should match current proto definitions and documentation. Names, methods, and availability must be reviewed against the maintained schema before every release.
Submit and manage orders, read market data, initiate private RFQ workflows, and subscribe to order and execution events.
Agents and applications interacting with Silvana Book.
Coordinate settlement proposals, preconfirmations, allocation readiness, lifecycle events, and final outcomes for supported DvP workflows.
Applications that need to follow the trade beyond matching.
Read supported Canton state, onboard agents, prepare transactions, execute signed operations, and return structured results for reconciliation.
Agents and backend applications performing state changing Canton operations.
Receive supported price and quote data for strategy evaluation, RFQ logic, monitoring, and execution decisions.
Agents that require approved external price context.
Receive supported product, protocol, or event information through feed or streaming interfaces where available.
Workflows that use approved informational inputs as part of a wider decision model.
Send the typed operation and parameters. Silvana returns the prepared payload, hash, identifiers, and available estimates.
Confirm the operation, asset, amount, recipient, fees, permissions, and expected outcome inside the client environment.
Sign the prepared transaction hash inside the approved environment. Private key material remains there.
Submit the transaction identifier and signature through the relevant execution service.
Store the returned update identifier, status, created records, usage information, and errors.
The platform prepares the operation. The client verifies and authorizes it. The resulting status is returned in a form the application can track.
Examples should be synchronized from maintained documentation or repositories. Exact clients, types, method names, and arguments must match the current release before publication.
let prepared = ledger.prepare_transaction(operation).await?;
verify_transaction(&prepared)?;
let signature = signer.sign(
&prepared.prepared_transaction_hash
);
let result = ledger.execute_transaction(
prepared.transaction_id,
signature
).await?;Inspect the active service, enabled capability groups, supported operations, and environment information before a workflow starts.
Register the agent and obtain the identifiers and configuration required by the selected environment.
Use the current authentication model for methods that require an approved identity or signed session.
Sign the exact hash returned for the prepared transaction rather than reconstructing the operation independently.
Keep private key material inside the approved application, agent, server, cloud, or secure execution environment.
Expose only the operations required by the application or agent, using supported capability groups where available.
Silvana services expose streams and structured state that let agents and applications follow activity as it changes.
Receive the supported orderbook, quote, and market information required by the strategy or product experience.
Follow submission, acceptance, updates, fills, cancellations, and other supported order events.
Track proposals, readiness, allocations, state changes, finalization, expiry, or failure according to the active workflow.
Receive supported Canton updates, active state changes, balances, and execution results.
Subscribe to approved pricing or informational feeds where those services are available.
Use the current cursor, update identifier, or recovery model to resume without losing important workflow state.
A typed action that identifies the workflow being requested.
Operation specific values for the selected asset, participant, amount, service, or settlement flow.
The reference that connects preparation, signing, execution, and retry handling.
The identifier used by the supported workflow to help manage duplicate or inconsistent submissions.
The authorization created inside the approved signing environment.
The canonical reference returned for the committed Canton update when available.
The structured state that tells the client whether execution completed, failed, or requires lifecycle tracking.
A machine readable error that helps the application decide whether to stop, correct, retry, or reconcile.
Use the current command and transaction identifiers to avoid accidental duplicate execution.
Do not infer success from submission alone. Store and evaluate the status returned by the service.
Handle validation, authorization, environment, provider, settlement, and network errors according to documentation.
Retry only when the operation and error class permit it. Do not treat every failed request as safe to repeat.
Resume from the latest durable identifier or state supported by the relevant service.
Log identifiers and state transitions that help operators understand what action is safe next.
The maintained technical documentation defines exact methods, schemas, endpoints, environments, and behavior. Last reviewed June 23, 2026.
Open the full reference for exact schemas, or follow the SDK Guide when the goal is a running agent rather than a direct service integration.