# Authentication
Source: https://docs.silvana.one/agentic-api/authentication

Ed25519 message-level signing for agent requests

All authenticated operations are signed by the **cloud agent's Ed25519 key**. The signature is carried in a top-level `request_signature` field of type [`MessageSignature`](#messagesignature), computed over a canonical encoding of the request payload.

## MessageSignature

```proto theme={null}
message MessageSignature {
  string public_key = 1;   // Ed25519 public key (hex)
  string signature  = 2;   // Ed25519 signature (hex)
  bytes  payload    = 3;   // canonical payload that was signed
}
```

The server responds with its own `response_signature` (signed by the provider's key) so that clients can verify response integrity end-to-end.

## Which methods require a signature

| Method | Signed |
| - | - |
| [`GetServiceInfo`](/agentic-api/core/get-service-info), [`GetLedgerEnd`](/agentic-api/core/get-ledger-end), [`GetDsoRates`](/agentic-api/core/get-dso-rates) | No |
| [`GetAgentConfig`](/agentic-api/onboarding/get-agent-config) | No |
| [`GetBalances`](/agentic-api/core/get-balances), [`GetAmulets`](/agentic-api/core/get-amulets), [`GetActiveContracts`](/agentic-api/core/get-active-contracts), [`GetUpdates`](/agentic-api/core/get-updates), [`GetPreapprovals`](/agentic-api/preapproval/get-preapprovals), [`GetSettlementContracts`](/agentic-api/dvp/get-settlement-contracts) | Yes (session token) |
| [`PrepareTransaction`, `ExecuteTransaction`](/agentic-api/transaction-flow) | Yes (Ed25519) |
| [`RegisterAgent`](/agentic-api/onboarding/register-agent), [`GetOnboardingStatus`](/agentic-api/onboarding/get-onboarding-status), [`SubmitOnboardingSignature`](/agentic-api/onboarding/submit-onboarding-signature) | Yes (Ed25519 — proves key ownership) |

## Session lifetime

[`GetServiceInfo`](/agentic-api/core/get-service-info) returns `session_ttl_secs`, the maximum age of a signed session before the server refuses it. Rotate your signatures well before the TTL expires.

<Warning>
  Never transmit your Ed25519 private key. All signing must happen on the agent side; the ledger service only ever sees public keys and signatures.
</Warning>


# OpenBridge
Source: https://docs.silvana.one/agentic-api/bridge/open-bridge

Open a cross-network bridge session

The `DAppBridgeService` exposes a single RPC used to open bridge sessions between networks.

## Service

```proto theme={null}
service DAppBridgeService {
  rpc OpenBridge (OpenBridgeRequest) returns (OpenBridgeResponse);
}
```

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  list silvana.ledger.v1.DAppBridgeService

grpcurl orderbook-devnet.silvana.dev:443 \
  describe silvana.ledger.v1.DAppBridgeService.OpenBridge
```

<Note>
  Use reflection to discover the full request/response schema of `OpenBridge` against the specific environment you are targeting — the exact fields may evolve independently of `DAppProviderService`.
</Note>

## See also

* Overview — `DAppBridgeService` sits alongside `DAppProviderService` in the same `silvana.ledger.v1` package.
* [`GetServiceInfo`](/agentic-api/core/get-service-info) — for non-bridge operations on the provider service.


# AcceptCip56
Source: https://docs.silvana.one/agentic-api/cip56/accept-cip56

Accept an incoming CIP-56 TransferOffer

Accept an incoming CIP-56 `TransferOffer`. The registrar is extracted automatically from the contract payload — you only need to pass the offer's contract ID.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_ACCEPT_CIP56`
* `params.accept_cip56 = AcceptCip56Params { … }`

## Params

<ParamField type="string">
  Contract ID of the CIP-56 `TransferOffer` to accept.
</ParamField>

```proto theme={null}
message AcceptCip56Params {
  string contract_id = 1;
}
```

<Tip>
  Use [`GetActiveContracts`](/agentic-api/core/get-active-contracts) with a CIP-56 `TransferOffer` template filter to discover pending offer contract IDs.
</Tip>

## See also

* [`TransferCip56`](/agentic-api/cip56/transfer-cip56) — create an outgoing CIP-56 transfer.
* [`GetBalances`](/agentic-api/core/get-balances) — verify the holding was credited after acceptance.


# TransferCip56
Source: https://docs.silvana.one/agentic-api/cip56/transfer-cip56

Transfer a CIP-56 token to a receiver

Transfer an amount of a CIP-56 instrument to a receiver. The instrument must be fully qualified (both `instrument_id` and `instrument_admin` party) — this matches the Daml `InstrumentId = { id: Text, admin: Party }` definition.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_TRANSFER_CIP56`
* `params.transfer_cip56 = TransferCip56Params { … }`

## Params

<ParamField type="string">
  Token identifier.
</ParamField>

<ParamField type="string">
  Admin party of the instrument.
</ParamField>

<ParamField type="string">
  Canton party ID of the receiver.
</ParamField>

<ParamField type="string">
  Decimal amount to transfer.
</ParamField>

<ParamField type="string (optional)">
  Client-supplied reference attached to the transfer.
</ParamField>

```proto theme={null}
message TransferCip56Params {
  string instrument_id    = 1;
  string instrument_admin = 2;
  string receiver_party   = 3;
  string amount           = 4;
  optional string reference = 5;
}
```

## See also

* [`AcceptCip56`](/agentic-api/cip56/accept-cip56) — how the counterparty claims the resulting `TransferOffer`.
* [`GetBalances`](/agentic-api/core/get-balances) — inspect current CIP-56 holdings for the authenticated party.
* [`GetActiveContracts`](/agentic-api/core/get-active-contracts) — enumerate CIP-56 contracts in the ACS.


# GetActiveContracts
Source: https://docs.silvana.one/agentic-api/core/get-active-contracts

Stream active Daml contracts for the authenticated party

**Server-streaming RPC.** Streams all active Daml contracts currently visible to the authenticated party, one contract per message. Results can be narrowed down with a `template_filters` list.

## Request

<ParamField type="string[]">
  Optional list of Daml template identifiers to filter by. Leave empty to stream everything visible to the caller.
</ParamField>

```proto theme={null}
message GetActiveContractsRequest {
  repeated string template_filters = 1;
}
```

## Response

Stream of `GetActiveContractsResponse`:

```proto theme={null}
message GetActiveContractsResponse {
  ActiveContractInfo contract = 1;
}
```

Each `ActiveContractInfo` contains the contract ID, template ID, and serialised payload.

## Example

```bash theme={null}
grpcurl -d '{"template_filters": []}' \
  orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetActiveContracts
```

## See also

* [`GetUpdates`](/agentic-api/core/get-updates) — stream future ledger updates instead of the current snapshot.
* [`GetSettlementContracts`](/agentic-api/dvp/get-settlement-contracts) — narrow lookup for DvP-related contracts by settlement ID.
* [`GetPreapprovals`](/agentic-api/preapproval/get-preapprovals) — narrow lookup for active `TransferPreapproval` contracts.
* [`AcceptCip56`](/agentic-api/cip56/accept-cip56) — common consumer of CIP-56 `TransferOffer` contract IDs discovered here.


# GetAmulets
Source: https://docs.silvana.one/agentic-api/core/get-amulets

Unlocked Canton Coin amulet contracts with amounts

Lightweight ACS (Active Contract Set) query that returns all unlocked Canton Coin amulet contracts held by the authenticated party, along with their amounts. Use it to pick amulets for payment scheduling and fee selection.

## Request

```proto theme={null}
message GetAmuletsRequest {}
```

## Response

<ParamField type="AmuletInfo[]">
  List of unlocked amulets — each contains a contract ID and an amount.
</ParamField>

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetAmulets
```

## See also

`GetAmulets` is typically called before any operation that consumes Canton Coin, so that the client can pick amulets explicitly via the `amulet_cids` parameter:

* [`TransferCc`](/agentic-api/transfer/transfer-cc) — transfer CC to a receiver
* [`SplitCc`](/agentic-api/transfer/split-cc) — merge and split amulets
* [`PayDvpFee`](/agentic-api/dvp/pay-dvp-fee) / [`PayAllocFee`](/agentic-api/dvp/pay-alloc-fee) — pay DvP settlement fees
* [`Allocate`](/agentic-api/dvp/allocate) — allocate amulets to a `Dvp` contract
* [`ExecuteMultiCall`](/agentic-api/multicall/execute-multicall) — consume amulets in an atomic batch

For balance totals across all tokens (CC + CIP-56 holdings), use [`GetBalances`](/agentic-api/core/get-balances) instead.


# GetBalances
Source: https://docs.silvana.one/agentic-api/core/get-balances

Token balances for the authenticated party

Returns all token balances held by the authenticated party — both CIP-56 token holdings and Canton Coin.

## Request

```proto theme={null}
message GetBalancesRequest {}
```

## Response

<ParamField type="TokenBalance[]">
  List of balances. Each `TokenBalance` includes the token instrument identifier, admin party, and the amount held.
</ParamField>

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetBalances
```

## See also

* [`GetAmulets`](/agentic-api/core/get-amulets) — list individual unlocked Canton Coin amulet contracts (needed to pick `amulet_cids` for state-changing operations).
* [`GetActiveContracts`](/agentic-api/core/get-active-contracts) — stream all active Daml contracts visible to the authenticated party.


# GetDsoRates
Source: https://docs.silvana.one/agentic-api/core/get-dso-rates

CC/USD rate, current mining round, and DSO party info

Returns DSO (Decentralised Synchronizer Operator) rate information — Canton Coin to USD rate, current mining round, amulet price, and lists of open and issuing mining rounds. Useful for pricing fees and scheduling payments.

## Request

```proto theme={null}
message GetDsoRatesRequest {}
```

## Response

<ParamField type="string">Current CC/USD exchange rate (decimal string).</ParamField>
<ParamField type="string">Amulet price for the current round.</ParamField>
<ParamField type="uint64">Current mining round number.</ParamField>
<ParamField type="string">DSO party identifier.</ParamField>
<ParamField type="string">Featured-app rewards issuance rate.</ParamField>
<ParamField type="OpenMiningRound[]">Active mining rounds accepting transfers.</ParamField>
<ParamField type="IssuingMiningRound[]">Rounds currently issuing rewards.</ParamField>

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetDsoRates
```

## See also

* [`GetAmulets`](/agentic-api/core/get-amulets) — pick amulets to consume in a Canton Coin operation.
* [`GetBalances`](/agentic-api/core/get-balances) — total token balances for the authenticated party.
* [`TransferCc`](/agentic-api/transfer/transfer-cc) — use the CC/USD rate to schedule payments.


# GetLedgerEnd
Source: https://docs.silvana.one/agentic-api/core/get-ledger-end

Fetch the current ledger end offset

Returns the current ledger end offset. Use it as the `begin_exclusive` for a subsequent [`GetUpdates`](/agentic-api/core/get-updates) stream, or to checkpoint progress when polling for transaction confirmations.

## Request

```proto theme={null}
message GetLedgerEndRequest {}
```

## Response

<ParamField type="int64">Current ledger end offset.</ParamField>

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetLedgerEnd
```

## See also

* [`GetUpdates`](/agentic-api/core/get-updates) — pass the returned offset as `begin_exclusive` to start streaming new ledger updates.


# GetPrepaidTrafficBalance
Source: https://docs.silvana.one/agentic-api/core/get-prepaid-traffic-balance

Remaining prepaid traffic balance for the authenticated party

Returns the remaining prepaid Canton traffic balance for the authenticated party. Use it to monitor headroom before submitting transactions and to surface low-balance warnings in agent dashboards.

## Request

```proto theme={null}
message GetPrepaidTrafficBalanceRequest {}
```

## Response

<ParamField type="string">
  Remaining prepaid traffic balance, expressed in the same units as `TrafficEstimate.total_cost`.
</ParamField>

<ParamField type="Timestamp (optional)">
  When the balance was last refreshed on the provider side.
</ParamField>

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetPrepaidTrafficBalance
```

## See also

* [Transaction flow](/agentic-api/transaction-flow) — every prepared transaction returns a `TrafficEstimate`; compare it against this balance before executing.
* [`GetBalances`](/agentic-api/core/get-balances) — token balances (CC, CIP-56), separate from traffic.


# GetServiceInfo
Source: https://docs.silvana.one/agentic-api/core/get-service-info

Discover provider metadata and supported operations

Returns metadata about the provider service — network, synchronizer, supported operations, session TTL. Use it as a health check and to discover which functional groups are enabled on this server.

<Info>
  Unauthenticated — no signature required.
</Info>

## Request

```proto theme={null}
message GetServiceInfoRequest {}
```

## Response

<ParamField type="string">Provider identifier.</ParamField>
<ParamField type="string">Service version string.</ParamField>
<ParamField type="string">Provider type (e.g. `orderbook-ledger-service`).</ParamField>
<ParamField type="TransactionOperation[]">List of operations enabled on this server — see the [`TransactionOperation` enum](/agentic-api/transaction-flow#transactionoperation).</ParamField>
<ParamField type="string">Canton network identifier.</ParamField>
<ParamField type="string">Canton synchronizer party ID.</ParamField>
<ParamField type="uint64">Maximum lifetime of a signed session.</ParamField>

## Example

<CodeGroup>
  ```bash grpcurl theme={null}
  grpcurl orderbook-devnet.silvana.dev:443 \
    silvana.ledger.v1.DAppProviderService/GetServiceInfo
  ```
</CodeGroup>

## See also

* [`TransactionOperation` enum](/agentic-api/transaction-flow#transactionoperation) — full list of values that can appear in `supported_operations`.
* [Transaction flow](/agentic-api/transaction-flow) — how to invoke any of the supported operations once you've confirmed they are enabled.
* [Authentication](/agentic-api/authentication#session-lifetime) — `session_ttl_secs` controls how long a signed session remains valid.


# GetUpdates
Source: https://docs.silvana.one/agentic-api/core/get-updates

Stream ledger updates from a given offset

**Server-streaming RPC.** Streams ledger updates from a starting offset (exclusive) up to an optional end offset (inclusive). Each message is either a committed `LedgerTransaction` or a bare `LedgerOffsetCheckpoint`. Typically used to confirm transaction submission or to tail the ledger.

## Request

<ParamField type="int64">
  Offset to start streaming from (exclusive). Use the result of [`GetLedgerEnd`](/agentic-api/core/get-ledger-end) to start from "now".
</ParamField>

<ParamField type="int64 (optional)">
  Optional end offset (inclusive). Omit to stream indefinitely.
</ParamField>

<ParamField type="string[]">
  Optional Daml template filters.
</ParamField>

```proto theme={null}
message GetUpdatesRequest {
  int64 begin_exclusive        = 1;
  optional int64 end_inclusive = 2;
  repeated string template_filters = 3;
}
```

## Response

```proto theme={null}
message GetUpdatesResponse {
  oneof update {
    LedgerTransaction       transaction       = 1;
    LedgerOffsetCheckpoint  offset_checkpoint = 2;
  }
}
```

<Note>
  `offset_checkpoint` messages let the server advance your cursor even when no transactions match your filter — always persist the latest observed offset to resume cleanly.
</Note>

## See also

* [`GetLedgerEnd`](/agentic-api/core/get-ledger-end) — fetch the current offset to use as `begin_exclusive`.
* [`GetActiveContracts`](/agentic-api/core/get-active-contracts) — snapshot of currently active contracts (one-shot, not a tail).
* [`ExecuteTransaction`](/agentic-api/transaction-flow) — `update_id` from its response can be matched against `LedgerTransaction` events here for confirmation.


# ListFaucetInstruments
Source: https://docs.silvana.one/agentic-api/core/list-faucet-instruments

Token instruments currently supported by the faucet

Returns the list of token instruments that the faucet can dispense in the active environment. Use this before calling the faucet to discover which instruments are eligible and what limits apply.

The faucet is enabled in development environments only.

## Request

```proto theme={null}
message ListFaucetInstrumentsRequest {}
```

## Response

<ParamField type="FaucetInstrument[]">
  Each entry describes a faucet-enabled instrument: its identifier, optional admin party, the per-request amount, and any cooldown or daily cap that the faucet enforces.
</ParamField>

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/ListFaucetInstruments
```

## See also

* `RequestFaucet` — request funds for one of the instruments returned here. Documented in the [Ledger Gateway API](/sdk/grpc-api/ledger-gateway-api#faucet) overview.
* [`GetBalances`](/agentic-api/core/get-balances) — confirm that funds arrived after a faucet request.


# AcceptDvp
Source: https://docs.silvana.one/agentic-api/dvp/accept-dvp

Accept a DvpProposal as the counterparty

Counterparty-side acceptance of a DvP proposal previously created via [`ProposeDvp`](/agentic-api/dvp/propose-dvp).

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_ACCEPT_DVP`
* `params.accept_dvp = AcceptDvpParams { … }`

## Params

<ParamField type="string">
  Settlement proposal identifier.
</ParamField>

<ParamField type="string">
  Contract ID of the `DvpProposal` being accepted — discover it via [`GetSettlementContracts`](/agentic-api/dvp/get-settlement-contracts).
</ParamField>

```proto theme={null}
message AcceptDvpParams {
  string proposal_id     = 1;
  string dvp_proposal_cid = 2;
}
```

## Next step

After acceptance, the proposer pays the allocation fee with [`PayAllocFee`](/agentic-api/dvp/pay-alloc-fee) and then allocates amulets with [`Allocate`](/agentic-api/dvp/allocate) to execute settlement.

**Full sequence**: [PayDvpFee](/agentic-api/dvp/pay-dvp-fee) → [ProposeDvp](/agentic-api/dvp/propose-dvp) → **AcceptDvp** → [PayAllocFee](/agentic-api/dvp/pay-alloc-fee) → [Allocate](/agentic-api/dvp/allocate).


# Allocate
Source: https://docs.silvana.one/agentic-api/dvp/allocate

Allocate amulets to a Dvp contract

Final step of the DvP flow — allocate specific Canton Coin amulets to an accepted `Dvp` contract so that settlement can execute.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_ALLOCATE`
* `params.allocate = AllocateParams { … }`

## Params

<ParamField type="string">
  Settlement proposal identifier.
</ParamField>

<ParamField type="string">
  Contract ID of the accepted `Dvp` contract.
</ParamField>

<ParamField type="string[]">
  Contract IDs of the amulets being allocated to the settlement.
</ParamField>

```proto theme={null}
message AllocateParams {
  string proposal_id = 1;
  string dvp_cid     = 2;
  repeated string amulet_cids = 3;
}
```

<Tip>
  Use [`GetSettlementContracts`](/agentic-api/dvp/get-settlement-contracts) to discover the `dvp_cid`, and [`GetAmulets`](/agentic-api/core/get-amulets) to pick the amulets you want to allocate.
</Tip>

## DvP flow

**Full sequence**: [PayDvpFee](/agentic-api/dvp/pay-dvp-fee) → [ProposeDvp](/agentic-api/dvp/propose-dvp) → [AcceptDvp](/agentic-api/dvp/accept-dvp) → [PayAllocFee](/agentic-api/dvp/pay-alloc-fee) → **Allocate**.

On success, the settlement is complete.


# GetSettlementContracts
Source: https://docs.silvana.one/agentic-api/dvp/get-settlement-contracts

Discover on-chain DvpProposal and Dvp contracts for active settlements

Look up on-chain `DvpProposal` and `Dvp` contracts for a given list of settlement IDs. Use it to discover the state of active settlements before proposing, accepting, or allocating.

## Request

<ParamField type="string[]">
  Settlement identifiers to look up.
</ParamField>

```proto theme={null}
message GetSettlementContractsRequest {
  repeated string settlement_ids = 1;
}
```

## Response

<ParamField type="DiscoveredContract[]">
  Matching DvP-related contracts, each with contract ID, template ID, and payload.
</ParamField>

## Example

```bash theme={null}
grpcurl -d '{"settlement_ids": ["sett-123"]}' \
  orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetSettlementContracts
```

## DvP flow

`GetSettlementContracts` is typically called by the counterparty before [`AcceptDvp`](/agentic-api/dvp/accept-dvp), and by the proposer before [`Allocate`](/agentic-api/dvp/allocate), to discover the relevant contract IDs.

**Full sequence**: [PayDvpFee](/agentic-api/dvp/pay-dvp-fee) → [ProposeDvp](/agentic-api/dvp/propose-dvp) → [AcceptDvp](/agentic-api/dvp/accept-dvp) → [PayAllocFee](/agentic-api/dvp/pay-alloc-fee) → [Allocate](/agentic-api/dvp/allocate).


# PayAllocFee
Source: https://docs.silvana.one/agentic-api/dvp/pay-alloc-fee

Pay the allocation fee required before Allocate

Pay the allocation fee for a DvP settlement. Required before [`Allocate`](/agentic-api/dvp/allocate) can be invoked on the same proposal.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_PAY_ALLOC_FEE`
* `params.pay_fee = PayFeeParams { fee_type = "alloc", … }`

## Params

Uses the shared `PayFeeParams` message (see [`PayDvpFee`](/agentic-api/dvp/pay-dvp-fee)). Set `fee_type = "alloc"`.

```proto theme={null}
message PayFeeParams {
  string proposal_id = 1;
  string fee_type    = 2;
  repeated string amulet_cids = 3;
}
```

## Next step

With the allocation fee paid, call [`Allocate`](/agentic-api/dvp/allocate) with the `dvp_cid` to execute settlement.

**Full sequence**: [PayDvpFee](/agentic-api/dvp/pay-dvp-fee) → [ProposeDvp](/agentic-api/dvp/propose-dvp) → [AcceptDvp](/agentic-api/dvp/accept-dvp) → **PayAllocFee** → [Allocate](/agentic-api/dvp/allocate).


# PayDvpFee
Source: https://docs.silvana.one/agentic-api/dvp/pay-dvp-fee

Pay the DvP settlement fee for a proposal

Pay the Delivery-vs-Payment settlement fee for a given settlement proposal. This is the first step in the DvP flow — a fee must be paid before `ProposeDvp` can be invoked.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_PAY_DVP_FEE`
* `params.pay_fee = PayFeeParams { fee_type = "dvp", … }`

## Params

<ParamField type="string">
  Settlement proposal identifier.
</ParamField>

<ParamField type="string">
  Fee kind (e.g. `dvp`).
</ParamField>

<ParamField type="string[]">
  Specific amulet contract IDs used to pay the fee.
</ParamField>

```proto theme={null}
message PayFeeParams {
  string proposal_id = 1;
  string fee_type    = 2;
  repeated string amulet_cids = 3;
}
```

## Next step

Once the fee is paid, call [`ProposeDvp`](/agentic-api/dvp/propose-dvp) with the same `proposal_id` to create the on-chain `DvpProposal`.

**Full sequence**: [GetSettlementContracts](/agentic-api/dvp/get-settlement-contracts) → **PayDvpFee** → [ProposeDvp](/agentic-api/dvp/propose-dvp) → [AcceptDvp](/agentic-api/dvp/accept-dvp) → [PayAllocFee](/agentic-api/dvp/pay-alloc-fee) → [Allocate](/agentic-api/dvp/allocate).


# ProposeDvp
Source: https://docs.silvana.one/agentic-api/dvp/propose-dvp

Create an on-chain DvpProposal

Propose a Delivery-vs-Payment settlement on chain. The proposer must have already paid the DvP fee with [`PayDvpFee`](/agentic-api/dvp/pay-dvp-fee).

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_PROPOSE_DVP`
* `params.propose_dvp = ProposeDvpParams { … }`

## Params

<ParamField type="string">
  Settlement proposal identifier — must match the one used in `PayDvpFee`.
</ParamField>

```proto theme={null}
message ProposeDvpParams {
  string proposal_id = 1;
}
```

## Next step

The counterparty discovers the resulting `DvpProposal` via [`GetSettlementContracts`](/agentic-api/dvp/get-settlement-contracts) and accepts it with [`AcceptDvp`](/agentic-api/dvp/accept-dvp).

**Full sequence**: [PayDvpFee](/agentic-api/dvp/pay-dvp-fee) → **ProposeDvp** → [AcceptDvp](/agentic-api/dvp/accept-dvp) → [PayAllocFee](/agentic-api/dvp/pay-alloc-fee) → [Allocate](/agentic-api/dvp/allocate).


# Getting Started
Source: https://docs.silvana.one/agentic-api/getting-started

Programmatic access to the Canton Network through the Silvana Ledger gRPC service

The **Silvana Ledger** service exposes a **gRPC** interface for agents and backend applications that need to transact on the Canton Network.

Follow on to start using the **Agentic API**.

<Card title="Proto definitions" icon="github" href="https://github.com/SilvanaOne/silvana-book-agent/tree/proto/proto/silvana/ledger/v1">
  Canonical `.proto` files for `silvana.ledger.v1` — service, enum, and message definitions.
</Card>

## Endpoint

<CodeGroup>
  ```bash DevNet theme={null}
  orderbook-devnet.silvana.dev:443
  ```
</CodeGroup>

## Services

The package `silvana.ledger.v1` exposes two services:

<CardGroup>
  <Card title="DAppProviderService" icon="server">
    Main service for agentic operations: queries, transaction preparation and execution, onboarding.
  </Card>

  <Card title="DAppBridgeService" icon="link">
    Bridge operations between networks.
  </Card>
</CardGroup>

## Reflection

The server supports gRPC reflection, so you can introspect the schema with any reflection-aware client (grpcurl, Postman, BloomRPC):

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 list
grpcurl orderbook-devnet.silvana.dev:443 list silvana.ledger.v1.DAppProviderService
grpcurl orderbook-devnet.silvana.dev:443 describe silvana.ledger.v1.DAppProviderService
```

## Functional groups

Operations are organised into **functional groups**. Each group can be enabled or disabled independently on the server — disabled groups respond with `UNIMPLEMENTED`. The `core` group is always enabled.

| Group | Methods |
| - | - |
| `core` | Read-only queries — always available ([GetServiceInfo](/agentic-api/core/get-service-info), [GetLedgerEnd](/agentic-api/core/get-ledger-end), [GetDsoRates](/agentic-api/core/get-dso-rates), [GetBalances](/agentic-api/core/get-balances), [GetAmulets](/agentic-api/core/get-amulets), [GetActiveContracts](/agentic-api/core/get-active-contracts), [GetUpdates](/agentic-api/core/get-updates)) |
| `transfer` | [TransferCc](/agentic-api/transfer/transfer-cc), [SplitCc](/agentic-api/transfer/split-cc) |
| `preapproval` | [GetPreapprovals](/agentic-api/preapproval/get-preapprovals), [RequestPreapproval](/agentic-api/preapproval/request-preapproval) |
| `dvp` | [GetSettlementContracts](/agentic-api/dvp/get-settlement-contracts), [PayDvpFee](/agentic-api/dvp/pay-dvp-fee), [ProposeDvp](/agentic-api/dvp/propose-dvp), [AcceptDvp](/agentic-api/dvp/accept-dvp), [PayAllocFee](/agentic-api/dvp/pay-alloc-fee), [Allocate](/agentic-api/dvp/allocate) |
| `cip56` | [TransferCip56](/agentic-api/cip56/transfer-cip56), [AcceptCip56](/agentic-api/cip56/accept-cip56) |
| `recurring` | [RequestRecurringPrepaid](/agentic-api/recurring/request-recurring-prepaid), [RequestRecurringPayasyougo](/agentic-api/recurring/request-recurring-payasyougo) |
| `onboarding` | [GetAgentConfig](/agentic-api/onboarding/get-agent-config), [RegisterAgent](/agentic-api/onboarding/register-agent), [GetOnboardingStatus](/agentic-api/onboarding/get-onboarding-status), [SubmitOnboardingSignature](/agentic-api/onboarding/submit-onboarding-signature) |
| `multicall` | [ExecuteMultiCall](/agentic-api/multicall/execute-multicall) |
| `user_service` | [RequestUserService](/agentic-api/user-service/request-user-service) |

<Note>
  Check which operations are supported on a specific server by calling [`GetServiceInfo`](/agentic-api/core/get-service-info). The response includes a `supported_operations` list of [`TransactionOperation`](/agentic-api/transaction-flow#transactionoperation) enum values.
</Note>

## Next steps

<CardGroup>
  <Card title="Authentication" icon="key" href="/agentic-api/authentication">
    How Ed25519 request signing works and which methods require it.
  </Card>

  <Card title="Transaction flow" icon="arrows-rotate" href="/agentic-api/transaction-flow">
    The full two-phase prepare → sign → execute model with enum and oneof references.
  </Card>

  <Card title="Onboarding" icon="user-plus" href="/agentic-api/onboarding/get-agent-config">
    Register a new agent and obtain a Canton party.
  </Card>

  <Card title="GetServiceInfo" icon="circle-info" href="/agentic-api/core/get-service-info">
    Discover which functional groups are enabled on a specific server.
  </Card>
</CardGroup>


# Agentic API Intro
Source: https://docs.silvana.one/agentic-api/intro



Agentic execution is at the core of Silvana’s design. To get and use data, agents need a direct interface to interact with Canton.

<Check>
  Agentic API – the execution layer for Canton-native apps.
</Check>

Agentic API runs via the **Silvana Ledger,** exposing  a unified **gRPC** interface for agents and backend applications that need to transact on the Canton Network.

* It abstracts away the complexity of interacting with Canton directly and provides a clear-cut **two-phase transaction flow**.
* Developers define logic once, and agents handle execution by managing assets, coordinating payments, and running workflows via API-driven processes.

# Two-phase transaction flow

Operations resulting in a state transition (transfer, DvP, CIP-56, recurring payments, multicall, etc.) never execute in a single RPC. Instead, they follow a **prepare → sign → execute** flow. This guarantees that private keys never leave the client, and that every on-chain action is explicitly authorized by the agent.

See [Transaction flow](/agentic-api/transaction-flow) for more details, the full message schema, and an operations reference table.

# Core Capabilities

Check the use cases below to see the true power of Agentic API.

<CardGroup>
  <Card title="CIP-56 Payment" href="/agentic-api/cip56/transfer-cip56">
    Programmable, verifiable, agent-driven payments by Canton's CIP-56 standard.
  </Card>

  <Card title="DvP Execution" href="/agentic-api/dvp/get-settlement-contracts">
    Run transactions by the Delivery-versus-Payment (DvP) flow.
  </Card>

  <Card title="CC Transfer" href="/agentic-api/transfer/transfer-cc">
    Transfer Canton Coins in bulk or by splitting.
  </Card>

  <Card title="Payroll" href="/agentic-api/recurring/request-recurring-prepaid">
    Execute regular programmable payments.
  </Card>

  <Card title="Stay Updated" href="/agentic-api/core/get-updates">
    Get an ongoing stream of updates telling you what's going on in Canton.
  </Card>

  <Card title="Multicall" href="/agentic-api/multicall/execute-multicall">
    Execute multi-step workflows involving several agents.
  </Card>

  <Card title="Bridged Transactions" href="/agentic-api/bridge/open-bridge">
    Run cross-chain transactions via a bridge.
  </Card>

  <Card title="Request User Service" href="/agentic-api/user-service/request-user-service">
    Engage the provider to do a required action for provider-defined user flows.
  </Card>
</CardGroup>

Read more here

<CardGroup>
  <Card title="Getting Started" icon="book" href="/agentic-api/getting-started">
    Start building: endpoint, services, reflection, and functional groups.
  </Card>

  <Card title="Authentication" icon="key" href="/agentic-api/authentication">
    Ed25519 signing and methods requiring a signed session.
  </Card>

  <Card title="Transaction flow" icon="arrows-rotate" href="/agentic-api/transaction-flow">
    Two-phase prepare → sign → execute model and `TransactionOperation` reference.
  </Card>
</CardGroup>

<Check>
  Power your agents with Agentic API! Build with ease!
</Check>


# ExecuteMultiCall
Source: https://docs.silvana.one/agentic-api/multicall/execute-multicall

Atomically execute a batch of operations via Execute_MultiCall

Atomically execute a batch of operations through Canton's `Execute_MultiCall` DAR choice. Each sub-operation is individually gated against its own functional group — a disabled group will cause the whole batch to be rejected.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_EXECUTE_MULTICALL`
* `params.execute_multicall = ExecuteMultiCallParams { … }`

## Params

<ParamField type="MultiCallOp[]">
  Ordered list of sub-operations to execute atomically.
</ParamField>

<ParamField type="string[]">
  Canton Coin amulets to be consumed by the batch.
</ParamField>

<ParamField type="string[]">
  CIP-56 holding contract IDs to be consumed by the batch.
</ParamField>

```proto theme={null}
message ExecuteMultiCallParams {
  repeated MultiCallOp operations   = 1;
  repeated string      amulet_cids  = 2;
  repeated string      holding_cids = 3;
}
```

<Warning>
  All sub-operations succeed or the entire batch is rolled back. MultiCall is the right tool when two or more actions must be strictly atomic (e.g. split + transfer in the same commit).
</Warning>

<Tip>
  Call [`GetAmulets`](/agentic-api/core/get-amulets) and [`GetActiveContracts`](/agentic-api/core/get-active-contracts) to pre-select the `amulet_cids` and `holding_cids` the batch should consume.
</Tip>

## See also

* [`TransferCc`](/agentic-api/transfer/transfer-cc), [`SplitCc`](/agentic-api/transfer/split-cc) — common Canton Coin sub-operations.
* [`TransferCip56`](/agentic-api/cip56/transfer-cip56), [`AcceptCip56`](/agentic-api/cip56/accept-cip56) — common CIP-56 sub-operations.
* [`Allocate`](/agentic-api/dvp/allocate) — DvP allocation that is often combined with other steps via MultiCall.
* [`GetServiceInfo`](/agentic-api/core/get-service-info) — confirm each sub-operation's group is enabled before batching.


# GetAgentConfig
Source: https://docs.silvana.one/agentic-api/onboarding/get-agent-config

Fetch the agent configuration template

Returns the agent configuration template — the set of parameters (synchronizer, settlement operator, fee parties, subscription terms, traffic pricing) that a newly onboarded agent needs to operate against this provider.

<Info>
  Unauthenticated — no signature required.
</Info>

## Request

```proto theme={null}
message GetAgentConfigRequest {}
```

## Response

<ParamField type="string">Canton synchronizer party ID.</ParamField>
<ParamField type="string">Party ID of the settlement operator.</ParamField>
<ParamField type="string">Party that receives traffic fees.</ParamField>
<ParamField type="string">Traffic price in USD per megabyte.</ParamField>
<ParamField type="string">Party that receives operational fees.</ParamField>
<ParamField type="string">Node identifier for this provider.</ParamField>
<ParamField type="string">Ed25519 public key of the ledger service — used to verify `response_signature`.</ParamField>
<ParamField type="string">Party used for subscription-based recurring payments.</ParamField>
<ParamField type="string">Subscription amount charged per cycle.</ParamField>
<ParamField type="string">Traffic package required to join.</ParamField>
<ParamField type="string">Canton Coin reserve required by the agent.</ParamField>
<ParamField type="string">DAR package name for recurring payments.</ParamField>

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetAgentConfig
```

## Next step

Once the agent has a local copy of the config, call [`RegisterAgent`](/agentic-api/onboarding/register-agent) to join the provider's waiting list.

**Onboarding sequence**: **GetAgentConfig** → [RegisterAgent](/agentic-api/onboarding/register-agent) → [GetOnboardingStatus](/agentic-api/onboarding/get-onboarding-status) → [SubmitOnboardingSignature](/agentic-api/onboarding/submit-onboarding-signature).


# GetOnboardingStatus
Source: https://docs.silvana.one/agentic-api/onboarding/get-onboarding-status

Poll the onboarding status for a registered agent

Poll the onboarding status for an agent. Once the provider assigns a party and issues a multihash to sign, the response will include both `party_id` and `multihash`. The request must be signed with the agent's Ed25519 key.

## Request

<ParamField type="string">
  Ed25519 public key of the agent (hex).
</ParamField>

<ParamField type="MessageSignature">
  Signature proving ownership of `public_key` — see [Authentication](/agentic-api/authentication#messagesignature).
</ParamField>

```proto theme={null}
message GetOnboardingStatusRequest {
  string public_key = 1;
  MessageSignature request_signature = 30;
}
```

## Response

<ParamField type="OnboardingStatus">Current onboarding status.</ParamField>
<ParamField type="string (optional)">Allocated Canton party ID, once assigned.</ParamField>
<ParamField type="string (optional)">Multihash that must be signed with [`SubmitOnboardingSignature`](/agentic-api/onboarding/submit-onboarding-signature).</ParamField>
<ParamField type="string (optional)">Populated if onboarding failed.</ParamField>
<ParamField type="uint64">Waiting list position.</ParamField>

## Next step

When `multihash` is populated, sign it locally and submit it with [`SubmitOnboardingSignature`](/agentic-api/onboarding/submit-onboarding-signature).

**Onboarding sequence**: [GetAgentConfig](/agentic-api/onboarding/get-agent-config) → [RegisterAgent](/agentic-api/onboarding/register-agent) → **GetOnboardingStatus** → [SubmitOnboardingSignature](/agentic-api/onboarding/submit-onboarding-signature).


# RegisterAgent
Source: https://docs.silvana.one/agentic-api/onboarding/register-agent

Register a new agent on the waiting list

Register an agent on the provider's waiting list. The request is signed with the agent's Ed25519 private key, proving ownership of the public key. After registration, poll [`GetOnboardingStatus`](/agentic-api/onboarding/get-onboarding-status) until a `multihash` is issued.

## Request

<ParamField type="string">
  Ed25519 public key of the agent (hex).
</ParamField>

<ParamField type="string (optional)">
  Invite code, if the provider requires one.
</ParamField>

<ParamField type="string (optional)">
  Contact email.
</ParamField>

<ParamField type="string (optional)">
  Human-readable agent name.
</ParamField>

<ParamField type="MessageSignature">
  Ed25519 signature over the canonical request payload proving ownership of `public_key` — see [Authentication](/agentic-api/authentication#messagesignature).
</ParamField>

```proto theme={null}
message RegisterAgentRequest {
  string public_key = 1;
  optional string invite_code = 2;
  optional string email       = 3;
  optional string agent_name  = 4;
  MessageSignature request_signature = 30;
}
```

## Response

<ParamField type="bool">Whether registration succeeded.</ParamField>
<ParamField type="string">Human-readable status message.</ParamField>
<ParamField type="uint64">Position on the waiting list.</ParamField>
<ParamField type="OnboardingStatus">Initial onboarding status (e.g. `WAITING`).</ParamField>

## Next step

Poll [`GetOnboardingStatus`](/agentic-api/onboarding/get-onboarding-status) with the same `public_key` until it returns a `multihash` ready to sign.

**Onboarding sequence**: [GetAgentConfig](/agentic-api/onboarding/get-agent-config) → **RegisterAgent** → [GetOnboardingStatus](/agentic-api/onboarding/get-onboarding-status) → [SubmitOnboardingSignature](/agentic-api/onboarding/submit-onboarding-signature).


# SubmitOnboardingSignature
Source: https://docs.silvana.one/agentic-api/onboarding/submit-onboarding-signature

Submit the multihash signature to finalise onboarding

Final step of onboarding — submit the agent's Ed25519 signature over the `multihash` returned by [`GetOnboardingStatus`](/agentic-api/onboarding/get-onboarding-status). Once accepted, the agent transitions to an active state.

## Request

<ParamField type="string">
  Ed25519 public key of the agent.
</ParamField>

<ParamField type="string">
  Hex-encoded Ed25519 signature over the multihash.
</ParamField>

<ParamField type="MessageSignature">
  Signature proving ownership of `public_key` — see [Authentication](/agentic-api/authentication#messagesignature).
</ParamField>

```proto theme={null}
message SubmitOnboardingSignatureRequest {
  string public_key          = 1;
  string multihash_signature = 2;
  MessageSignature request_signature = 30;
}
```

## Response

<ParamField type="bool">Whether the signature was accepted.</ParamField>
<ParamField type="string">Human-readable status.</ParamField>
<ParamField type="OnboardingStatus">Updated onboarding status.</ParamField>

## After onboarding

Once the signature is accepted, the agent is active and can begin making authenticated calls — start with [`GetServiceInfo`](/agentic-api/core/get-service-info) to confirm supported operations, then follow the [transaction flow](/agentic-api/transaction-flow) for state-changing calls.

**Onboarding sequence**: [GetAgentConfig](/agentic-api/onboarding/get-agent-config) → [RegisterAgent](/agentic-api/onboarding/register-agent) → [GetOnboardingStatus](/agentic-api/onboarding/get-onboarding-status) → **SubmitOnboardingSignature**.


# ExecutePayFee
Source: https://docs.silvana.one/agentic-api/payment/execute-pay-fee

Phase 2 of the fee-payment flow: submit the locally signed fee transaction

`ExecutePayFee` submits the agent-signed fee-payment transaction to Canton. It is the second phase of the fee-only counterpart to [`ExecuteTransaction`](/agentic-api/transaction-flow).

## Request

<ParamField type="string">
  Value returned from [`PreparePayFee`](/agentic-api/payment/prepare-pay-fee).
</ParamField>

<ParamField type="string">
  Hex-encoded Ed25519 signature over `prepared_transaction_hash`.
</ParamField>

<ParamField type="MessageSignature">
  Message-level signature from the cloud agent — see [Authentication](/agentic-api/authentication#messagesignature).
</ParamField>

## Response

<ParamField type="bool">
  `true` if the fee transaction was submitted and committed successfully.
</ParamField>

<ParamField type="string">
  Canton update ID of the committed fee transaction.
</ParamField>

<ParamField type="TrafficEstimate">
  Actual traffic consumed.
</ParamField>

<ParamField type="string (optional)">
  Human-readable error.
</ParamField>

<ParamField type="ProviderError (optional)">
  Structured error (`ProviderRpcError`) when `success = false`.
</ParamField>

<ParamField type="TransactionStatus">
  `EXECUTED` on success, `FAILED` on error.
</ParamField>

## See also

* [`PreparePayFee`](/agentic-api/payment/prepare-pay-fee) — phase 1, build the transaction and obtain the hash to sign.
* [`PayDvpFee`](/agentic-api/dvp/pay-dvp-fee), [`PayAllocFee`](/agentic-api/dvp/pay-alloc-fee) — settlement operations that depend on a paid fee.
* [Transaction flow](/agentic-api/transaction-flow) — the parallel general-purpose flow.


# PreparePayFee
Source: https://docs.silvana.one/agentic-api/payment/prepare-pay-fee

Phase 1 of the fee-payment flow: build a fee-payment transaction to sign locally

`PreparePayFee` builds a Canton transaction whose only purpose is to pay a fee — for example a DvP settlement fee or an allocation fee — and returns the prepared transaction hash for the agent to sign locally with its Ed25519 key.

This is the fee-payment counterpart to [`PrepareTransaction`](/agentic-api/transaction-flow). It follows the same **prepare → sign → execute** model as ordinary transactions but is scoped to fee-only operations.

## When to use it

Use this method when an operation requires a fee leg as a separate signed transaction — for example, before `ProposeDvp` or `Allocate` in the DvP flow. Operations that bundle a fee internally (most multicall and transfer flows) use `PrepareTransaction` instead.

## Request

<ParamField type="string">
  Fee kind, e.g. `dvp` or `alloc`.
</ParamField>

<ParamField type="string">
  Settlement proposal identifier when paying a DvP-related fee.
</ParamField>

<ParamField type="string[]">
  Explicit amulet contract IDs to consume for the fee. If omitted, the server selects amulets automatically.
</ParamField>

<ParamField type="MessageSignature">
  Message-level signature from the cloud agent — see [Authentication](/agentic-api/authentication#messagesignature).
</ParamField>

## Response

<ParamField type="string">
  Opaque server-assigned ID. Pass this into [`ExecutePayFee`](/agentic-api/payment/execute-pay-fee).
</ParamField>

<ParamField type="string">
  Hex-encoded Canton transaction hash. **This is what the agent must sign.**
</ParamField>

<ParamField type="bytes">
  Serialised prepared transaction (for deterministic re-hashing if desired).
</ParamField>

<ParamField type="string">
  Canton hashing scheme version used to compute the hash.
</ParamField>

<ParamField type="TrafficEstimate">
  Estimated Canton traffic the fee transaction will consume.
</ParamField>

<ParamField type="MessageSignature">
  Provider signature over the response payload.
</ParamField>

## See also

* [`ExecutePayFee`](/agentic-api/payment/execute-pay-fee) — phase 2, submit the signed fee transaction.
* [Transaction flow](/agentic-api/transaction-flow) — the full prepare/sign/execute model used by general transactions.
* [`PayDvpFee`](/agentic-api/dvp/pay-dvp-fee), [`PayAllocFee`](/agentic-api/dvp/pay-alloc-fee) — high-level operations layered on top of this flow.


# GetPreapprovals
Source: https://docs.silvana.one/agentic-api/preapproval/get-preapprovals

List active TransferPreapproval contracts

Returns all active `TransferPreapproval` contracts visible to the authenticated party. A preapproval allows Canton Coin transfers to settle atomically without requiring the receiver to accept each transfer individually.

## Request

```proto theme={null}
message GetPreapprovalsRequest {}
```

## Response

<ParamField type="PreapprovalInfo[]">
  Each entry describes an active preapproval: contract ID, provider party, receiver party, and expiry metadata.
</ParamField>

## Example

```bash theme={null}
grpcurl orderbook-devnet.silvana.dev:443 \
  silvana.ledger.v1.DAppProviderService/GetPreapprovals
```

## See also

* [`RequestPreapproval`](/agentic-api/preapproval/request-preapproval) — create a new `TransferPreapproval` for the authenticated party.
* [`TransferCc`](/agentic-api/transfer/transfer-cc) — CC transfers to a receiver with an active preapproval settle atomically instead of creating a `TransferOffer`.


# RequestPreapproval
Source: https://docs.silvana.one/agentic-api/preapproval/request-preapproval

Create a TransferPreapproval for the authenticated party

Create a `TransferPreapproval` so that future Canton Coin transfers to the authenticated party settle atomically without manual acceptance.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_REQUEST_PREAPPROVAL`
* `params.request_preapproval = RequestPreapprovalParams {}`

## Params

```proto theme={null}
message RequestPreapprovalParams {}
```

The request takes no fields — the receiver party is derived from the authenticated session.

## See also

* [`GetPreapprovals`](/agentic-api/preapproval/get-preapprovals) — verify the preapproval after submission.
* [`TransferCc`](/agentic-api/transfer/transfer-cc) — Canton Coin transfers to a party with an active preapproval settle atomically.


# RequestRecurringPayasyougo
Source: https://docs.silvana.one/agentic-api/recurring/request-recurring-payasyougo

Create a pay-as-you-go recurring payment agreement

Create a pay-as-you-go recurring payment agreement with an app party. Unlike the prepaid variant, no funds are locked upfront — charges are pulled as they occur, up to the agreed amount per cycle.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_REQUEST_RECURRING_PAYASYOUGO`
* `params.request_recurring_payasyougo = RequestRecurringPayasyougoParams { … }`

## Params

<ParamField type="string">
  Party ID of the app receiving the recurring payments.
</ParamField>

<ParamField type="string">
  Amount charged per cycle.
</ParamField>

<ParamField type="string (optional)">
  Human-readable description.
</ParamField>

<ParamField type="string (optional)">
  Client-supplied reference.
</ParamField>

```proto theme={null}
message RequestRecurringPayasyougoParams {
  string app_party  = 1;
  string amount     = 2;
  optional string description = 3;
  optional string reference   = 4;
}
```

## See also

* [`RequestRecurringPrepaid`](/agentic-api/recurring/request-recurring-prepaid) — prepaid variant that locks funds upfront.
* [`GetAgentConfig`](/agentic-api/onboarding/get-agent-config) — read `subscription_app_party` and `recurring_payment_package_name`.


# RequestRecurringPrepaid
Source: https://docs.silvana.one/agentic-api/recurring/request-recurring-prepaid

Create a prepaid recurring payment subscription

Create a prepaid recurring payment agreement with an app party. The client locks funds upfront for a fixed period, enabling subsequent pay-outs without additional on-chain approvals.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_REQUEST_RECURRING_PREPAID`
* `params.request_recurring_prepaid = RequestRecurringPrepaidParams { … }`

## Params

<ParamField type="string">
  Party ID of the app receiving the recurring payments.
</ParamField>

<ParamField type="string">
  Payment amount per cycle.
</ParamField>

<ParamField type="string">
  Amount of Canton Coin locked upfront as prepayment.
</ParamField>

<ParamField type="uint32">
  How many days the prepayment remains locked.
</ParamField>

<ParamField type="string">
  Maximum total amount the app can draw over the lifetime of the agreement.
</ParamField>

<ParamField type="string (optional)">
  Human-readable description.
</ParamField>

<ParamField type="string (optional)">
  Client-supplied reference.
</ParamField>

```proto theme={null}
message RequestRecurringPrepaidParams {
  string app_party    = 1;
  string amount       = 2;
  string locked_amount = 3;
  uint32 lock_days    = 4;
  optional string description = 5;
  optional string reference   = 6;
  string limit        = 7;
}
```

## See also

* [`RequestRecurringPayasyougo`](/agentic-api/recurring/request-recurring-payasyougo) — alternative flow with no upfront lock.
* [`GetAmulets`](/agentic-api/core/get-amulets) — pick amulets that satisfy `locked_amount`.
* [`GetAgentConfig`](/agentic-api/onboarding/get-agent-config) — read `subscription_app_party` and `recurring_payment_package_name` for the provider's recurring-payment setup.


# Transaction flow
Source: https://docs.silvana.one/agentic-api/transaction-flow

Two-phase prepare → sign → execute model

Every state-changing operation in the Silvana Ledger service uses a **two-phase** transaction model. This guarantees that the private key never leaves the client, and that the server never submits anything the agent has not explicitly authorised.

## Phases

<Steps>
  <Step title="Prepare">
    The client calls `PrepareTransaction` with a [`TransactionOperation`](#transactionoperation) enum value and a matching `params` oneof. The server builds the Canton transaction, returns its hash (`prepared_transaction_hash`), the serialized `prepared_transaction`, a `transaction_id`, and a `TrafficEstimate`.
  </Step>

  <Step title="Sign">
    The client signs `prepared_transaction_hash` with the agent's Ed25519 private key — see [Authentication](/agentic-api/authentication) for details on how signatures are carried.
  </Step>

  <Step title="Execute">
    The client calls `ExecuteTransaction` with `transaction_id` and the hex-encoded signature. The server submits the transaction to Canton and returns the outcome — including `update_id`, `contract_id`, any newly created contracts, and the traffic actually consumed.
  </Step>
</Steps>

## TransactionOperation

The enum selects which sub-operation the server should build in phase 1:

```proto theme={null}
enum TransactionOperation {
  TRANSACTION_OPERATION_UNSPECIFIED = 0;

  // DvP settlement
  TRANSACTION_OPERATION_PAY_DVP_FEE   = 1;
  TRANSACTION_OPERATION_PROPOSE_DVP   = 2;
  TRANSACTION_OPERATION_ACCEPT_DVP    = 3;
  TRANSACTION_OPERATION_PAY_ALLOC_FEE = 4;
  TRANSACTION_OPERATION_ALLOCATE      = 5;

  // Canton Coin transfers
  TRANSACTION_OPERATION_TRANSFER_CC = 6;

  // Preapproval
  TRANSACTION_OPERATION_REQUEST_PREAPPROVAL = 7;

  // Recurring payments
  TRANSACTION_OPERATION_REQUEST_RECURRING_PREPAID    = 8;
  TRANSACTION_OPERATION_REQUEST_RECURRING_PAYASYOUGO = 9;

  // User service
  TRANSACTION_OPERATION_REQUEST_USER_SERVICE = 10;

  // CIP-56 token transfers
  TRANSACTION_OPERATION_TRANSFER_CIP56 = 11;
  TRANSACTION_OPERATION_ACCEPT_CIP56   = 12;

  // CC merge-split
  TRANSACTION_OPERATION_SPLIT_CC = 13;

  // Atomic batch via Execute_MultiCall DAR choice
  TRANSACTION_OPERATION_EXECUTE_MULTICALL = 14;
}
```

### Operations reference

Each enum value corresponds to one dedicated method page that documents its `params` message:

| Operation | `params` field | Page |
| - | - | - |
| `PAY_DVP_FEE` | `pay_fee` | [PayDvpFee](/agentic-api/dvp/pay-dvp-fee) |
| `PROPOSE_DVP` | `propose_dvp` | [ProposeDvp](/agentic-api/dvp/propose-dvp) |
| `ACCEPT_DVP` | `accept_dvp` | [AcceptDvp](/agentic-api/dvp/accept-dvp) |
| `PAY_ALLOC_FEE` | `pay_fee` | [PayAllocFee](/agentic-api/dvp/pay-alloc-fee) |
| `ALLOCATE` | `allocate` | [Allocate](/agentic-api/dvp/allocate) |
| `TRANSFER_CC` | `transfer_cc` | [TransferCc](/agentic-api/transfer/transfer-cc) |
| `SPLIT_CC` | `split_cc` | [SplitCc](/agentic-api/transfer/split-cc) |
| `REQUEST_PREAPPROVAL` | `request_preapproval` | [RequestPreapproval](/agentic-api/preapproval/request-preapproval) |
| `TRANSFER_CIP56` | `transfer_cip56` | [TransferCip56](/agentic-api/cip56/transfer-cip56) |
| `ACCEPT_CIP56` | `accept_cip56` | [AcceptCip56](/agentic-api/cip56/accept-cip56) |
| `REQUEST_RECURRING_PREPAID` | `request_recurring_prepaid` | [RequestRecurringPrepaid](/agentic-api/recurring/request-recurring-prepaid) |
| `REQUEST_RECURRING_PAYASYOUGO` | `request_recurring_payasyougo` | [RequestRecurringPayasyougo](/agentic-api/recurring/request-recurring-payasyougo) |
| `REQUEST_USER_SERVICE` | `request_user_service` | [RequestUserService](/agentic-api/user-service/request-user-service) |
| `EXECUTE_MULTICALL` | `execute_multicall` | [ExecuteMultiCall](/agentic-api/multicall/execute-multicall) |

## PrepareTransactionRequest

```proto theme={null}
message PrepareTransactionRequest {
  TransactionOperation operation = 1;

  oneof params {
    PayFeeParams                       pay_fee                        = 10;
    ProposeDvpParams                   propose_dvp                    = 11;
    AcceptDvpParams                    accept_dvp                     = 12;
    AllocateParams                     allocate                       = 13;
    TransferCcParams                   transfer_cc                    = 14;
    RequestPreapprovalParams           request_preapproval            = 15;
    RequestRecurringPrepaidParams      request_recurring_prepaid      = 16;
    RequestRecurringPayasyougoParams   request_recurring_payasyougo   = 17;
    RequestUserServiceParams           request_user_service           = 18;
    TransferCip56Params                transfer_cip56                 = 19;
    AcceptCip56Params                  accept_cip56                   = 20;
    SplitCcParams                      split_cc                       = 21;
    ExecuteMultiCallParams             execute_multicall              = 22;
  }

  MessageSignature request_signature = 30;
}
```

## PrepareTransactionResponse

<ParamField type="string">
  Opaque server-assigned ID. Pass this into `ExecuteTransaction`.
</ParamField>

<ParamField type="string">
  Hex-encoded Canton transaction hash. **This is what the agent must sign.**
</ParamField>

<ParamField type="string">
  Canton command ID used for idempotency.
</ParamField>

<ParamField type="bytes">
  Serialised prepared transaction (for deterministic re-hashing if desired).
</ParamField>

<ParamField type="string">
  Canton hashing scheme version used to compute the hash.
</ParamField>

<ParamField type="TrafficEstimate">
  Estimated Canton traffic (`read_cost`, `write_cost`, `total_cost`) the transaction will consume.
</ParamField>

<ParamField type="MessageSignature">
  Provider signature over the response payload — see [Authentication](/agentic-api/authentication#messagesignature).
</ParamField>

<ParamField type="TransactionStatus">
  Always `PENDING` after prepare.
</ParamField>

## ExecuteTransactionRequest

<ParamField type="string">
  Value returned from `PrepareTransaction`.
</ParamField>

<ParamField type="string">
  Hex-encoded Ed25519 signature over `prepared_transaction_hash`.
</ParamField>

<ParamField type="MessageSignature">
  Message-level signature from the cloud agent — see [Authentication](/agentic-api/authentication#messagesignature).
</ParamField>

## ExecuteTransactionResponse

<ParamField type="bool">
  `true` if the transaction was submitted and committed successfully.
</ParamField>

<ParamField type="string">
  Canton update ID of the committed transaction.
</ParamField>

<ParamField type="string (optional)">
  Primary contract created by the transaction (if any).
</ParamField>

<ParamField type="CreatedContractInfo[]">
  All contracts created by the transaction — useful for tracking new amulets from change/split.
</ParamField>

<ParamField type="TrafficEstimate">
  Actual traffic consumed.
</ParamField>

<ParamField type="string (optional)">
  Featured-app rewards earned, if applicable.
</ParamField>

<ParamField type="uint64 (optional)">
  Mining round in which rewards were earned.
</ParamField>

<ParamField type="string (optional)">
  Human-readable error.
</ParamField>

<ParamField type="ProviderError (optional)">
  Structured error (`ProviderRpcError`) when `success = false`.
</ParamField>

<ParamField type="TransactionStatus">
  `EXECUTED` on success, `FAILED` on error.
</ParamField>


# SplitCc
Source: https://docs.silvana.one/agentic-api/transfer/split-cc

Split Canton Coin amulets via AmuletRules_Transfer (MergeSplit)

Split one or more Canton Coin amulets into new amulets with specified denominations. Uses the `AmuletRules_Transfer` MergeSplit operation under the hood.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_SPLIT_CC`
* `params.split_cc = SplitCcParams { … }`

## Params

<ParamField type="string[]">
  Decimal amounts for the output amulets. Sum must be less than or equal to the total input.
</ParamField>

<ParamField type="string[]">
  Contract IDs of the input amulets to be merged and split.
</ParamField>

```proto theme={null}
message SplitCcParams {
  repeated string output_amounts = 1;
  repeated string amulet_cids    = 2;
}
```

<Tip>
  Call [`GetAmulets`](/agentic-api/core/get-amulets) first to discover the input `amulet_cids` and their amounts.
</Tip>

## See also

* [`GetAmulets`](/agentic-api/core/get-amulets) — list the unlocked amulets you can merge.
* [`TransferCc`](/agentic-api/transfer/transfer-cc) — send Canton Coin to a receiver (may be combined with split in a [`MultiCall`](/agentic-api/multicall/execute-multicall)).


# TransferCc
Source: https://docs.silvana.one/agentic-api/transfer/transfer-cc

Transfer Canton Coin to a receiver

Transfer Canton Coin to a receiver. If the receiver has an existing `TransferPreapproval`, the transfer settles atomically. Otherwise the transaction creates a `TransferOffer` that the receiver must accept.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_TRANSFER_CC`
* `params.transfer_cc = TransferCcParams { … }`

## Params

<ParamField type="string">
  Canton party ID of the receiver.
</ParamField>

<ParamField type="string">
  Decimal amount of Canton Coin to transfer.
</ParamField>

<ParamField type="string (optional)">
  Human-readable description attached to the transfer.
</ParamField>

<ParamField type="string">
  Client-generated command ID for idempotency.
</ParamField>

<ParamField type="string (optional)">
  Link this transfer to an existing settlement proposal.
</ParamField>

<ParamField type="string[]">
  Explicit amulet contract IDs to consume. If omitted, the server selects amulets automatically.
</ParamField>

```proto theme={null}
message TransferCcParams {
  string receiver_party = 1;
  string amount = 2;
  optional string description = 3;
  string command_id = 4;
  optional string settlement_proposal_id = 5;
  repeated string amulet_cids = 6;
}
```

<Tip>
  Call [`GetAmulets`](/agentic-api/core/get-amulets) first if you need to pre-select amulets for deterministic fee calculation.
</Tip>

## See also

* [`GetPreapprovals`](/agentic-api/preapproval/get-preapprovals) — check whether the receiver has an active `TransferPreapproval` (which makes this transfer settle atomically).
* [`RequestPreapproval`](/agentic-api/preapproval/request-preapproval) — create a preapproval for the authenticated party.
* [`SplitCc`](/agentic-api/transfer/split-cc) — reshape amulet denominations before transferring.
* [`ExecuteMultiCall`](/agentic-api/multicall/execute-multicall) — bundle a transfer with other operations atomically.


# RequestUserService
Source: https://docs.silvana.one/agentic-api/user-service/request-user-service

Request a user-scoped service from the provider

Create a `UserService` request — a generic mechanism for provider-defined user flows (onboarding, KYC, feature activation, etc.). The semantics of `reference_id` and `party_name` are provider-specific.

Invoked through the two-phase [transaction flow](/agentic-api/transaction-flow) with:

* `operation = TRANSACTION_OPERATION_REQUEST_USER_SERVICE`
* `params.request_user_service = RequestUserServiceParams { … }`

## Params

<ParamField type="string (optional)">
  Provider-defined reference ID.
</ParamField>

<ParamField type="string (optional)">
  Human-readable party name.
</ParamField>

```proto theme={null}
message RequestUserServiceParams {
  optional string reference_id = 1;
  optional string party_name   = 2;
}
```

## See also

* [`GetAgentConfig`](/agentic-api/onboarding/get-agent-config) — discover provider-specific parameters that govern user-service flows.
* [`GetServiceInfo`](/agentic-api/core/get-service-info) — confirm that the `user_service` group is enabled.
* [Transaction flow](/agentic-api/transaction-flow) — two-phase model this call uses.


# Cloud Agents
Source: https://docs.silvana.one/guides/agents/cloud



Silvana Book Agent can run on self-hosted infrastructure or in a managed cloud environment. The agent communicates with Silvana through a gRPC service, signs transactions locally, and never transmits the private key to the server.

Silvana Book Agents is not tied to a specific cloud provider:

| Environment | Where it can run |
| - | - |
| **Local / self-hosted** | <ul><li>Developer machine</li><li>VM</li><li>Your own server</li></ul> |
| **Cloud infrastructure** | <ul><li>Any environment capable of running the `cloud-agent` binary</li><li>Infrastructure and deployment are managed by the developer</li></ul> |

<Warning>
  Google Cloud deployment is coming soon. Until then, Silvana Book Agent can be deployed on self-hosted infrastructure
</Warning>

<Note>
  The following links are **necessary** for developers to access the protocol, library interface, and reference implementation:

  * [**Proto specification**](https://github.com/SilvanaOne/silvana-book-agent/tree/main/proto/silvana)
  * [**Agent code repository**](https://github.com/SilvanaOne/silvana-book-agent)
  * [Silvana Book Agent README](https://github.com/SilvanaOne/silvana-book-agent/blob/main/README.md)
</Note>

# Launch Cloud Agent

Use Silvana Book Agent as a starting point, or extend its Rust libraries to build custom agent logic.

<Note>
  Before continuing, complete [onboarding](/guides/quickstart/onboarding). The guide covers installing `cloud-agent`, onboarding your agent, and checking the initial setup.
</Note>

<Steps>
  <Step title="Configure the agent">
    Onboarding creates a starter `agent.toml` automatically.

    Update it with the markets and runtime settings your workflow needs.

    <Check>
      For custom implementations, you can use the Silvana Book Agent Rust crates and extend the agent logic for your use case.
    </Check>
  </Step>

  <Step title="Test the workflow">
    For the long-running Silvana Book Agent mode, use `--dry-run` to test the configuration without signing or executing transactions:

    ```bash theme={null}
    cloud-agent agent --dry-run
    ```

    Check that the agent loads the expected configuration and processes the workflow as intended before enabling execution.
  </Step>

  <Step title="Run the agent">
    Once the configuration is ready, start the long-running agent:

    ```bash theme={null}
    cloud-agent agent
    ```

    In this mode, Silvana Book Agent places grid orders on configured markets, responds to incoming RFQs, and handles DvP settlement.

    If you built a custom agent with the SDK, run your implementation using its own entry point.
  </Step>
</Steps>

## Developer reference

Silvana Book Agent communicates with the orderbook server through four gRPC services defined under `proto/silvana/*/v1/*.proto`.

| **Service** | **Purpose** |
| - | - |
| `DAppProviderService` | Transaction signing, balance, and contract queries |
| `SettlementService` | DvP settlement orchestration and RFQ handling |
| `OrderbookService` | Order submission, market data, and RFQ initiation |
| `PricingService` | External price feeds |

## Read More

<CardGroup>
  <Card title="Launch Your First Agent" href="/guides/quickstart/how-to-deploy">
    Follow the full path from setup to a running agent.
  </Card>

  <Card title="Agent Onboarding" href="/guides/quickstart/agent-onboarding">
    Create your agent identity and initial configuration.
  </Card>

  <Card title="Provide Liquidity" href="/guides/trading/how-to-provide-liquidity">
    Run a long-lived agent for grid orders, RFQs, and settlement.
  </Card>

  <Card title="How to Start" href="/guides/quickstart/how-to-start">
    Explore the main developer paths and choose where to begin.
  </Card>
</CardGroup>


# Agent Onboarding
Source: https://docs.silvana.one/guides/quickstart/agent-onboarding



Set up your Silvana Book Agent and connect it to the orderbook in just a few steps.

You’ll need an invite code to complete onboarding. We provide the code directly as part of the onboarding process.

## Onboard your agent

<Steps>
  <Step title="Install the CLI">
    <Tabs>
      <Tab title="Prebuilt binary">
        Download the latest `cloud-agent` binary from the [GitHub Releases page](https://github.com/SilvanaOne/silvana-book-agent/releases/latest).

        | Platform | Archive |
        | - | - |
        | macOS Apple Silicon | `cloud-agent-macos-silicon.tar.gz` |
        | Linux x86\_64 | `cloud-agent-x86_64-linux.tar.gz` |
        | Linux ARM64 | `cloud-agent-arm64-linux.tar.gz` |

        <Accordion title="macOS Apple Silicon example">
          ```bash theme={null}
          curl -LO https://github.com/SilvanaOne/silvana-book-agent/releases/latest/download/cloud-agent-macos-silicon.tar.gz
          tar -xzf cloud-agent-macos-silicon.tar.gz
          chmod +x cloud-agent
          ./cloud-agent --help
          ```
        </Accordion>

        Checksums for all archives are available in `checksums.txt` on the release page.
      </Tab>

      <Tab title="Build from source">
        Build the CLI from the repository root:

        ```bash theme={null}
        cargo build --release -p cli
        ```

        The compiled binary is available at:

        ```bash theme={null}
        target/release/cloud-agent
        ```
      </Tab>
    </Tabs>
  </Step>

  <Step title="Run onboarding">
    Run the onboarding command with your agent name, email, and invite code:

    ```bash theme={null}
    cloud-agent onboard \
      --agent-name my-agent \
      --email me@example.com \
      --invite-code INVITE1
    ```

    <Note>
      The DevNet RPC is used by default. Use `--rpc <URL>` only when connecting to another endpoint.
    </Note>
  </Step>

  <Step title="Complete the setup">
    During onboarding, the agent creates its identity, registers with Silvana, completes the required Canton setup, and creates the required preapprovals.

    On successful onboarding, two files are created in the current directory:

    * `.env` — agent identity, keys, and network configuration
    * `agent.toml` — starter configuration for the agent

    On DevNet, initial CC and USDC balances are also provided automatically.
  </Step>

  <Step title="Check your balance">
    Confirm that the agent is ready:

    ```bash theme={null}
    cloud-agent info balance
    ```

    <Check>
      Once onboarding is complete, you can configure the agent for trading or liquidity provision.
    </Check>
  </Step>
</Steps>

## Read More

<CardGroup>
  <Card title="How to Start" href="/guides/quickstart/how-to-start">
    Explore the main paths and developer resources available in Silvana.
  </Card>

  <Card title="Launch Your First Agent" href="/guides/quickstart/how-to-deploy">
    Move from onboarding to configuring and running your first agent.
  </Card>

  <Card title="Buy & Sell Assets" href="/guides/trading/how-to-buy-and-sell-assets">
    Use your onboarded agent to execute buy and sell flows.
  </Card>

  <Card title="Cloud Agents" href="/guides/agents/cloud">
    Learn how to run the Silvana Book Agent on your own infrastructure.
  </Card>
</CardGroup>


# How to Launch Your First Agent
Source: https://docs.silvana.one/guides/quickstart/how-to-deploy



On Silvana, agents can apply defined logic to asset operations, coordinate settlement, and automate multi-step financial processes while remaining within configured execution rules.

This guide shows how to take an agent from initial setup to a working Silvana workflow, whether you start from an existing implementation or adapt one to your own use case.

<Tabs>
  <Tab title="Agent Space">
    Start with an existing implementation from [Agent Space](https://app.silvana.one/agents).

    <Steps>
      <Step title="Choose an agent">
        Open Agent Space and choose an agent that matches your workflow.

        <img alt="Agent Calalog" />
      </Step>

      <Step title="Explore the implementation">
        Open the agent details, review the available implementation, and test the demo when provided.

        <img alt="Agent Catalog2" />
      </Step>

      <Step title="Adapt it to your workflow">
        Copy the implementation and adjust its configuration or logic for your use case.

        Once ready, run the agent on your infrastructure.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Build Your Own">
    Use Silvana Book Agent as a starting point, or extend its Rust libraries to build custom agent logic.

    <Note>
      Before continuing, complete [onboarding](/guides/quickstart/onboarding). The guide covers installing `cloud-agent`, onboarding your agent, and checking the initial setup.
    </Note>

    <Steps>
      <Step title="Configure the agent">
        Onboarding creates a starter `agent.toml` automatically.

        Update it with the markets and runtime settings your workflow needs.

        <Check>
          For custom implementations, you can use the Silvana Book Agent Rust crates and extend the agent logic for your use case.
        </Check>
      </Step>

      <Step title="Test the workflow">
        For the long-running Silvana Book Agent mode, use `--dry-run` to test the configuration without signing or executing transactions:

        ```bash theme={null}
        cloud-agent agent --dry-run
        ```

        Check that the agent loads the expected configuration and processes the workflow as intended before enabling execution.
      </Step>

      <Step title="Run the agent">
        Once the configuration is ready, start the long-running agent:

        ```bash theme={null}
        cloud-agent agent
        ```

        In this mode, Silvana Book Agent places grid orders on configured markets, responds to incoming RFQs, and handles DvP settlement.

        If you built a custom agent with the SDK, run your implementation using its own entry point.
      </Step>
    </Steps>
  </Tab>
</Tabs>

<Note>
  For additional configuration options, CLI flags, and implementation details, see the Silvana Book Agent [README](https://github.com/SilvanaOne/silvana-book-agent/blob/main/README.md).
</Note>

## Read More

<CardGroup>
  <Card title="Agent Onboarding" href="/guides/quickstart/agent-onboarding">
    Complete the initial setup before configuring your agent workflow.
  </Card>

  <Card title="Cloud Agents" href="/guides/agents/cloud">
    Explore deployment options for running Silvana Book Agent.
  </Card>

  <Card title="Provide Liquidity" href="/guides/trading/how-to-provide-liquidity">
    Configure an agent for grid orders, RFQs, and settlement.
  </Card>

  <Card title="Buy & Sell Assets" href="/guides/trading/how-to-buy-and-sell-assets">
    Run direct taker execution flows through the CLI.
  </Card>
</CardGroup>


# How to Start
Source: https://docs.silvana.one/guides/quickstart/how-to-start



You can start building with Silvana in more than one place: launch an existing agent, work with Silvana Book Agent, build custom logic with the SDK, or connect directly through APIs.

You don’t need to learn the whole stack first. Start with the path that matches what you want to build and go deeper when you need it.

<Card title="Onbooard Your Agent" icon="rocket" href="/guides/quickstart/agent-onboarding">
  New to Silvana? Start with onboarding to install `cloud-agent`, create your agent identity, and prepare the initial configuration.
</Card>

## Start Building with Silvana

Choose the path that fits your workflow. Each page below takes you directly to the tools and documentation you need.

<CardGroup>
  <Card title="Launch Your First Agent" icon="play" href="/guides/quickstart/how-to-deploy">
    Move from setup to a running agent using an existing Agent Space implementation or your own logic.

    * Choose your development path
    * Configure, test, and run the agent
  </Card>

  <Card title="Silvana Book Agent" icon="robot" href="/sdk/silvana-book-agent">
    Learn how the cloud agent works and how it connects trading, RFQ, and settlement workflows.

    * Understand the agent runtime
    * Explore CLI and library capabilities
  </Card>

  <Card title="SDK Intro" icon="code" href="/sdk/introduction/sdk-intro">
    Build custom agents with the same Rust libraries Silvana Book Agent uses.

    * Reuse execution components
    * Build custom agent workflows
  </Card>

  <Card title="Agentic API" icon="plug" href="/agentic-api/intro">
    Connect your application or agent through the Agentic API and start building execution workflows.

    * Set up your integration
    * Move from API access to execution
  </Card>

  <Card title="Agent Sample" icon="flask" href="/sdk/introduction/agent-sample">
    Start from a working implementation and see how the main SDK components fit together.

    * Explore a practical example
    * Adapt the flow to your own logic
  </Card>

  <Card title="gRPC API" icon="server" href="/sdk/grpc-api/grpc-api-types">
    Explore the services and types behind orderbook, settlement, pricing, and ledger operations.

    * Understand the core gRPC types
    * Navigate the available services
  </Card>
</CardGroup>

## Essential Reference

Keep these pages close once you move beyond the first setup.

<CardGroup>
  <Card title="Configuration" icon="gear" href="/sdk/reference/configuration">
    Configure markets, runtime behavior, and agent settings through `.env` and `agent.toml`.
  </Card>

  <Card title="Full CLI Reference" icon="terminal" href="/sdk/reference/full-cli-reference">
    Find the available `cloud-agent` commands, options, and execution flags in one place.
  </Card>

  <Card title="Authentication & Signing" icon="key" href="/sdk/reference/authentication-and-signature">
    Understand authentication, local signing, and how agent requests are authorized.
  </Card>

  <Card title="Security Model" icon="shield" href="/sdk/reference/security-model">
    Learn how transaction verification, local keys, and two-phase signing protect agent execution.
  </Card>
</CardGroup>


# How to Buy & Sell Assets
Source: https://docs.silvana.one/guides/trading/how-to-buy-and-sell-assets



Silvana Book Agent provides `buy` and `sell` commands for taker execution through RFQ. Each accepted quote is settled atomically, and larger trades can be split across multiple settlement rounds until the requested amount is filled.

## Before you start

<Check>
  Complete [agent onboarding](/guides/quickstart/onboarding) first to set up your agent, create the required configuration, and confirm that everything is ready to use.
</Check>

## Buy and Sell via CLI

<Tabs>
  <Tab title="Buy">
    <Steps>
      <Step title="Choose a market">
        Use the market ID for the asset pair you want to trade, for example, `CC-USDC`.

        The `--amount` value represents the total amount of the base instrument you want to buy.
      </Step>

      <Step title="Run the buy command">
        ```bash theme={null}
        cloud-agent buy --market CC-USDC --amount 15
        ```

        The agent requests quotes, accepts an eligible quote, and settles it atomically. If the agent can't fill the full amount in one round, the process continues until it fills the requested amount.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Sell">
    <Steps>
      <Step title="Choose a market">
        Use the market ID for the asset pair you want to trade, for example `CC-USDC`.

        The `--amount` value represents the total amount of the base instrument you want to sell.
      </Step>

      <Step title="Run the sell command">
        ```bash theme={null}
        cloud-agent sell --market CC-USDC --amount 100
        ```

        The sell flow uses the same RFQ fill loop and can split the total amount across multiple settlement rounds.
      </Step>
    </Steps>
  </Tab>
</Tabs>

## Execution controls

Both `buy` and `sell` support the following options:

| Flag | Description |
| - | - |
| `--market <ID>` | Market ID, for example `CC-USDC` |
| `--amount <N>` | Total amount of the base instrument to fill |
| `--price-limit <N>` | Maximum buy price or minimum sell price per unit |
| `--min-settlement <N>` | Minimum size for an individual settlement |
| `--max-settlement <N>` | Maximum size for an individual settlement |
| `--interval <SECS>` | Retry interval when no quote is available |

<Accordion title="Examples">
  For example, to buy 10 CC in settlement chunks between `0.5` and `5.0`:

  ```bash theme={null}
  cloud-agent buy --market CC-USDC --amount 10 \
    --min-settlement 0.5 \
    --max-settlement 5.0 \
    --interval 60
  ```

  To sell with a minimum acceptable price:

  ```bash theme={null}
  cloud-agent sell --market CC-USDC --amount 10 \
    --price-limit 0.14
  ```
</Accordion>

## Read More

<CardGroup>
  <Card title="Agent Onboarding" href="/guides/quickstart/agent-onboarding">
    Set up your agent before running trading commands.
  </Card>

  <Card title="Provide Liquidity" href="/guides/trading/how-to-provide-liquidity">
    Move beyond taker execution and start providing liquidity.
  </Card>

  <Card title="Grid Mode" href="/guides/trading/how-to-trade-in-the-grid-mode">
    Configure automated bid and offer levels around the market.
  </Card>

  <Card title="Launch Your First Agent" href="/guides/quickstart/how-to-deploy">
    Learn how to configure, test, and run a long-running agent.
  </Card>
</CardGroup>


# How to Provide Liquidity
Source: https://docs.silvana.one/guides/trading/how-to-provide-liquidity



Silvana Book Agent can run as a long-running liquidity provider, placing grid orders, responding to RFQs, and coordinating DvP settlement.

The agent communicates with Silvana through gRPC, while transactions are verified and signed locally.

## Liquidity modes

Silvana Book Agent supports two liquidity modes:

* **Grid orders** — place limit orders at configured levels around the current mid price.
* **RFQ (Request for Quote)** — respond to incoming quote requests using configured spreads and size limits.

Both are configured through `agent.toml`.

## Before you start

<Check>
  Complete [agent onboarding](/guides/quickstart/onboarding) first to set up your agent, create the required configuration, and confirm that everything is ready to use.
</Check>

# Configure liquidity

Choose the liquidity mode you want to configure. Both modes use `agent.toml`.

<Tabs>
  <Tab title="Grid Orders">
    Grid orders place bids and offers at configured levels around the current mid price.

    <Steps>
      <Step title="Add a market">
        Add an enabled market to `agent.toml`:

        ```toml theme={null}
        [[markets]]
        market_id = "CC-USDC"
        enabled = true
        price_change_threshold_percent = 0.1
        ```

        `price_change_threshold_percent` defines how far the mid price must move before the grid is cancelled and rebuilt.
      </Step>

      <Step title="Add bid levels">
        Bids are placed below the mid price, so `delta_percent` uses negative values.

        ```toml theme={null}
        [[markets.bid_levels]]
        delta_percent = -0.015
        quantity = "10"

        [[markets.bid_levels]]
        delta_percent = -0.2
        quantity = "10"

        [[markets.bid_levels]]
        delta_percent = -0.3
        quantity = "10"
        ```
      </Step>

      <Step title="Add offer levels">
        Offers are placed above the mid price, so `delta_percent` uses positive values.

        ```toml theme={null}
        [[markets.offer_levels]]
        delta_percent = 0.015
        quantity = "10"

        [[markets.offer_levels]]
        delta_percent = 0.2
        quantity = "10"

        [[markets.offer_levels]]
        delta_percent = 0.3
        quantity = "10"
        ```

        `quantity` defines the order size at each level.
      </Step>
    </Steps>

    When the mid price moves by more than `price_change_threshold_percent`, the agent cancels the current grid and places new orders at updated levels.
  </Tab>

  <Tab title="RFQ">
    RFQ mode lets the agent respond to incoming quote requests for configured markets.

    <Steps>
      <Step title="Configure the liquidity provider">
        Add the liquidity provider settings to `agent.toml`:

        ```toml theme={null}
        [liquidity_provider]
        name = "My LP"
        max_concurrent_rfqs = 10
        default_quote_valid_secs = 60
        ```

        `max_concurrent_rfqs` limits how many RFQs can be handled at the same time.
      </Step>

      <Step title="Enable RFQ for the market">
        Add RFQ settings under the relevant market:

        ```toml theme={null}
        [markets.rfq]
        enabled = true
        min_quantity = "5"
        max_quantity = "1000"
        bid_spread_percent = 0.5
        offer_spread_percent = 0.5
        quote_valid_secs = 60
        allocate_before_secs = 900
        settle_before_secs = 1800
        ```

        `min_quantity` and `max_quantity` define the supported RFQ range.

        `bid_spread_percent` and `offer_spread_percent` control quote pricing around the current mid price.
      </Step>
    </Steps>

    <AccordionGroup>
      <Accordion title="How RFQ works">
        Once RFQ is enabled, the agent receives quote requests for the configured market, calculates a price from the current mid price and spread, checks quantity limits and available balance, and returns a quote or rejection.
      </Accordion>

      <Accordion title="When an RFQ is rejected">
        <Warning>
          An RFQ can be rejected when:

          * the market is disabled or not configured;
          * RFQ is disabled for the market;
          * the quantity is outside `min_quantity` or `max_quantity`;
          * no mid price is available yet;
          * the agent has insufficient balance.
        </Warning>
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>

## RFQ behavior

<AccordionGroup>
  <Accordion title="How RFQ works">
    Once RFQ is enabled, the agent receives quote requests for the configured market, calculates a price from the current mid price and spread, checks quantity limits and available balance, and returns a quote or rejection.
  </Accordion>

  <Accordion title="When an RFQ is rejected">
    <Warning>
      An RFQ can be rejected when:

      * the market is disabled or not configured;
      * RFQ is disabled for the market;
      * the quantity is outside `min_quantity` or `max_quantity`;
      * no mid price is available yet;
      * the agent has insufficient balance.
    </Warning>
  </Accordion>
</AccordionGroup>

## Agent options

Use these flags when you need more control over agent execution:

| Flag | Description |
| - | - |
| `--orders-only` | Place and manage grid orders without settlement |
| `--settlement-only` | Process settlement without placing grid orders |
| `--dry-run` | Prepare and verify transactions without signing or executing them |
| `--confirm` | Ask for confirmation before signing each transaction |
| `--verbose` | Enable detailed logging |
| `--config <PATH>` | Use a specific `agent.toml` file |

Start with `--dry-run` when testing new grid levels, spreads, or thresholds.

## Operational tips

* Keep enough CC available for `AGENT_FEE_RESERVE_CC` and transaction fees.
* Check balances with `cloud-agent info balance`.
* Use `price_change_threshold_percent` to control how often the grid is refreshed.
* Use `max_concurrent_rfqs` to control parallel RFQ exposure.
* Restart the agent after changing `agent.toml`.

## Read More

<CardGroup>
  <Card title="Grid Mode" href="/guides/trading/how-to-trade-in-the-grid-mode">
    Configure grid levels and automate order placement around the mid price.
  </Card>

  <Card title="Buy & Sell Assets" href="/guides/trading/how-to-buy-and-sell-assets">
    Explore direct taker execution through the CLI.
  </Card>

  <Card title="Launch Your First Agent" href="/guides/quickstart/how-to-deploy">
    Set up and run a long-running agent workflow.
  </Card>

  <Card title="Agent Onboarding" href="/guides/quickstart/agent-onboarding">
    Complete the required setup before running liquidity workflows.
  </Card>
</CardGroup>


# How to Trade in Grid Mode
Source: https://docs.silvana.one/guides/trading/how-to-trade-in-the-grid-mode



Grid mode places limit orders at configured levels around the current mid price. The agent manages the grid automatically and rebuilds it when the market moves beyond the configured threshold.

<Callout icon="info">
  Bids are placed below the mid price using negative offsets, while offers are placed above it using positive offsets.
</Callout>

## Before you start

<Note>
  Complete [agent onboarding](/guides/quickstart/onboarding) first. It covers installing `cloud-agent`, setting up your agent identity, and creating the initial `.env` and `agent.toml` files.
</Note>

## Configure grid mode

<Steps>
  <Step title="Set the agent configuration">
    Open the `agent.toml` created during onboarding and check the main agent settings:

    ```toml theme={null}
    role = "trader"
    auto_settle = true
    poll_interval_secs = 7
    rfq_v2_only = false
    ```

    Keep `rfq_v2_only = false` when using grid orders.
  </Step>

  <Step title="Add a market">
    Add the market where you want the agent to place grid orders:

    ```toml theme={null}
    [[markets]]
    market_id = "CC-USDC"
    enabled = true
    price_change_threshold_percent = 0.1
    ```

    <Tip>
      `price_change_threshold_percent` defines how far the mid price must move before the current grid is canceled and rebuilt at updated levels.
    </Tip>
  </Step>

  <Step title="Add bid levels">
    Configure bids below the current mid price using negative `delta_percent` values:

    ```toml theme={null}
    [[markets.bid_levels]]
    delta_percent = -0.015
    quantity = "10"

    [[markets.bid_levels]]
    delta_percent = -0.2
    quantity = "10"

    [[markets.bid_levels]]
    delta_percent = -0.3
    quantity = "10"
    ```

    Each `quantity` defines the order size for that level.
  </Step>

  <Step title="Add offer levels">
    Configure offers above the current mid price using positive `delta_percent` values:

    ```toml theme={null}
    [[markets.offer_levels]]
    delta_percent = 0.015
    quantity = "10"

    [[markets.offer_levels]]
    delta_percent = 0.2
    quantity = "10"

    [[markets.offer_levels]]
    delta_percent = 0.3
    quantity = "10"
    ```

    Once the market and levels are configured, the grid is ready to run.
  </Step>
</Steps>

## Run the grid

Choose how you want the agent to operate:

<Tabs>
  <Tab title="Grid only">
    Run only the grid-order workflow:

    ```bash theme={null}
    cloud-agent agent --orders-only
    ```

    This mode places and manages grid orders without processing settlement.
  </Tab>

  <Tab title="Full agent">
    Run the complete long-running agent:

    ```bash theme={null}
    cloud-agent agent
    ```

    The agent manages grid orders together with settlement and any RFQ workflows configured in `agent.toml`.
  </Tab>
</Tabs>

<Warning>
  Grid orders are not placed when `rfq_v2_only = true`. The `--orders-only` option also conflicts with this setting.
</Warning>

## Test your configuration

Use `--dry-run` to prepare and verify transactions without signing or executing them:

```bash theme={null}
cloud-agent agent --orders-only --dry-run
```

Once the configuration behaves as expected, start the agent without `--dry-run`.

## Useful options

| Flag | Description |
| - | - |
| `--orders-only` | Place and manage grid orders without settlement |
| `--dry-run` | Prepare and verify transactions without signing or executing |
| `--verbose` | Enable detailed logging |
| `--config <PATH>` | Use a specific `agent.toml` file |

<Accordion title="How the grid refreshes">
  Each grid level is defined by:

  * `delta_percent` — percentage offset from the current mid price
  * `quantity` — order size at that level

  When the mid price moves by more than `price_change_threshold_percent`, the agent cancels the existing grid orders and places them again at updated price levels.
</Accordion>

<Note>
  For more advanced configuration, CLI options, and implementation details, see the [Silvana Book Agent README](https://github.com/SilvanaOne/silvana-book-agent#readme).
</Note>

## Read More

<CardGroup>
  <Card title="Provide Liquidity" href="/guides/trading/how-to-provide-liquidity">
    Explore grid orders and RFQ as part of a complete liquidity workflow.
  </Card>

  <Card title="Buy & Sell Assets" href="/guides/trading/how-to-buy-and-sell-assets">
    Execute direct buy and sell flows through `cloud-agent`.
  </Card>

  <Card title="Launch Your First Agent" href="/guides/quickstart/how-to-deploy">
    Configure, test, and run your agent from start to finish.
  </Card>

  <Card title="Agent Onboarding" href="/guides/quickstart/agent-onboarding">
    Prepare your agent and initial configuration before trading.
  </Card>
</CardGroup>


# Home
Source: https://docs.silvana.one/index

Private agentic trading infrastructure

<div>
  <div />

  <div>
    <h1>
      Unlocking the era of

      <br />

      private agentic trading
    </h1>

    <p>
      Access a private orderbook with ultra-fast off-chain matching, while keeping full asset control and completing agent-driven order flow.
    </p>

    <a href="/silvana-book/introduction/get-started/onboarding">
      <span>Get Started</span>

      <svg>
        <path />
      </svg>
    </a>
  </div>
</div>

<div>
  ## Silvana Orderbook

  <div>
    <CardGroup>
      <Card href="/silvana-book/introduction/meet-silvana-book">
        <img alt="" />

        <div>
          Meet Silvana Book
        </div>

        <p>
          Learn orderbook's solution, design, major features, and advantages.
        </p>
      </Card>

      <Card href="/silvana-book/introduction/get-started/onboarding">
        <img alt="" />

        <div>
          Onboarding
        </div>

        <p>
          Get access, pass KYC, complete verification.
        </p>
      </Card>

      <Card href="/silvana-book/introduction/earn-hub/how-to-earn">
        <img alt="" />

        <div>
          How to Earn
        </div>

        <p>
          Explore all the ways to earn points and receive rewards through your activity.
        </p>
      </Card>

      <Card>
        <img alt="" />

        <div>
          For Traders
        </div>

        <p>
          Trade privately, place orders, and manage positions efficiently.
        </p>

        <div>
          <a href="/silvana-book/introduction/terminal">
            <svg>
              <rect />

              <path />

              <path />
            </svg>

            <span>Terminal</span>
          </a>

          <a href="/silvana-book/for-traders/supported-trading-strategies">
            <svg>
              <path />
            </svg>

            <span>Supported Trading Strategies</span>
          </a>
        </div>
      </Card>

      <Card>
        <img alt="" />

        <div>
          For Liquidity Providers
        </div>

        <p>
          Provide liquidity through agents to earn rewards.
        </p>

        <div>
          <a href="/guides/trading/how-to-provide-liquidity">
            <svg>
              <path />
            </svg>

            <span>How to Provide Liquidity</span>
          </a>
        </div>
      </Card>

      <Card>
        <img alt="" />

        <div>
          For Developers
        </div>

        <p>
          Build, integrate, and automate trading with agents, APIs and SDKs.
        </p>

        <div>
          <a href="/platform/overview/matching-and-execution">
            <svg>
              <path />
            </svg>

            <span>Matching and Execution</span>
          </a>

          <a href="/platform/overview/agents">
            <svg>
              <path />
            </svg>

            <span>Orderbook Agents</span>
          </a>

          <a href="/guides/agents/how-to-deploy">
            <svg>
              <path />
            </svg>

            <span>Build your Agent</span>
          </a>
        </div>
      </Card>
    </CardGroup>
  </div>
</div>

<div>
  ## Silvana Agents

  <div>
    <CardGroup>
      <Card href="/platform/overview/agents">
        <img alt="" />

        <div>
          Agents
        </div>

        <p>
          Learn how agents operate and power execution across the Orderbook.
        </p>
      </Card>

      <Card href="/guides/agents/cloud">
        <div>
          <img alt="" />

          <div>
            Cloud Agents
          </div>

          <p>
            Run agents at scale with Silvana cloud infrastructure.
          </p>
        </div>
      </Card>

      <Card href="https://app.silvana.one/agents">
        <div>
          <img alt="" />

          <div>
            Agent Space
          </div>

          <p>
            Discover, launch, and manage agents in the Silvana app.
          </p>
        </div>
      </Card>
    </CardGroup>
  </div>
</div>

<div>
  ## Silvana Platform

  <div>
    <CardGroup>
      <Card href="https://silvana.one/">
        <img alt="" />

        <div>
          Silvana
        </div>

        <p>
          Visit Silvana website to learn about its core functions and features.
        </p>
      </Card>

      <Card href="/platform/overview/meet-silvana">
        <img alt="" />

        <div>
          Docs
        </div>

        <p>
          Make a deep dive into Silvana solution and architectural components.
        </p>
      </Card>

      <Card>
        <div>
          <img alt="" />

          <img alt="Soon" />

          <div>
            Agent App
          </div>

          <p>
            Set up and manage your agent, connect a wallet, and fund your agent’s balance from one place.
          </p>
        </div>
      </Card>
    </CardGroup>
  </div>
</div>

<div>
  ## Resources

  <div>
    <CardGroup>
      <Card>
        <img alt="" />

        <div>
          Onboarding & Access
        </div>

        <p>
          Get help with onboarding, wallets, KYC, and passkeys.
        </p>

        <div>
          <a href="/silvana-book/introduction/get-started/onboarding">
            <svg>
              <path />
            </svg>

            <span>Onboarding Guide</span>
          </a>

          <a href="/silvana-book/introduction/get-started/kyc-verification">
            <svg>
              <path />

              <path />

              <path />
            </svg>

            <span>KYC Verification</span>
          </a>

          <a href="/silvana-book/introduction/faqs">
            <svg>
              <path />

              <path />

              <path />
            </svg>

            <span>FAQs</span>
          </a>
        </div>
      </Card>

      <Card>
        <img alt="" />

        <div>
          SDK & Integration
        </div>

        <p>
          Integrate with Silvana Book using our tools for private matching and secure settlement.
        </p>

        <div>
          <a href="/sdk/introduction/silvana-book-agent">
            <svg>
              <path />
            </svg>

            <span>SDK Documentation</span>
          </a>
        </div>
      </Card>

      <Card href="/agentic-api/intro">
        <img alt="" />

        <div>
          Quick Start
        </div>

        <p>
          Start building an agent-driven execution flow with a simple end-to-end trading example.
        </p>
      </Card>
    </CardGroup>
  </div>
</div>


# Agent Space
Source: https://docs.silvana.one/platform/overview/agent-space



# Where Agents Live

[**Agent Space**](https://app.silvana.one/agents) is the home for Silvana agents built and deployed on the platform.

We provide them to cover the most common and in-demand use cases. You can also add a custom agent to the platform to cater to your needs.

At the top of the page, there's a guide to using Silvana agents.

<Frame>
  <img alt="Image" />
</Frame>

Then follows a catalog of all available agents. For some of them, templates or a demo are provided.

Some workflows require more than one agent to run. For each use case, you can see the number of agents engaged and the language in which they are written.

Start typing the agent name in the search line to access it quickly.

<Frame>
  <img alt="Image" />
</Frame>

Upon click, you can view agent details: name, group (category), description, version, language, repo link, and doc links.

<Frame>
  <img alt="Image" />
</Frame>

You can also order the development of a customized agent with us.

<Check>
  We encourage you to power the Agent Space with your own custom agents.
</Check>

# What Can Agents Do?

Silvana agents cover a wide range of use cases: trading, audit, compliance, and other execution workflows. They can monitor, prove, report, trade, trigger payments, coordinate settlement, and interact with external systems.

<Check>
  The functions covered are not limited to trading alone. There are other workflows (legal and risk compliance, audit, etc.), and this number is about to grow further!
</Check>

<AccordionGroup>
  <Accordion title="Silvana Agent Samples">
    * **pre-trade check** – validates an order (or a stream of orders) against compliance rules: notional, quantity, price band, market, and side allow/blocklists;
    * **oracle** – fetches prices for every configured market on a fixed cadence and emits one record per market per poll;
    * **killswitch** – instantly cancels every open order on demand, or trips automatically when health checks (open-order count, failed settlements) breach configured limits;
    * **watchlist** – tracks markets, streaming live prices, and orderbook depth for a configurable list of pairs;
    * **test run** – verifies connectivity, JWT, and basic queries before launching any ledger-writing agent;
    * **state monitor** – observes your orders and settlement proposals in real time;
    * **compliance screening** – applies compliance policies: blocked markets, per-party notional caps, allowed-counterparty whitelist, etc.;
    * **risk alert** – provides alerts when thresholds (open orders, failed settlements, notional caps) are breached without cancelling a transaction;
    * **batch orders** – submits multiple orders in a single transaction;
    * **portfolio rebalancing** – continuously buys or sells assets in a portfolio based on target indicators;
    * **notifier** – notifies user on events;
    * **trend analysis** – analyzes the market and provides important event feeds;
    * **signature** – signs transactions with Ed25519 signature. Raw and canonical envelope signing is supported;
    * and more!!!
  </Accordion>
</AccordionGroup>

<callout>
  The number of agents in Silvana will grow with time. Build your own agents and contribute to the Agent Space.
</callout>

<card>
  ## **Agent Catalogue**

  See a list of Silvana agents [**here**](https://silvana.one/agents/catalog#available-agents).
</card>

<card>
  ## **Agent Playground**

  Test-run the agent you built [**here**](https://silvana.one/agents/playground#simulator).

  <Check>
    The number of agents in Silvana will grow with time. Build your own agents and contribute to the Agent Space.
  </Check>

  <CardGroup>
    <Card title="Agent Catalogue">
      See a list of Silvana agents [here](https://silvana.one/agents/catalog#available-agents).
    </Card>

    <Card title="Agent Playground">
      Test-run the agent you built [here](https://silvana.one/agents/playground#simulator).
    </Card>
  </CardGroup>

  <br />
</card>

<CardGroup>
  <Card title="Agent Catalogue" href="https://silvana.one/agents/catalog">
    See a list of Silvana agents.
  </Card>

  <Card title="Agent Playground" href="https://silvana.one/agents/playground">
    Test-run an agent.
  </Card>
</CardGroup>

<CardGroup>
  <Card title="Agentic API" href="/agentic-api/intro">
    Access agentic execution endpoints.
  </Card>

  <Card title="SDK" href="/sdk/introduction/sdk-intro">
    Build your own agent.
  </Card>
</CardGroup>


# Silvana Agents
Source: https://docs.silvana.one/platform/overview/agents



# Agent Platform

Silvana provides the infrastructure for agents to interact with assets: automate actions, coordinate transactions, and trigger settlement.

Every sensitive operation is constrained by permissions, policies, signing rules, and settlement logic. This gives developers and institutions automation without blind execution.

<Tip>
  Learn more about available endpoints, transaction flows, and integration patterns in the [Agentic API](/agentic-api/intro) documentation.
</Tip>

# Where Agents Come From

Silvana embraces all types of agents out there: AI-powered, rule-based, human-assisted, etc.

Agents come from multiple sources:

* platform-native agents;
* agents built by users;
* third-party agents (Perplexity, Claude, etc.).

Bring your own agents, integrate third-party agents, or build and publish new ones for others to use. Mix agents from different providers, connect them into custom workflows, and deploy them through a unified execution layer.

# What Agents Do

Agents in Silvana perform all operations on assets that would otherwise require manual coordination among users, applications, wallets, ledgers, and external systems.

Below are some samples of agents operating on Silvana:

<Columns>
  <Column>
    <Card title="Asset and Activity Monitoring" icon="chart-line">
      Track balances, transactions, and account activity in real time.
    </Card>
  </Column>

  <Column>
    <Card title="Oracles" icon="database">
      Read market, business, and external data to drive decisions.
    </Card>
  </Column>
</Columns>

<Columns>
  <Column>
    <Card title="Tx Builders" icon="file-signature">
      Build transactions and workflow actions before execution.
    </Card>
  </Column>

  <Column>
    <Card title="Policy Enforcement" icon="shield-check">
      Apply limits, permissions, and business rules automatically.
    </Card>
  </Column>
</Columns>

<Columns>
  <Column>
    <Card title="Approval Management" icon="user-check">
      Request and coordinate approvals when required by policy.
    </Card>
  </Column>

  <Column>
    <Card title="Payroll" icon="arrows-left-right">
      Manage recurring payments to counterparties, employees, etc.
    </Card>
  </Column>
</Columns>

<Columns>
  <Column>
    <Card title="Track Execution Status" icon="clock-rotate-left">
      Monitor transaction progress from initiation to settlement.
    </Card>
  </Column>

  <Column>
    <Card title="Generate Verifiable Outputs" icon="badge-check">
      Produce proofs, attestations, and reports for audit and compliance.
    </Card>
  </Column>
</Columns>

<Callout icon="info">
  This list is not exhaustive. These capabilities are just the starting point. Agents can be combined, extended, or custom-built for virtually any action.
</Callout>

# Marketplace

Agents are the building blocks of the future tokenized economy.

The Silvana **Agent Marketplace** is an open ecosystem where agents are bought and sold. Instead of building every workflow from scratch, users can purchase and leverage specialized agents for their business goals.

As the ecosystem grows, the marketplace will become a hub for agent-driven applications, enabling businesses to assemble complex financial and operational systems from modular, reusable components.

<Check>
  **Discover agents. Deploy instantly. Monetize what you build.**
</Check>


# Ambassador Program
Source: https://docs.silvana.one/platform/overview/ambassador-program



<Frame>
  <img alt="Ambassador 1" />
</Frame>

Turn your influence into impact. Create useful content, start conversations, grow the Silvana community, and get rewarded for helping more people discover the ecosystem.

<Callout icon="person-rays">
  The Ambassador Program is designed for creators, community builders, educators, and other contributors ready to go beyond individual tasks and take an active role in shaping and growing the Silvana community.
</Callout>

# Grow With Silvana

Becoming a Silvana Ambassador opens more ways to contribute, connect, and grow alongside the ecosystem.

<Columns>
  <Card title="Your Path to a Contract" icon="money-bill-trend-up">
    Pass the selection process as a qualified ambassador and move into an ongoing paid collaboration
  </Card>

  <Card title="Earn More Rewards" icon="gift">
    Receive additional rewards for your contributions, with boosted referral earnings through your audience
  </Card>

  <Card title="Connect with the Team" icon="users">
    Join a closer circle of contributors and communicate directly with the Silvana team
  </Card>

  <Card title="Build Your Presence" icon="chart-line-up">
    Grow your visibility by creating content, organizing activities, and contributing your expertise
  </Card>
</Columns>

# **Who should apply**

You do not need to fit into one narrow definition of an Ambassador.

<Card title="Bring Value to Silvana" icon="sparkles">
  We welcome ambassadors with an active audience, original content, or expertise in Web3, crypto, digital finance, AI agents, development, community building, or events.
</Card>

<Check>
  Previous examples of your work matter, as does the ability to explain complex topics clearly, communicate consistently, and build genuine engagement rather than spam or artificial activity.
</Check>

# Start Your Journey

Ready to bring your ideas, skills, and community closer to Silvana? Getting started only takes a few steps.

<Steps>
  <Step title="Explore the Program">
    Find the "**Become the Voice of Silvana"** card in Earn Hub tasks and click Read more to explore the program, benefits, and what Silvana is looking for.

    <Frame>
      <img alt="Ambassador Task" />
    </Frame>
  </Step>

  <Step title="Start Your Application">
    Click **Apply to become an ambassador**, open the application form, and tell us how you would like to contribute.
  </Step>

  <Step title="Share What You Bring">
    Introduce your background, experience, community work, previous projects, or content that can help us understand the value you can bring to Silvana.

    <Callout icon="lightbulb">
      Links to relevant work, social profiles, projects, or previous contributions can help us get a better picture of your experience.
    </Callout>
  </Step>

  <Step title="Review and Submit">
    Check your application, accept the Ambassador Program Terms and Conditions and Privacy Policy, confirm that your information is accurate, and click **Submit application**.

    <Note>
      Make sure your contact details are correct so the Silvana team can reach you regarding your application.
    </Note>
  </Step>

  <Step title="Wait for a Response">
    The Silvana team will review your application and contact you with the result.

    <Frame>
      <img alt="Submitted Ambassador2 1" title="Submitted Ambassador2 1" />
    </Frame>
  </Step>
</Steps>

# Once You’re Approved

<Callout icon="party-horn">
  Once your application is approved, your Ambassador status becomes active, giving you access to dedicated features and communication channels.
</Callout>

<Columns>
  <Card title="Ambassador Account" icon="user-check">
    Get a dedicated account designed for your activities and program access.
  </Card>

  <Card title="Ambassador Badge" icon="badge-check">
    Receive your special badge and make your role within the community visible.
  </Card>

  <Card title="Private Team Chat" icon="messages">
    Connect directly with the team through a private Ambassador chat.
  </Card>
</Columns>

## **Have a few questions?**

<AccordionGroup>
  <Accordion title="What happens after I submit?">
    Your application goes to the Silvana team for review. Submitting the form does not automatically grant Ambassador status; it is the first step toward joining the program.

    <Note>
      Keep an eye on the contact details you provide in the application so the team can reach you.
    </Note>
  </Accordion>

  <Accordion title="Can I update my application after submitting?">
    Yes. If you forgot to include something or want to add more information, you can submit a new application. The application form can be submitted up to 5 times per day.
  </Accordion>
</AccordionGroup>


# Matching and Execution
Source: https://docs.silvana.one/platform/overview/matching-and-execution



## Separation of Matching and Settlement

Silvana Book separates **execution** (order matching) from **settlement**:

* **Execution** (**order matching**) runs **off-chain** in a private matching engine. No orders or depth are exposed to the public.
* **Settlement** runs **on-chain** on Canton using [Delivery-versus-Payment (DvP)](/silvana-book/introduction/how-silvana-book-ensures-security), so asset transfer and payment are atomic.

Agents and clients never perform matching themselves; they submit orders and consume events. The orderbook service matches orders and then drives settlement flow via the **Coordination Layer**.

## Participants and the Orderbook API

Participants (or their agents) communicate with the orderbook via the Silvana API, typically through the orderbook client. The API is defined by the orderbook protocol and implemented as API service. The client uses a JWT for authentication and a Transport (e.g. Node or web) to send requests and receive streams.

From the client’s perspective, execution revolves around:

* **Submitting and cancelling orders**: e.g. `submitOrder`, `cancelOrder`.
* **Reading book and orders**: e.g. `getOrderbookDepth`, `getOrders`, `getOrderHistory`.
* **Subscribing to real-time updates**: e.g. `subscribeOrderbook`, `subscribeOrders`, `subscribeSettlements`.

<Note>
  Execution is **event-driven**: agents place/cancel orders and react to orderbook updates, order state changes, and settlement events.
</Note>

## Order Submission and Matching Flow

1. **Submit orders**<br />A participant (or agent) calls the API to submit an order for a given market, with order type (e.g. limit/market), price, quantity, time-in-force, optional expiry, and optional trader order ref and signature/nonce for authentication and replay protection. Orders are sent to the Orderbook service over the authenticated channel.
2. **Private matching engine**<br />The orderbook service holds a private order book per market. Its matching engine runs off-chain: it takes incoming orders, matches them against resting bids and asks according to price-time (or other configured) rules, and produces fills and trades.

<Check>
  This is where execution happens; **it is not visible to the public**!
</Check>

3. **Optimistic execution outcome**<br />When orders match, the system produces an **optimistic state**: the trade is considered executed from the participant’s perspective. Order state (e.g. open, filled, partially filled, cancelled) is updated and exposed via the API and streams.

<Check>
  Agents can subscribe to order updates and orderbook depth to stay in sync and react to fills without polling.
</Check>

4. **Settlement proposals and DvP**<br />Matched trades are not settled on-chain immediately. The coordination layer turns them into settlement proposals and runs the Delivery-versus-Payment (DvP) workflow on Canton. Participants can query settlement proposals and settlements via the API and subscribe to settlement updates to receive notifications when proposals are created and settlements are finalized.

Orders are scoped by market and carry order type, price, quantity, time in force, and optional expiry. The client uses the same JWT for all calls; the backend associates orders and streams with the authenticated party.

<Note>
  **Agents do not match orders!** They submit them and subscribe to orderbook, order, and settlement streams. The orderbook service performs matching and hands off to the coordination layer for DvP settlement.
</Note>


# Welcome to Silvana
Source: https://docs.silvana.one/platform/overview/meet-silvana

Introductory notes.

<Frame>
  <img alt="Image" />
</Frame>

Tokenization is in full swing. However, alone, it is not enough. Assets need to be effectively handled. Increasingly, these operations will be performed by software agents rather than humans.

We believe that:

1. Ultimately, all assets will be tokenized.
2. Agents will operate them.

<Callout icon="chain">
  Silvana is the agent interaction layer for the next generation of tokenized assets.
</Callout>

Our vision extends to treasury management, lending, payroll, compliance, reporting, audit, due diligence, RWA, and corporate operations, and far beyond.

# Why Canton?

Silvana and Canton are a powerful match. Canton ensures privacy and secure institutional-grade settlement, while Silvana provides a framework for building agentic apps to manage tokenized assets.

| **Silvana** | **Canton** |
| - | - |
| Agent building, integration, and runtime | Private ownership |
| Workflow orchestration and automation | Asset issuance |
| Settlement coordination | DvP settlement |
| Agent APIs and SDKs for devs | Institutional infrastructure |

<Callout icon="star-shooting">
  [Silvana Book](/silvana-book/introduction/meet-silvana-book) is our first chapter: a private, agent-driven orderbook on Canton.
</Callout>

# Why Silvana?

These are Silvana's key features that make it stand out:

<CardGroup>
  <Card title="Rule-Based Agent Execution" icon="arrows-turn-to-dots">
    Automate workflows the way you need, with assets and approvals under your control.
  </Card>

  <Card title="Enterprise-Grade" icon="business-time">
    Silvana serves businesses and institutions that require private, secure, and compliant operations.
  </Card>
</CardGroup>

<Columns>
  <Column>
    <Card title="Easy to Build" icon="tools">
      Build and deliver agent-driven apps faster with [APIs](/agentic-api/intro), [SDKs](/sdk/introduction/sdk-intro), and orchestration tools.
    </Card>
  </Column>

  <Column>
    <Card title="Ultra-Fast" icon="arrow-progress">
      We ensure sub-second tx execution by landing the Coordination Layer on a fast blockchain.
    </Card>
  </Column>
</Columns>

<Columns>
  <Column>
    <Card title="Built for Real Use" icon="money-bill-trend-up">
      We support real-world use cases across trading, treasury, payments, lending, and other areas.
    </Card>
  </Column>

  <Column>
    <Card title="Lower Tx Costs" icon="money-check-dollar-pen">
      Coordination Layer batches and sequences txs to reduce fees and make operations economically viable.
    </Card>
  </Column>
</Columns>

<Columns>
  <Column>
    <Card title="Private by Design" icon="table-cells-row-lock">
      Keep your business activity confidential with DvP settlement, ZK proofs, and TEE computing.
    </Card>
  </Column>

  <Column>
    <Card title="Multi-Chain by Nature" icon="arrows-up-down-left-right">
      Silvana is chain-agnostic. It is based on Canton, has the execution layer on Sui, and can handle assets from any chain.
    </Card>
  </Column>
</Columns>

<Columns>
  <Column>
    <Card title="Auditable Activity" icon="list-check">
      ZKPs verify balances, transactions,  cash flows, and financial outcomes without exposing business data.
    </Card>
  </Column>

  <Column>
    <Card title="Modular by Default" icon="boxes">
      Assemble applications from modular building blocks and tailor them to your business needs.
    </Card>
  </Column>
</Columns>

<Columns>
  <Column>
    <Card title="Agent Marketplace" icon="shopping-cart">
      Buy and sell ready-made custom agents for your business.
    </Card>
  </Column>

  <Column>
    <Card title="Selective Disclosure" icon="field-hockey-stick-ball">
      You decide which part of your business activity will be publicly available.
    </Card>
  </Column>
</Columns>

<Callout icon="star">
  We make tokenized assets actually operable and usable.
</Callout>


# Settlement
Source: https://docs.silvana.one/platform/overview/settlement



## From Matching to Settlement

Settlement is the process of turning those proposals into on-chain, atomic asset transfer and payment on Canton via Delivery-versus-Payment (DvP).

* **Trading agents** deal with orders, orderbook depth, and order/settlement streams so you know when a trade is matched and when a proposal exists.
* **Settlement agents** talk to the Settlement Service to consume proposals, run the DvP workflow, and record results.

## Settlement Flow at a Glance

A typical flow looks like this:

1. **Settlement proposal intake**

Settlement agent learns about new proposals, e.g., via pending proposals or the bidirectional settlement stream.

2. **Preconfirmation**

Parties confirm they are ready to settle (preconfirmation decision), so the system can proceed with DvP.

3. **DvP on Canton**

The coordination layer drives DvP contract creation, counterparty acceptance, allocation, and final settlement on Canton. Agent participates via the settlement stream and/or by recording events.

4. **Recording State**

As DvP completes, the operator (or designated component) records the settlement; events and transactions can be recorded for audit and history. Agents can query settlement status and proposal/history to monitor the state.

<Note>
  The Settlement client does not use a JWT as the orderbook client does; it uses Canton node authentication per request, and the bidirectional stream is initiated by the Canton node, allowing the server to push commands and the node to respond.
</Note>

<Note>
  Use the orderbook client for orders and matching-related streams; use the Settlement client for proposal intake, DvP coordination (stream + preconfirmation/disclosed contracts), and recording.
</Note>


# Solution
Source: https://docs.silvana.one/platform/overview/solution



Silvana is built as a layered execution platform.

Each layer has a specific responsibility, but together they form one system for controlled automation: agents prepare actions, workflows are coordinated, sensitive data remains protected, proofs make outcomes verifiable, and final settlement is executed through Canton’s DvP infrastructure.

## Execution Layer

The Execution Layer is where agents perform actions. Execution is not tied to a single environment and can run:

* off-chain
* on another blockchain
* in the cloud
* inside a user-controlled private environment
* within a Trusted Execution Environment (TEE)

Agents handle the actual work. Developers can build agents themselves, integrate existing agents from external environments, or use agents provided by Silvana.

<Callout icon="lightbulb">
  The flexibility allows teams to build modular applications with custom logic and deploy them via Silvana [APIs](/sdk/introduction/sdk-intro) and [SDKs](/sdk/introduction/sdk-intro) without having to rebuild the execution stack from scratch.
</Callout>

## Coordination Layer

The Coordination Layer orchestrates how agents, applications, proofs, and settlement flows work together.

It handles a wide range of workflow coordination functions, including:

* Sequencing agent actions in the correct order
* Batching multiple operations into a single coordinated process
* Routing tasks, messages, and transactions between agents and systems
* Orchestrating multi-step transactions and cross-system workflows
* Automating business processes based on predefined rules and conditions
* Managing workflow state and tracking progress across execution stages
* Synchronizing actions between multiple agents, applications, and environments
* Coordinating dependencies, approvals, and event-driven triggers throughout a workflow

<Check>
  This is especially important for agentic applications, where the Coordination Layer connects policy checks, proofs, verification, settlement, and reconciliation into a single executable workflow.
</Check>

The Coordination Layer is built on a fast chain, enabling Silvana to support ultra-fast coordination at low transaction costs.

## Privacy-Preserving Layer

The Privacy-Preserving Layer makes execution verifiable without exposing confidential data.

Silvana uses zero-knowledge proofs, selective disclosure, TEE-based confidential execution, and MPC-based integrations to protect sensitive information while still allowing users, counterparties, auditors, or applications to verify outcomes.

<Callout icon="lightbulb">
  For enterprises and institutional users, this creates an important separation: data can stay private, while correctness can still be proven.
</Callout>

## Settlement Layer

The Settlement Layer finalizes asset transfers and anchors execution results.

Silvana uses Canton’s [DvP settlement](/silvana-book/introduction/how-silvana-book-ensures-security) infrastructure to ensure that delivery and payment happen together. Assets move only when all settlement conditions are satisfied. If one side fails to meet its obligations, settlement does not complete, and the transaction rolls back.

<Check>
  We abstract the complexity of DvP into developer-friendly settlement workflows.
</Check>

[A two-phase transaction model](/agentic-api/transaction-flow) also helps to keep settlement secure while abstracting low-level ledger, allocation, confirmation, and synchronization complexity from developers.


# Use Cases
Source: https://docs.silvana.one/platform/overview/use-cases



Silvana use cases show how tokenized assets can move from passive records to active operations.

Agents can trade, pay, borrow, rebalance, reconcile, audit, and enforce risk rules across financial and business workflows. The result is practical automation for real asset operations, with privacy, verification, and control built into the flow.

## Trade

In a live trading workflow, agents can trade tokenized assets on the orderbook through RFQs, order placement, rebalancing, and settlement coordination.

The agent does not need to expose the trader’s full strategy to the public market. It can submit orders, react to market data, monitor fills, adjust exposure, and adhere to risk limits, while the user retains control over assets and signing authority.

## Commerce

In this model, agents can discover services, negotiate terms, initiate payments, and manage fulfillment. Instead of treating a commercial transaction as a simple payment event, Silvana can support the full operational flow around it: request, quote, agreement, execution, delivery, verification, settlement, and records.

## Margin

This differs from a simple loan flow because the margin is tied to active strategy execution. A trading desk, fund, or treasury may need capital at a specific moment, subject to specific exposure limits, with collateral that fluctuates in value. Manual monitoring is slow and risky. An agent can continuously track its position and act before the situation becomes urgent.

It can:

* monitor liquidity needs and portfolio exposure
* source financing when extra capital is needed
* manage collateral and margin requirements
* refinance when better terms appear
* act before the position becomes risky.

## Payroll

A company can use agents to automate recurring payments to employees, contractors, partners, counterparties, tax authorities, and other scheduled recipients. The agent follows predefined rules, verifies payment conditions, prepares transactions, initiates payments, tracks settlement, and generates payment records.

## Loans

The agent’s role is to manage the loan lifecycle. It can source financing, evaluate offers, check eligibility, manage collateral, monitor repayment schedules, track obligations, and refinance when better conditions appear. In tokenized asset environments, this becomes especially powerful because collateral, payment flows, risk checks, and settlement states can be represented digitally and coordinated through programmable workflows.

## Risk Compliance Check

Every organization has rules. A trade may have size limits. A treasury transfer may require approval. A counterparty may need screening. A loan may need collateral coverage. A payment may need policy validation. When these checks remain manual, operations slow down, and violations can slip through. A Risk Compliance Check agent evaluates actions before execution:

* checks transactions, counterparties, exposures, limits, and restrictions;
* approves, blocks, modifies, or escalates actions based on policy;
* records compliance outcomes for reporting and audit.

## Audit and Due Diligence

Silvana can support audit and due diligence through agents that collect records, validate evidence, generate proofs, and prepare reports. The [Privacy-Preserving Layer](/platform/overview/solution) allows selected facts to be verified while sensitive underlying data remains protected.

## Account Reconciliation

Silvana’s settlement references, update identifiers, and structured execution records make this use case especially valuable because reconciliation depends on traceable transaction state. A Reconciliation Agent can continuously monitor records, match entries across systems, detect inconsistencies, and generate reports.

## Treasury Management

Treasury teams manage liquidity, capital allocation, reserves, risk exposure, payments, and portfolio strategy. In tokenized asset environments, these operations can move faster, but they also require better automation and stronger controls.

Silvana gives the opportunity to monitor balances, liquidity, exposures, market conditions, and allocation policies. It can suggest or execute transfers, swaps, reallocations, and rebalancing actions according to predefined rules. It can also maintain cash buffers, rotate yield exposure, and prepare settlement-ready transactions.


# Who Silvana Is Built For
Source: https://docs.silvana.one/platform/overview/who-silvana-is-built-for



Tokenization drives demand among many market participants.

<Callout icon="users">
  Silvana extends beyond a single use case, serving a wide range of users and beneficiaries who need agents to interact with tokenized assets securely and efficiently.
</Callout>

We provide users of different types with a shared execution environment where agents can handle work privately, securely, and at scale.

## Who Uses Silvana?

Silvana caters to:

<CardGroup>
  <Card title="AI Developers">
    Build agents that can observe, decide, and act on tokenized assets.
  </Card>

  <Card title="Market Makers / Liquidity Providers">
    Run private strategies without exposing inventory, intent, or pricing logic.
  </Card>

  <Card title="Treasuries / DAOs">
    Asset management, portfolio rebalancing, and treasury operations.
  </Card>

  <Card title="Token Issuers / RWA Platforms">
    Trade tokenized assets and make them accessible to agents.
  </Card>

  <Card title="Financial Institutions">
    Asset management, compliance checks, audit, and due diligence.
  </Card>

  <Card title="Corporate Finance Teams">
    Payments, approvals, reporting, and financial operations.
  </Card>

  <Card title="Auditors">
    Check business activity, balances, and policies for compliance.
  </Card>

  <Card title="Accounting and Operations Teams">
    Reconcile records across business units, wallets, apps, and systems.
  </Card>

  <Card title="Government Agencies">
    Streamline official registries, identity systems, and public-sector workflows.
  </Card>

  <Card title="Researchers">
    Get reliable data, tech stats, gain insights, track asset flow and activity.
  </Card>
</CardGroup>


# Execution API
Source: https://docs.silvana.one/sdk/grpc-api/execution-api



# Overview

Use the Execution (Orderbook) API through gRPC  `OrderbookService` to discover markets, place and manage orders, request quotes, and monitor settlement-related activity in the orderbook.

Execution API powers these user flows:

* buy CC via RFQ;
* sell CC via RFQ;
* run as an LP or market-maker;
* monitor settlement-related execution activity.

# API Surface

Below are the Execution (Orderbook) API sections.

## Instruments and Markets

Start every trading flow by loading instruments and markets.

This is the standard initialization path for takers, LPs, and custom agents. It is also the natural first step before quoting, placing orders, or building routing logic.

### Use cases:

* populate market selectors in the UI;
* validate tradable pairs such as `CC-USDC` .

initialize trading agents with supported markets.

### Endpoint:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetInstruments` | Load the instrument registry before trading or strategy setup. |
| `GetMarkets` | List active markets and market metadata. |
| `CreateInstrument` | Register a new tradable instrument in the orderbook (admin operation). |
| `CreateMarket` | Open a new market for an instrument pair (admin operation). |
| `UpdateMarketPriceFeeds` | Update the price-feed sources bound to a market (admin operation). |

## Orders

Use the Orders endpoints to place and manage orderbook orders.

This is the core execution path for maker strategies and long-running LP agents. In long-running mode, the cloud agent places grid orders on configured markets and continuously manages them.

### Use cases:

* submit maker quotes as resting orders;
* review filled, open, or canceled orders;
* update strategy state after order changes.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetOrders` | Retrieve active or historical orders. |
| `GetOrderHistory` | Fetch a richer historical order log scoped to the authenticated party. |
| `SubmitOrder` | Place a new order on the orderbook. |
| `CancelOrder` | Cancel an existing order. |

## Orderbook Depth and Streams

Use market data endpoints to read Silvana Book's live state.

The standard pattern is snapshot plus stream:

1. fetch a current depth snapshot;
2. subscribe to updates;
3. maintain an in-memory live book view.

### Use cases:

* render live orderbook depth in a UI;
* feed strategy engines and market-making bots;
* track execution conditions before sending orders or RFQs.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `getOrderbookDepth` | Get a point-in-time depth snapshot. |
| `SubscribeOrderbook` | Stream live orderbook updates for bots, dashboards, and execution logic. |

## RFQ

RFQ is the primary taker execution flow in the repo.

The CLI `buy` and `sell` flows are built on this model. For example, buying CC on `CC-USDC` requests quotes, selects the best offer, and continues into settlement. The repo also notes that the buy flow repeats until the full requested amount is filled.

### Use cases:

* one-off taker execution;
* best-quote selection across LPs;
* RFQ monitoring and trade audit trails.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `RequestQuotes` | Request executable quotes for a market such as `CC-USDC`. |
| `StreamRequestQuotes` | Stream RFQ progress for a request: incoming quotes, lifecycle updates, and completion. |
| `AcceptQuote` | Accept the selected quote and continue execution. |
| `StreamRfqEvents` | Monitor RFQ activity in real time. |
| `GetRfqAuditLog` | Retrieve RFQ history for audit and review. |
| `StreamRfqAuditLog` | Stream RFQ audit updates as they occur. |

## Settlement Proposals

Execution continues beyond quote acceptance. After a trade is agreed, clients can inspect the settlement-related execution state through the settlement proposal endpoints.

This is useful for agents that need to react to proposed settlements, automate post-trade handling, or surface trade progress in a UI.

### Use cases:

* monitor execution progress after RFQ acceptance;
* trigger downstream post-trade logic;
* power execution status views.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetSettlementProposal` | Fetch a single settlement proposal by ID. |
| `GetSettlementProposals` | Inspect settlement proposals related to execution. |
| `GetSettlements` | Retrieve completed settlements for analytics and reconciliation. |
| `GetUserSettlementStats` | Aggregate per-user settlement statistics (volume, count, success rate). |
| `EstimateSettlementFees` | Pre-compute the expected settlement fees for a planned trade. |
| `SubscribeSettlements` | Monitor settlement updates after execution. |

## Liquidity Providers and Rounds

The Execution API also exposes metadata about the network environment.

These endpoints are useful for analytics, routing decisions, and understanding how liquidity is distributed across the execution environment.

### Use cases:

* discover available quoting counterparties;
* enrich execution dashboards;
* drive market-maker or taker routing logic.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetLiquidityProviders` | Discover connected liquidity providers. |
| `GetConnectedLiquidityProviders` | List LPs that are currently connected and quoting in the active session. |
| `GetRoundsData` | Retrieve round and network metadata relevant to execution. |

## Parties

The orderbook tracks a party record for each authenticated trading entity. Use these endpoints to onboard, edit, deactivate, and inspect parties.

### Use cases:

* onboard a new party before its first order;
* edit display metadata or settings;
* inspect counterparty info for execution and audit views;
* review historical activity tied to a party.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `CreateParty` | Register a new party in the orderbook. |
| `UpdateParty` | Update mutable fields on an existing party record. |
| `DeactivateParty` | Mark a party as inactive so it can no longer place orders. |
| `GetParty` | Fetch a single party record by ID. |
| `GetParties` | List parties, with optional filters and pagination. |
| `GetPartyHistory` | Retrieve historical activity for a party (orders, settlements, RFQs). |

## Invites and Waiting List

Onboarding into the orderbook is gated by invites and a waiting list during the early-access phase.

### Use cases:

* queue a new user for access via the waiting list;
* look up an invite issued to the authenticated user;
* redeem an invite to complete onboarding.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `AddWaitingListEntry` | Add the authenticated user to the orderbook waiting list. |
| `GetInvite` | Fetch the invite associated with the authenticated user, if any. |
| `UseInvite` | Redeem an invite code to unlock orderbook access. |

# Example flow

A typical taker flow looks like this:

1. Call `GetInstruments` and `GetMarkets` to load tradable markets.
2. Call `RequestQuotes` for a market such as `CC-USDC`.
3. Review the returned quotes and call `AcceptQuote` on the best one.
4. Track settlement using settlement proposal endpoints and hand off completion to the ledger-backed settlement flow.


# gRPC API Types
Source: https://docs.silvana.one/sdk/grpc-api/grpc-api-types



# gRPC API

The agent communicates with the Silvana orderbook server via 4 gRPC services defined in `proto/silvana/*/v1/*.proto`.

| **Service** | **Proto** | **Role** | **Streaming** |
| :- | :- | :- | :- |
| `DAppProviderService` | `ledger/v1/*.proto` | Two-phase <br />transaction signing, <br />balance and <br />contract queries | Server-streaming <br />(`GetActiveContracts`, <br />`GetUpdates`) |
| `SettlementService` | `settlement/v1/settlement.proto` | DVP settlement <br />orchestration, <br />RFQ handling | Bidirectional <br />(`SettlementStream`) |
| `OrderbookService` | `orderbook/v1/orderbook.proto` | Order submission, <br />market data, <br />RFQ initiation | Server-streaming <br />(`SubscribeOrderbook`, <br />`SubscribeOrders`, <br />`SubscribeSettlements`) |
| `PricingService` | `pricing/v1/pricing.proto` | External price <br />feeds (Binance, <br />ByBit, CoinGecko) | Server-streaming <br />(`StreamPrices`) |

<Check>
  Access gRPC APIs below.
</Check>

<CardGroup>
  <Card title="Execution API" href="/sdk/grpc-api/execution-api">
    Place orders and execute trades.
  </Card>

  <Card title="Pricing API" href="/sdk/grpc-api/pricing-api">
    Get live and historical prices.
  </Card>

  <Card title="Settlement API" href="/sdk/grpc-api/settlement-api">
    Track and manage trade settlement.
  </Card>

  <Card title="Ledger Gateway API" href="/sdk/grpc-api/ledger-gateway-api">
    Query the ledger and submit txs.
  </Card>
</CardGroup>


# Ledger Gateway API
Source: https://docs.silvana.one/sdk/grpc-api/ledger-gateway-api



# Overview

Use the Ledger Gateway API to read ledger state, onboard an agent, prepare and execute signed transactions, and request faucet funds on supported environments.

It is the ledger proxy used by cloud agents that run without direct access to the Canton ledger, while keeping the Ed25519 private key local to each agent.

# API surface

Below are the Ledger Gateway API sections.

## Streaming queries

Use this API for streaming.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetActiveContracts` | Stream active contracts for the authenticated party. |
| `GetUpdates` | Stream ledger updates from an offset, for example, to track transaction <br />confirmations. |

## Unary queries

Use the unary query RPCs for point-in-time ledger reads.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetLedgerEnd` | Get the current ledger end offset. |
| `GetBalances` | Fetch token balances, including CIP-56 holdings and Canton Coin. |
| `GetPreapprovals` | Retrieve transfer preapproval contracts. |
| `GetDsoRates` | Read CC/USD rate and current round data. |
| `GetSettlementContracts` | Discover on-chain DVP proposal and settlement contracts. |
| `GetServiceInfo` | Fetch provider service metadata and capability information. |
| `GetAmulets` | Retrieve unlocked amulet contracts and amounts. |
| `GetPrepaidTrafficBalance` | Read the remaining prepaid traffic balance for the authenticated party. |

## Onboarding

The onboarding flow is separate from normal JWT-authenticated access.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetAgentConfig` | Get an unauthenticated agent configuration template. |
| `RegisterAgent` | Register an agent on the waiting list with an Ed25519-signed <br />request. |
| `GetOnboardingStatus` | Poll onboarding progress with an Ed25519-signed request. |
| `SubmitOnboardingSignature` | Submit the onboarding multihash signature. |

## Transactions

### Transaction Flow

Ledger mutations use a two-phase protocol.

#### Phase 1

`PrepareTransaction` builds the transaction and returns a transaction ID, a prepared transaction hash, the prepared Canton payload, the hashing scheme version, fee data, and service signatures over the response.

#### Phase 2

`ExecuteTransaction` submits the locally produced signature, together with fee authorization data, and returns the execution status, update ID, optional created contracts, and structured provider errors when execution fails.

<CardGroup>
  <Card title="SDK Interaction Flow" href="/sdk/reference/sdk-interaction-flow">
    Read more about transaction mechanics in Silvana.
  </Card>
</CardGroup>

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `PrepareTransaction` | Build a transaction and return the hash and prepared payload to sign <br />locally. |
| `ExecuteTransaction` | Submit the signed transaction for execution. |
| `PreparePayFee` | Build a fee-payment transaction and return the hash and prepared payload to sign <br />locally. Used as the fee leg for DvP, multicall, and other authenticated flows. |
| `ExecutePayFee` | Submit the signed fee-payment transaction. Pairs with `PreparePayFee`. |

## Faucet

Use `RequestFaucet` to request funds from the faucet when the environment supports it. The service proto describes this as a server-side submission path that does not need the two-phase signing flow.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `requestFaucet` | Request CC or CIP-56 tokens from the faucet, where enabled. |
| `ListFaucetInstruments` | Discover which token instruments the faucet currently supports in the active environment. |

# Example flow

A typical Ledger Gateway flow looks like this:

1. Call `GetAgentConfig` to load the initial onboarding template.
2. Call `RegisterAgent` and poll `GetOnboardingStatus`.
3. Submit the required onboarding signature with `SubmitOnboardingSignature`.
4. Call `GetBalances` or `RequestFaucet` to initialize working balances where needed.
5. Call `PrepareTransaction`, sign the returned hash locally, then call `ExecuteTransaction`.
6. Use `GetLedgerEnd` and `GetUpdates` to monitor confirmation and downstream effects.


# News API
Source: https://docs.silvana.one/sdk/grpc-api/news-api



# Overview

Use the News API to read product and market announcements published by Silvana. In this repo, these capabilities are exposed through the `NewsService` gRPC service.

News API is useful for surfacing announcements in client UIs, monitoring product updates from agents, and building notification pipelines around protocol-level events.

# API Surface

Below are the News API sections.

## News Feed

Use `GetNews` when you need a point-in-time fetch of recent news items. The request can include filters such as a category, a tag, a result limit, and an optional pagination cursor. The response returns a list of news items with title, body, publication timestamp, optional categories, and optional tags.

### Use Cases:

* render a news section in a dashboard or onboarding flow;
* batch-import announcements into a notification system;
* audit which announcements were active at a given time.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetNews` | Fetch a paginated list of news items, optionally filtered by category or tag. |

## Streams

Use `StreamNews` to subscribe to live news updates. The stream emits each new item as it is published. Filters mirror the unary call so that clients can subscribe to a single category or tag.

### Use Cases:

* show live announcement banners in trading UIs;
* forward Silvana announcements into Slack, Discord, or alerting pipelines;
* trigger agents on protocol-level events.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `StreamNews` | Subscribe to a real-time feed of news items as they are published. |

# Example flow

A typical news flow looks like this:

1. Call `GetNews` once to backfill recent announcements at startup.
2. Open `StreamNews` to receive live updates from that point forward.
3. Optionally filter by category or tag to scope the feed to a specific surface.


# Pricing API
Source: https://docs.silvana.one/sdk/grpc-api/pricing-api



Use the Pricing API to fetch current prices, batch quotes, candle data, order book snapshots, live price streams, and pivot points. In this repo, these capabilities are exposed through the `PricingService` gRPC service.

# API Surface

Below are the Pricing API sections.

## Prices

Use `GetPrice` when you need the current price for one market. The request takes a `market_id` and can optionally specify a `source`. The response includes fields such as `last`, optional `bid` and `ask`, optional 24h metrics, the selected source, and a timestamp.

Use `GetPrices` when you need the latest price data for multiple markets in one request. This is the batch version of single-market price lookup and is a better fit for dashboards, watchlists, and multi-market strategies.

In the current SDK client, `GetPrice` is the pricing method that is explicitly wrapped as a helper.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetPrice` | Get the latest price for a single market, such as `CC-USDC`. |
| `GetPrices` | Fetch current prices for multiple markets in one request. |

## Historical Data

Use `GetKlines` to retrieve candle data for a market. The request includes `market_id`, `interval`, optional `limit`, optional `start_time`, optional `end_time`, and optional `source`. The proto lists supported interval examples such as `1m`, `5m`, `15m`, `30m`, `1h`, `4h`, `1d`, and `1w`.

### Use Cases:

* price charts;
* historical analysis;
* strategy research;
* time-series exports.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetKlines` | Load candle data for charting, backtesting, or analytics. |
| `GetOrderBook` | Retrieve a point-in-time order book snapshot. |

## Market Depth

Use `GetOrderBook` when you need a snapshot of bids and asks for a market. The request includes `market_id`, optional `depth`, and optional `source`. The response returns bid and ask levels, a timestamp, and the source used.

### Use Cases:

* rendering a read-only market depth view;
* pre-trade analysis;
* lightweight monitoring without opening a stream.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetKlines` | Retrieve a point-in-time order book snapshot. |

## Streams

Use `StreamPrices` for live market data. The request accepts one or more `market_ids` and optional flags to include order book updates and trade updates in the stream. Stream messages include the market, price, optional bid and ask, optional volume, source, timestamp, and optional embedded order book or trade updates.

### Use Cases:

* live dashboards;
* trading bots;
* alerting systems;
* continuously updated market views.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `StreamPrices` | Subscribe to real-time price updates, with optional order book and trade <br />updates. |

## Technical Analytics

Use `GetPivotPoints` when you need derived support and resistance levels. The request takes a `market_id`, a `timeframe`, and an optional `source`. The response can include classic, fibonacci, camarilla, woodie, and demark pivot calculations, along with a calculation timestamp.

### Use Cases:

* technical-analysis overlays;
* signal generation;
* trader-facing chart tools.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetPivotPoints` | Get calculated pivot levels for daily, weekly, or monthly analysis. |

# Example flow

A typical pricing flow looks like this:

1. Choose a market such as `CC-USDC`.
2. Call `GetPrice` for the latest price.
3. Call `GetKlines` if you also need chart history.
4. Call `GetOrderBook` if you need a current depth snapshot.
5. Open `StreamPrices` if you need live updates.


# Settlement API
Source: https://docs.silvana.one/sdk/grpc-api/settlement-api



# Overview

Use the Settlement API through gRPC `SettlementService`  to coordinate DVP settlement, exchange settlement messages over a long-lived stream, record settlement outcomes, and query settlement state and history.

# API surface

Below are the Settlement API sections.

## Settlement stream

`SettlementStream` is the core realtime RPC in this service.

### Message Flow:

1. The agent sends a handshake,
2. heartbeats,
3. preconfirmations,
4. DVP lifecycle events, and
5. RFQ quotes or rejections.

This is the main endpoint to document for long-running LP agents and any service that needs live settlement orchestration rather than point-in-time queries.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `SettlementStream` | Long-lived bidirectional stream for RFQ handling and settlement <br />lifecycle coordination. |

## Proposal queries

Use `GetPendingProposals` to retrieve pending proposals for a party and `GetSettlementStatus` to inspect the current state of a specific settlement. The proto comments describe these as optional unary RPCs for specific operations.

These endpoints are suitable for monitoring UIs, operational dashboards, and background workers that need to poll the settlement state without joining the bidirectional stream.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `GetPendingProposals` | Fetch pending settlement proposals for a party. |
| `GetSettlementStatus` | Check the current status of a settlement. |

## Preconfirmation

Use `SubmitPreconfirmation` when you need to send a preconfirmation outside the streaming flow. Explicitly labels it as a manual pre-confirmation path when the stream is idle.

This is useful for fallback flows, operational tooling, or integrations that do not maintain a long-lived settlement stream.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `SubmitPreconfirmation` | Submit a manual preconfirmation when not using the stream flow. |

## Disclosed contracts

Use `SaveDisclosedContract` to persist a disclosed contract during allocation, and use `GetDisclosedContracts` to retrieve disclosed contracts. Operators can access all disclosed contracts, while buyers and sellers can access their own.

These endpoints are the right place to document allocation-time artifacts and settlement disclosures separately from the higher-level settlement proposal objects.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `SaveDisclosedContract` | Save a disclosed contract during allocation. |
| `GetDisclosedContracts` | Retrieve disclosed contracts for the current participant or operator. |

## Recording and history

Use `RecordSettlement` to record a completed settlement and `RecordTransaction` to store a transaction in history. Use `GetTransactionHistory` to retrieve historical transactions, `RecordSettlementEvent` to append to the settlement proposal event log, and `GetSettlementHistory` to fetch the event history for a proposal. Settlement history is treated as an append-only event log.

This part of the API is best documented as the audit and observability layer of settlement. It is useful for post-trade operations, internal reconciliation, and external status reporting.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `RecordSettlement` | Record a completed settlement. |
| `RecordTransaction` | Record a transaction in the settlement history. |
| `GetTransactionHistory` | Retrieve historical settlement-related transactions. |
| `RecordSettlementEvent` | Append an event to the settlement proposal history log. |

## Proposal lifecycle

Use `UpdateProposalStatus` to move a proposal through its lifecycle, `GetSettlementProposalById` to fetch proposal details by ID, and `CancelSettlement` to cancel a settlement before execution.`UpdateProposalStatus` is operator-only and is described `CancelSettlement` as available to the buyer or seller before settlement execution.

This is the lifecycle-management part of the service and is the section to document for operational controls, dispute handling, and manual intervention flows.

### Endpoints:

| **Endpoint** | **Use Сase** |
| :- | :- |
| `UpdateProposalStatus` | Update the proposal status to operator-only. |
| `GetSettlementProposalById` | Fetch a settlement proposal by ID. |
| `CancelSettlement` | Cancel a settlement before execution. |

# Example flow

A typical settlement flow looks like this:

1. Open `SettlementStream` and complete the handshake.
2. Receive RFQ requests or settlement proposals from the server.
3. Send preconfirmations and other settlement lifecycle messages as the flow progresses.
4. Record outcomes and events through the unary recording endpoints when needed.
5. Query status or proposal history through the history and lifecycle endpoints.

The agent opens this stream when `[liquidity_provider]` is configured in `agent.toml`.


# Agent Sample
Source: https://docs.silvana.one/sdk/introduction/agent-sample



Now, let's see how we can build an agent.

<Note>
  The same crates the CLI uses are available as Rust libraries. Import them from a path or git and build custom agents, batch tools, or test harnesses.
</Note>

# Example - Buy CC

We take a canonical example – buying CantonCoins.

The agent lives at `examples/buy_cc`.

It buys CC on `CC-USDC`.

`examples/buy_cc/Cargo.toml`:

<CodeGroup>
  ```toml toml theme={null}
  {
    "name": "buy-cc-example",
    "version": "0.1.0",
    "type": "module",
    "dependencies": {
      "cloud-agent": "file:../crates/cloud-agent",
      "agent-logic": "file:../crates/agent-logic",
      "orderbook-proto": "file:../crates/orderbook-proto",
      "dotenv": "^0.15.0",
      "commander": "^4.0.0",
      "pino": "^0.3.0"
    }
  }
  ```
</CodeGroup>

`examples/buy_cc/src/main.rs` (abridged):

<CodeGroup>
  ```ts TypeScript theme={null}
  import "dotenv/config";
  import yargs from "yargs";
  import { hideBin } from "yargs/helpers";

  import { BaseConfig } from "agent-logic/config";
  import { newConfirmLock } from "agent-logic/confirm";
  import { LiquidityManager } from "agent-logic/liquidity";
  import { MulticallSettler } from "cloud-agent/accept-settle";
  import { CloudSettlementBackend } from "cloud-agent/backend";
  import { runFillLoop, FillDirection, type FillParams } from "cloud-agent/fill-loop";
  import { populateInstruments } from "cloud-agent";

  type Args = {
    amount: number;
    maxPrice?: number;
    pollPeriod: number;
    minSettlement: number;
  };

  async function parseArgs(): Promise<Args> {
    const argv = await yargs(hideBin(process.argv))
      .option("amount", {
        type: "number",
        demandOption: true,
        describe: "Amount to buy",
      })
      .option("max_price", {
        type: "number",
        describe: "Maximum acceptable price",
      })
      .option("poll_period", {
        type: "number",
        default: 600,
        describe: "Polling period in seconds",
      })
      .option("min_settlement", {
        type: "number",
        default: 5.0,
        describe: "Minimum settlement amount",
      })
      .strict()
      .parse();

    return {
      amount: argv.amount,
      maxPrice: argv.max_price,
      pollPeriod: argv.poll_period,
      minSettlement: argv.min_settlement,
    };
  }

  async function main(): Promise<void> {
    const args = await parseArgs();

    console.info("Starting buy flow");

    // 1. Load config from .env + agent.toml
    const config = await BaseConfig.loadOrDefaults("agent.toml");

    // 2. Fetch instrument registry from orderbook-rpc
    await populateInstruments(config);

    // 3. Create backend
    const confirmLock = newConfirmLock();
    const lm = new LiquidityManager(
      config.feeReserveCc,
      config.liquidityMargin,
      config.flowEmaWindowHours,
      config.depletionMaxHours,
      config.depletionMinHours
    );

    const backend = new CloudSettlementBackend(
      structuredClone(config),
      false,
      false,
      false,
      false,
      confirmLock,
      lm
    );

    // 4. Create settler for atomic multicall settlement
    const settler = new MulticallSettler({
      config: structuredClone(config),
      amuletCache: backend.amuletCache(),
      verbose: false,
      dryRun: false,
      force: false,
      confirm: false,
      confirmLock,
    });

    // 5. Run the fill loop
    const params: FillParams = {
      direction: FillDirection.Buy,
      marketId: "CC-USDC",
      totalAmount: args.amount,
      priceLimit: args.maxPrice,
      minSettlement: args.minSettlement,
      maxSettlement: args.amount,
      intervalSecs: args.pollPeriod,
    };

    const _backendGuard = backend;

    await runFillLoop(config, settler, params, null, null);
  }

  main().catch((error) => {
    console.error("Fatal error:", error);
    process.exit(1);
  })
  ```

  ```rust Rust theme={null}
  use std::sync::Arc;
  use anyhow::{Context, Result};
  use clap::Parser;

  use agent_logic::config::BaseConfig;
  use agent_logic::confirm::new_confirm_lock;
  use agent_logic::liquidity::LiquidityManager;
  use cloud_agent::accept_settle::MulticallSettler;
  use cloud_agent::backend::CloudSettlementBackend;
  use cloud_agent::fill_loop::{self, FillDirection, FillParams};
  use cloud_agent::populate_instruments;

  #[derive(Parser)]
  struct Args {
      #[arg(long)] amount: f64,
      #[arg(long)] max_price: Option<f64>,
      #[arg(long, default_value = "600")] poll_period: u64,
      #[arg(long, default_value = "5.0")] min_settlement: f64,
  }

  #[tokio::main]
  async fn main() -> Result<()> {
      let _ = dotenvy::dotenv();
      let args = Args::parse();
      tracing_subscriber::fmt().with_env_filter("info").init();

      // 1. Load config from .env + agent.toml
      let mut config = BaseConfig::load_or_defaults("agent.toml")?;

      // 2. Fetch instrument registry (CC/USDC/…) from orderbook-rpc
      populate_instruments(&mut config).await?;

      // 3. Create backend (spawns ACS worker to keep amulet cache fresh)
      let confirm_lock = new_confirm_lock();
      let lm = LiquidityManager::new(
          config.fee_reserve_cc, config.liquidity_margin,
          config.flow_ema_window_hours,
          config.depletion_max_hours, config.depletion_min_hours,
      );
      let backend = CloudSettlementBackend::new(
          config.clone(), false, false, false, false, confirm_lock.clone(), lm,
      );

      // 4. Create settler for atomic multicall settlement
      let settler = Arc::new(MulticallSettler {
          config: config.clone(),
          amulet_cache: backend.amulet_cache().clone(),
          verbose: false, dry_run: false, force: false, confirm: false,
          confirm_lock,
      });

      // 5. Run the fill loop
      let params = FillParams {
          direction: FillDirection::Buy,
          market_id: "CC-USDC".to_string(),
          total_amount: args.amount,
          price_limit: args.max_price,
          min_settlement: args.min_settlement,
          max_settlement: args.amount,
          interval_secs: args.poll_period,
      };
      let _backend_guard = backend;
      fill_loop::run_fill_loop(config, settler, params, None, None).await
  }
  ```
</CodeGroup>

To launch the agent, run this command:

```text theme={null}
cargo run -p buy-cc-example -- --amount 10.0 --max-price 0.16 --poll-period 600
```

<Check>
  CC Buying agent is launched! Great job!
</Check>


# SDK Intro
Source: https://docs.silvana.one/sdk/introduction/sdk-intro



<Frame>
  <img alt="Sdk Main" />
</Frame>

SDK is the entry point for building agents and applications on top of Silvana Book – an ultra-fast agentic orderbook on Silvana.

The underlying communication layer is abstracted, and a clean, developer-friendly interface is provided for interacting with the orderbook and settlement flows.

<Check>
  Turn your strategy into a powerful agent. Build your edge with Silvana SDK!
</Check>

Follow the links below to guide you through Silvana SDK.

<CardGroup>
  <Card title="Silvana Book Agent" href="/sdk/introduction/silvana-book-agent">
    DvP-native trading agent on the Canton Network.
  </Card>

  <Card title="Silvana Book Agent Quickstart" href="/sdk/introduction/silvana-book-agent-quickstart">
    Learn how to add your agent (on the Silvana Book Agent sample).
  </Card>

  <Card title="Agent Sample" href="/sdk/introduction/agent-sample">
    See an example of an agent that can be deployed on Silvana.
  </Card>

  <Card title="gRPC API" href="/sdk/grpc-api/grpc-api-types">
    Get API endpoints for Silvana Book operations.
  </Card>
</CardGroup>


# Silvana Book Agent
Source: https://docs.silvana.one/sdk/introduction/silvana-book-agent



Silvana Book Agent enables automated orderbook workflows, managing orders, execution, and settlement end-to-end, powering multiple trading modes, including grid trading, RFQ, and taker execution flows.

<Check>
  Silvana Book Agent runs without direct access to the Canton ledger. All ledger operations are proxied through the Silvana gRPC service.
</Check>

Through its interaction model, the orderbook, agents, and coordination layer together enable fast off-chain execution with reliable on-chain settlement.

<Note>
  The **Coordination Layer** ensures that agents progress through settlement steps in a consistent, controlled manner and that [**Delivery-versus-Payment**](https://docs.silvana.one/how-silvana-book-ensures-security) execution is completed atomically.
</Note>

# Functions

Main functions of Silvana Book Agent include:

* Buy Canton Coins;
* Sell Canton Coins;
* Place Order;
* Accept Quote;
* DvP Settlement.

# Capacities

Silvana Book Agent offers a number of powerful features.

<Columns>
  <Column>
    <Card title="Orderbook Access" icon="angle-down">
      Submit orders, read market data, and subscribe to orderbook, order, and settlement updates.
    </Card>
  </Column>

  <Column>
    <Card title="RFQ Trading" icon="handshake">
      Agents agree on orders, compute quotes, validate balances, and respond in real time.
    </Card>
  </Column>

  <Column>
    <Card title="DvP Atomic Settlement" icon="atom-simple">
      Settlement occurs simultaneously through a single multicall. Once finished, traders exchange assets.
    </Card>
  </Column>

  <Column>
    <Card title="Grid Market Making" icon="grid">
      Limit orders are placed across configured price levels around the mid price and adjusted accordingly.
    </Card>
  </Column>

  <Column>
    <Card title="Settlement Stream" icon="signal-stream">
      A bidirectional stream handles RFQs, preconfirmations, and settlement lifecycle events.
    </Card>
  </Column>

  <Column>
    <Card title="Local Signing" icon="file-signature">
      Transactions are signed inside the agent, so the private key stays under local control.
    </Card>
  </Column>

  <Column>
    <Card title="Two-Phase Transaction Flow" icon="angles-right">
      Prepared transactions are verified before signing, reducing the risk of unintended execution.
    </Card>
  </Column>

  <Column>
    <Card title="Extensible Libraries" icon="folder-check">
      Core SDK crates can be accessed and reused to build custom agents, tools, or integrations.
    </Card>
  </Column>
</Columns>

# Sources

Here are the sources from which you get the SDK:

| **Crate** | **Key exports** |
| :- | :- |
| `agent-logic` | `BaseConfig`, `SettlementBackend` trait, `BalanceProvider` trait, `run_agent()`,<br />`LiquidityManager`, `OrderbookClient`, `OrderbookRpcClient`, `OrderTracker`,<br />`SettlementExecutor`, state persistence |
| `cloud-agent` | `CloudSettlementBackend` (impls `SettlementBackend`), `DAppProviderClient`,<br />`MulticallSettler`, `RfqHandler`, `PaymentQueue`, `AmuletCache`,<br />`fill_loop::run_fill_loop`, onboarding helpers |
| `orderbook-proto` | Generated gRPC clients + all protobuf types (`Market`, `Order`,<br />`SettlementProposal`, `TokenBalance`, …) and reflection descriptor pools |
| `message-signing` | Canonical Ed25519 signing for `DAppProviderService` RPCs<br />(`sign_canonical`,`verify_canonical`, canonical payload builders per<br />operation type) |
| `tx-verifier` | `verify_and_hash()` — independent Canton transaction verification +<br />3-layer SHA-256 hashing before signing |

<Check>
  Use the guides below to build and run your own agents on Silvana.
</Check>

<CardGroup>
  <Card title="Quickstart" href="/sdk/introduction/silvana-book-agent-quickstart">
    DvP-native trading agent on the Canton Network.
  </Card>

  <Card title="Agent Sample" href="/sdk/introduction/agent-sample">
    Learn how to add your agent (on the Silvana Book Agent sample).
  </Card>
</CardGroup>


# Silvana Book Agent Quickstart
Source: https://docs.silvana.one/sdk/introduction/silvana-book-agent-quickstart



# Installation

<Card title="Onbooard Your Agent" icon="rocket" href="/guides/quickstart/agent-onboarding">
  New to Silvana? Start with onboarding to install `cloud-agent`, create your agent identity, and prepare the initial configuration.
</Card>

# Operations

Now you're good to go. The following operations are available, and how to launch them:

## Faucet

To use the faucet, run this command:

```text theme={null}
cloud-agent faucet get --token CC      # 10,000 CC
cloud-agent faucet get --token USDC    # 1,000 USDC
cloud-agent info balance
```

## Buy CC via RFQ

Requests a quote on the `CC-USDC` market, accepts the best offer, and settles atomically via a single multicall. Repeats until the full amount is filled.

```text theme={null}
cloud-agent buy --market CC-USDC --amount 15
```

## Sell CC via RFQ

Request selling CC by running this command:

```text theme={null}
cloud-agent sell --market CC-USDC --amount 100
```

## Run as LP / market-maker

This is a long-running mode. It places grid orders on configured markets, responds to incoming RFQs, and settles DVPs end-to-end.

<Tip>
  Configured via `agent.toml`
</Tip>

To run as LP/Market-maker, enter this command:

```text theme={null}
cloud-agent agent
```

<Check>
  Use the docs below for reference to guide you as you build on Silvana.
</Check>

<CardGroup>
  <Card title="Prerequisites" href="/sdk/reference/configuration">
    See what you need to start building on Silvana.
  </Card>

  <Card title="Agent Onboarding" href="/sdk/reference/agent-onboarding">
    Learn the agent onboarding flow under the hood.
  </Card>

  <Card title="Configuration" href="/sdk/reference/configuration">
    Silvana Book Agent config doc. Nice to have for agent onboarding.
  </Card>

  <Card title="CLI Reference" href="/sdk/reference/full-cli-reference">
    A full list of CLI commands to get an agent running.
  </Card>

  <Card title="SDK Interaction Flow" href="/sdk/reference/sdk-interaction-flow">
    Read about the transaction mechanics in Silvana Book.
  </Card>

  <Card title="Trading Modes" href="/sdk/reference/trading-modes">
    Find out about the supported trading modes – Grid, RFQ, and Taker Loops.
  </Card>

  <Card title="Authentication and Signing" href="/sdk/reference/authentication-and-signature">
    Study the guidelines for authentication and signing.
  </Card>

  <Card title="Security Model" href="/sdk/reference/security-model">
    Get to know Silvana Book's security arrangements and practices.
  </Card>
</CardGroup>


# Authentication and Signing
Source: https://docs.silvana.one/sdk/reference/authentication-and-signature



Silvana Book Agent runs without direct access to the Canton ledger. Instead, ledger operations are proxied through Silvana’s gRPC service, while the agent keeps its Ed25519 private key locally and signs transactions using a two-phase flow.

We support 2 types of authentication:

1. **JWT-based authentication** for the orderbook and pricing clients.
2. **Ed25519 message signing** for ledger onboarding and transaction submission flows.


# Configuration
Source: https://docs.silvana.one/sdk/reference/configuration



# Overview

`.env` and `agent.toml` are both created by `cloud-agent onboard` — you typically don't write them from scratch. The tables below describe each field so you can tune an existing config.

# `.env `**— Environment Variables**

| **Variable** | **Description** | **Written by**`onboard` |
| :- | :- | :- |
| `PARTY_AGENT` | Your Canton party ID | yes |
| `PARTY_AGENT_PRIVATE_KEY` | Base58 Ed25519 private key (32-byte seed) | yes |
| `PARTY_AGENT_PUBLIC_KEY` | Base58 Ed25519 public key (derived from the private key) | yes |
| `ORDERBOOK_GRPC_URL` | Orderbook gRPC endpoint | yes |
| `CANTON_CHAIN` | `devnet` \| `testnet` \| `mainnet` | yes |
| `SYNCHRONIZER_ID` | Canton synchronizer ID | yes |
| `NODE_NAME` | Canton node name for routing | yes |
| `LEDGER_SERVICE_PUBLIC_KEY` | Base58 public key of the ledger service (for verifying responses) | yes |
| `DSO` | DSO (Canton Coin admin) party ID | yes |
| `PARTY_SETTLEMENT_OPERATOR` | Settlement operator party ID | yes |
| `PARTY_ORDERBOOK_FEE` | Orderbook fee collection party | yes |
| `PARTY_TRAFFIC_FEE` | Sequencer traffic fee party | yes |
| `TRAFFIC_FEE_PRICE_USD_MB` | Traffic fee rate in USD per MB | yes |
| `JOIN_TRAFFIC_TRANSACTIONS` | Batch traffic-fee transactions (default: `true`) | yes |
| `AGENT_FEE_RESERVE_CC` | CC balance held back for fees (default: `5.0`) | yes |
| `AGENT_FEE_CC` | Per-tx agent fee (CC) | yes |
| `PARTICIPANT_FEE_CC` | Per-tx participant fee (CC) | yes |
| `SIGNATURE_FEE_CC` | Per-tx signature fee (CC) | yes |
| `MERGE_THRESHOLD` | Merge worker triggers when selectable amulets exceed this count | yes |
| `MERGE_MAX_AMULETS` | Max amulets merged per round (default: `100`) | yes |
| `MERGE_POLL_INTERVAL_SEC` | Merge worker poll interval in seconds (default: `600`) | yes |
| `LOG_DESTINATION` | `console` \| `file` (paired with `LOG_DIR`, `LOG_FILE_PREFIX`) | yes |
| `RECURRING_PAYMENT_PACKAGE_NAME` | Recurring-payment package name; required for `subscription *` commands | yes |
| `SETTLEMENT_THREAD_COUNT` | Concurrent settlement threads (default used when unset) | no |
| `AGENT_MAX_SETTLEMENTS` | Max active settlements (default used when unset) | |

#### `agent.toml `**— Agent Settings**

Full example for an LP with grid orders and RFQ:

<CodeGroup>
  ```ts .toml theme={null}
  role = "trader"
  auto_settle = true
  poll_interval_secs = 7
  token_ttl_secs = 3600
  connection_timeout_secs = 30

  # Liquidity provider identity (enables RFQ handling)
  [liquidity_provider]
  name = "My LP"
  max_concurrent_rfqs = 10
  default_quote_valid_secs = 60

  [[markets]]
  market_id = "CC-USDC"
  enabled = true
  price_change_threshold_percent = 0.1

  # 3 bids below mid (negative deltas)
  [[markets.bid_levels]]
  delta_percent = -0.015
  quantity = "10"
  [[markets.bid_levels]]
  delta_percent = -0.2
  quantity = "10"
  [[markets.bid_levels]]
  delta_percent = -0.3
  quantity = "10"

  # 3 offers above mid (positive deltas)
  [[markets.offer_levels]]
  delta_percent = 0.015
  quantity = "10"
  [[markets.offer_levels]]
  delta_percent = 0.2
  quantity = "10"
  [[markets.offer_levels]]
  delta_percent = 0.3
  quantity = "10"

  # RFQ configuration for this market
  [markets.rfq]
  enabled = true
  min_quantity = "5"
  max_quantity = "1000"
  bid_spread_percent = 0.5
  offer_spread_percent = 0.5
  quote_valid_secs = 60
  allocate_before_secs = 3600
  settle_before_secs = 7200
  ```
</CodeGroup>


# Full CLI Reference
Source: https://docs.silvana.one/sdk/reference/full-cli-reference



| Command | Description |
| :- | :- |
| `agent [--settlement-only] `<br />`[--orders-only] `<br />`[--no-restore] `<br />`[--no-reject]` | Long-running LP / market-maker agent that places orders,<br />handles RFQs, and settles trades. |
| `onboard `<br />`--agent-name <NAME> `<br />`--email <EMAIL> `<br />`--invite-code <CODE>` | Self-service onboarding. Also supports `--rpc`, `--party`, <br />`--private-key`, `--env-file`, and `--poll-interval`. |
| `generate-private-key` | Generate a new Ed25519 private key, no config required. |
| `info balance` | Show token balances. |
| `info party` | Show party ID, public key, and node name. |
| `info network` | Show DSO party, rates, and mining rounds. |
| `info list [--template <ID>] `<br />`[--count]` | List active contracts, optionally filtered by template ID <br />or reduced to a count. |
| `buy --market <ID> `<br />`--amount <N> `<br />`[--price-limit <N>] `<br />`[--min-settlement <N>] `<br />`[--max-settlement <N>] `<br />`[--interval <SECS>]` | Buy via RFQ until the target amount is filled. |
| `sell --market <ID> `<br />`--amount <N> `<br />`[--price-limit <N>] `<br />`[--min-settlement <N>] `<br />`[--max-settlement <N>] `<br />`[--interval <SECS>]` | Sell via RFQ until the target amount is filled. |
| `faucet get --token <TOKEN> `<br />`[--admin <P>] `<br />`[--ticket <TICKET>] `<br />`[--amount <N>] `<br />`[--dry-run]` | Request faucet tokens. `CC` / `Amulet` default admin<br />to DSO. Other tokens use registry lookup or explicit <br />`--admin`. |
| `transfer send-cc `<br />`--receiver <P> `<br />`--amount <N> `<br />`[--description <TEXT>] `<br />`[--memo-uuid]` | Send Canton Coin to another party. |
| `transfer send-cip56 `<br />`--receiver <P> `<br />`--instrument-id <ID> `<br />`--instrument-admin <P> `<br />`--amount <N> `<br />`[--reference <REF>]` | Send a CIP-56 token. |
| `transfer accept-cip56 `<br />`--contract-id <CID>` | Accept an incoming CIP-56 transfer offer. |
| `transfer split-cc `<br />`--output-amounts a,b,c `<br />`--amulet-cids x,y` | Split CC into multiple amulets. |
| `transfer batch-pay `<br />`[--receiver <P> `<br />`--amount <N>]... `<br />`[--file <CSV>] `<br />`[--description <TEXT>] `<br />`[--amulet-cids x,y]` | Batch CC payments atomically via multicall, either from <br />CLI args or a CSV file. |
| `preapproval request `<br />`--instrument-admin <P>` | Create a CIP-56 `TransferPreapproval`. |
| `preapproval fetch` | List existing preapprovals. |
| `subscription request-prepaid `<br />`[--amount <USD>] `<br />`[--limit <USD>] `<br />`[--locked-amount <USD>] `<br />`[--lock-days <DAYS>] `<br />`[--description <TEXT>] `<br />`[--reference <REF>]` | Request a prepaid recurring payment. |
| `subscription request-payasyougo `<br />`[--app <P>] `<br />`[--amount <USD>] `<br />`[--description <TEXT>] `<br />`[--reference <REF>]` | Request a pay-as-you-go subscription. |
| `user-service request `<br />`[--reference-id <REF>] `<br />`[--party-name <NAME>]` | Request a `UserService` contract for onboarding or setup. |
| `lock holdings ...` | Lock holdings via `LockService.LockHoldings`. <br />Requires lock service contract details, amount, <br />instrument ID, and fee inputs. |
| `lock vote ...` | Process voting lock / unlock requests on `LockController`. <br />Requires controller details, requests JSON, and fee inputs. |
| `lock resize ...` | Resize a lock amount on `LockController`. <br />Requires controller details, new amount, instrument ID, <br />and fee inputs. |
| `lock terminate ...` | Terminate a lock on `LockController`. Requires <br />controller details and fee inputs. |
| `sign multihash --input <B64> `<br />`[--private-key <KEY>]` | Sign a Canton 34-byte multihash. |
| `sign message --input <TEXT> `<br />`[--private-key <KEY>]` | Sign a UTF-8 text message. |
| `sign binary --input <HEX> `<br />`[--private-key <KEY>]` | Sign hex-encoded binary data. |


# Onboarding Flow
Source: https://docs.silvana.one/sdk/reference/onboarding-flow



The `onboard` command performs 11 steps automatically:

1. Load or generate an Ed25519 keypair (written to `.env` as `PARTY_AGENT_PRIVATE_KEY`).
2. Connect to the orderbook RPC (raw gRPC, no auth yet).
3. Fetch server configuration (`GetAgentConfig`) → write `.env` and seed `agent.toml`.
4. Register on the waiting list (`RegisterAgent`, signed).
5. Poll for `SIGNATURE_REQUIRED` status.
6. Fetch and sign the Canton topology multihash.
7. Submit the signature (`SubmitOnboardingSignature`).
8. Poll until `TOPOLOGY_CREATED`; write `PARTY_AGENT` to `.env`.
9. Create Splice `TransferPreapproval` for CC (pending operator acceptance).
10. Create one CIP-56 `TransferPreapproval` per non-DSO registrar discovered from `GetInstruments`.
11. Request a `UserService` and (on devnet) auto-faucet CC + USDC.

# Flags

| **Flag** | **Description** |
| :- | :- |
| `--rpc <URL>` | Orderbook gRPC endpoint (default devnet) |
| `--agent-name <NAME>` | Display name (required) |
| `--email <EMAIL>` | Contact email (required) |
| `--invite-code <CODE>` | Waiting list invite code (required) |
| `--party <ID>` | Skip waiting list (requires `--private-key`) |
| `--private-key <B58>` | Base58-encoded Ed25519 private key |
| `--env-file <PATH>` | Path to .env file (default: `.env`) |
| `--poll-interval <SECS>` | Polling interval during onboarding (default: 10) |


# Prerequisites
Source: https://docs.silvana.one/sdk/reference/prerequisites



Make sure you have this as you start:

* [<u>Rust</u>](https://rustup.rs/) (stable toolchain)
* Protocol Buffers compiler: `apt install protobuf-compiler` (Linux) or `brew install protobuf` (macOS)
* Silvana orderbook RPC endpoint URL and an invite code (provided by Silvana)


# SDK Interaction Flow
Source: https://docs.silvana.one/sdk/reference/sdk-interaction-flow



# SDK Interaction Flow

Trading logic stays inside the agent, while transaction preparation, verification, signing, and submission follow a controlled flow.

<Steps>
  <Step title="Connect">
    The agent loads its configuration and connects to the Silvana orderbook server through the required gRPC services.
  </Step>

  <Step title="Trade">
    The agent reads market data, submits orders, processes RFQs when configured, and reacts to orderbook or settlement events.
  </Step>

  <Step title="Verify and Sign">
    For ledger-mutating actions, the server prepares the transaction, and the agent verifies the transaction before signing it locally.
  </Step>

  <Step title="Execute and Settle">
    The signed transaction is sent back to the service, submitted to Canton, and finalized through the DvP settlement flow.
  </Step>
</Steps>

# Two-Phase Transaction Flow

All ledger-mutating operations use a two-phase signing protocol:

1. Agent calls `PrepareTransaction` with an operation type and parameters.
2. Server returns the full `prepared_transaction` bytes and a hash.
3. Agent uses `tx-verifier` to independently verify the transaction matches the requested operation (correct template, parties, amounts).
4. Agent signs the hash locally with its Ed25519 private key.
5. Agent calls `ExecuteTransaction` with the signature.
6. Server submits the signed transaction to the Canton ledger.

Supported operation types include: `TRANSFER_CC`, `TRANSFER_CIP56`, `ACCEPT_CIP56`, `PAY_DVP_FEE`, `PROPOSE_DVP`, `ACCEPT_DVP`, `PAY_ALLOC_FEE`, `ALLOCATE`, `EXECUTE_MULTICALL`, `SPLIT_CC`, `REQUEST_PREAPPROVAL`, `REQUEST_RECURRING_PREPAID`, `REQUEST_RECURRING_PAYASYOUGO`, `REQUEST_USER_SERVICE`, `LOCK_HOLDINGS`, `PROCESS_LOCK_UNLOCK_REQUESTS`, `RESIZE_LOCK`, `TERMINATE_LOCK`.


# Security Model
Source: https://docs.silvana.one/sdk/reference/security-model



Silvana ensures security by:

* **Two-phase signing**: the server prepares a transaction and returns the bytes and a hash. The agent independently recomputes the hash, verifies the transaction with `tx-verifier`, and only then signs.
* **Transaction verification**: before signing, `tx-verifier` checks that the prepared transaction matches the requested operation (correct template, parties, amounts). This prevents the server from tricking the agent into signing unexpected transactions.
* **Ed25519 JWT authentication**: self-describing JWTs embed the Ed25519 public key (RFC 8037); the server verifies the public key fingerprint matches the party ID.
* **Private key isolation:** the Ed25519 private key is used only locally for signing transaction hashes and JWTs. It is never transmitted to the server.


# Trading Modes
Source: https://docs.silvana.one/sdk/reference/trading-modes



There are 3 trading modes that are currently supported: **Grid Mode**, **Request for Quote (RFQ)**, and **Taker Fill Loops**.

# Grid Mode

In this mode, multiple bid and ask orders are placed. across preset price levels.

When `agent` runs, it places limit orders on a grid of price levels around the current mid price.

Each level is defined by:

* `delta_percent` — signed offset from mid price in percent. Bids use negative values (below mid), offers use positive values (above mid). E.g. `-0.5` on a bid = 0.5% below mid; `0.3` on an offer = 0.3% above mid.
* `quantity` — order size at this level

When the mid price moves by more than `price_change_threshold_percent`, all grid orders are cancelled and re-placed at updated levels.

# RFQ

Quotes from liquidity providers are requested and executed against the best available quote. This mode best suits large-scale corporate trades on substantial amounts.

When `[liquidity_provider]` is configured, the agent connects to the orderbook server via a bidirectional gRPC stream (`SettlementStream`) and receives RFQ requests in real time.

This is a typical RFQ quote flow:

1. Agent connects and sends a handshake identifying the LP.
2. Server routes incoming RFQ requests to the LP.
3. Agent computes a quote price from the mid price and configured spread:
   * **Buy request** (user buys, LP sells): `price = mid * (1 + offer_spread_percent / 100)`
   * **Sell request** (user sells, LP buys): `price = mid * (1 - bid_spread_percent / 100)`
4. Agent validates quantity against `min_quantity` / `max_quantity` and checks balance via `LiquidityManager`.
5. Agent responds with a quote (price, quantity, validity window, settlement deadlines) or a rejection.

<Danger>
  Rejection reasons may include the following:

  * market disabled,
  * RFQ disabled for market,
  * quantity out of range,
  * no mid-price yet,
  * insufficient balance.
</Danger>

Each quote must include:

* `allocate_before_secs` — seconds from DVP creation to allocate tokens (default: 3600)
* `settle_before_secs` — seconds from DVP creation to complete settlement (default: 7200)

# Taker Fill Loops

Buy or sell RFQ orders are executed in chunks until the target amount is fully filled. This is an instance of an RFQ trade with an exceptionally high amount of funds.

Each accepted quote is settled atomically via a single multicall (`Accept_Dvp + Allocate + fees + traffic`).

```text theme={null}
# Buy 10 CC, chunked 0.5-5.0 per round, 60s interval between retries
cloud-agent buy --market CC-USDC --amount 10 \
  --min-settlement 0.5 --max-settlement 5.0 --interval 60

# Sell 10 CC with price floor
cloud-agent sell --market CC-USDC --amount 10 --price-limit 0.14
```

## `buy` and `sell` Flags

| **Flag** | **Description** |
| :- | :- |
| `--market <ID>` | Market ID (e.g. `CC-USDC`) |
| `--amount <N>` | Total amount to fill (base instrument) |
| `--price-limit <N>` | Max (buy) or min (sell) price per unit — default: mid ± 3% |
| `--min-settlement <N>` | Minimum per-round size (default: 5.0) |
| `--max-settlement <N>` | Maximum per-round size (default: total amount) |
| `--interval <SECS>` | Retry interval when no quote arrives (default: 60) |

## `agent` mode flags

| **Flag** | **Description** |
| :- | :- |
| `--settlement-only` | Disable order placement, only settle existing trades |
| `--orders-only` | Disable settlement, only place/manage grid orders |
| `--no-restore` | Skip loading previous state from `agent-state.json` |
| `--no-reject` | Accept all proposals without RFQ-state verification |
| `--dry-run` | Prepare and verify transactions without signing or executing |
| `--force` | Sign and execute even if verification fails |
| `--confirm` | Prompt for confirmation before signing each transaction |
| `--verbose` | Enable verbose logging |
| `--config <PATH>` | Path to agent.toml (default: `agent.toml`) |


# Supported Trading Strategies
Source: https://docs.silvana.one/silvana-book/for-traders/supported-trading-strategies

An overview of automated approaches available through Silvana Book.

Silvana’s Book agents enable a number of trading strategies.

<Callout icon="arrows">
  Each strategy may use one or more agents. Explore its available implementations, templates, and demos in [Agent Space](https://app.silvana.one/agents).
</Callout>

| **Strategy** | **Execution Pattern** | Status |
| - | - | - |
| **Market Making** | Limit orders are placed on both buy and sell sides. | <Badge icon="circle-check">Supported</Badge> |
| **Grid Trading** | A grid of standing limit buy or sell orders is <br />submitted across a price range. | <Badge icon="circle-check">Supported</Badge> |
| **RFQ (Request for Quote)** | Quotes from liquidity providers are requested and<br /> executed against the best available quote. | <Badge icon="circle-check">Supported</Badge> |
| **Taker Fill Loops** | Buy or sell RFQ orders are executed in chunks <br />until the target amount is fully filled. | <Badge icon="circle-check">Supported</Badge> |
| **Spot Grid** | Places bids and offers at fixed price levels <br />around the mid price. | <Badge icon="circle-check">Supported</Badge> |
| **Portfolio Rebalancing** | Trades assets to maintain configured portfolio weights. | <Badge icon="circle-check">Supported</Badge> |
| **Infinite Grid** | Maintains a grid without a fixed price range, <br />regenerating orders as the market moves. | <Badge icon="circle-check">Supported</Badge> |
| **Spread Capture** | Maintains a bid and offer around the market <br />price to capture the bid–ask spread. | <Badge icon="circle-check">Supported</Badge> |
| **Spot DCA** | Places periodic spot orders to accumulate an <br />asset gradually over time. | <Badge icon="circle-check">Supported</Badge> |
| **Mean Reversion** | Trades when the mid price diverges from and <br />returns toward a rolling reference value. | <Badge icon="circle-check">Supported</Badge> |
| **Trend Following** | Opens positions based on EMA crossover signals <br />and follows the resulting market direction. | <Badge icon="circle-check">Supported</Badge> |
| **Arbitrage** | Detects and trades price differences between external<br />venues and Canton markets. | <Badge icon="circle-check">Supported</Badge> |
| **Pairs Trading** | Trades two related markets when the spread between <br />them deviates from its expected range. | <Badge icon="circle-check">Supported</Badge> |
| **Copy Trading** | Mirrors the order flow of a selected trading party. | <Badge icon="circle-check">Supported</Badge> |
| **DCA Portfolio** | Runs a DCA strategy across multiple configured markets. | <Badge icon="circle-check">Supported</Badge> |
| **Yield Rotation** | Reallocates assets between markets based on <br />risk-adjusted return signals. | <Badge icon="circle-check">Supported</Badge> |


# Early Bird Program
Source: https://docs.silvana.one/silvana-book/introduction/early-bird-program



<Warning>
  **The Early Bird Program has ended since the release of Silvana V2 on 26.06.2026. You can continue using Silvana through the main app.**

  **Thanks to all early birds for your active participation!**
</Warning>

<Frame>
  <img alt="Image" />
</Frame>

# Silvana Book is opening its first chapter – and you are invited to be part of it!

The [**Early Bird Program**](https://join.silvana.one/) grants exclusive early access to Silvana Book before the wider public launch. Participate in the foundation stage of a private, high-performance trading environment!

This is your opportunity to get in before everyone else and earn rewards as an early user of the orderbook.

# What Early Bird Participants Receive

Participants enter the trading environment in early-access mode and receive whitelisted status after onboarding and completing verification requirements.

Early Bird access offers:

* It's the only way to get **pre-launch access** to Silvana Orderbook in the next 1-2 months;
* **Extra reward bonuses** for early participants;
* **Early exposure** to upcoming features;
* **More privileges** to be announced.

<Check>
  Early Bird participants may also qualify for stage-based activity rewards. Rewards are allocated based on **successfully settled** transactions and overall activity, with additional perks for the most active early users.
</Check>

# Start Early

## 1. Complete Onboarding

To access the Early Bird Program, you must complete the full [onboarding process](/silvana-book/introduction/get-started/onboarding).

For more detailed information, read the [**Onboarding FAQ**](/silvana-book/introduction/faqs).

Once approved, your account is marked as **Whitelisted,** and you can proceed to purchase your **Early Bird Ticket**!

## 2. Connect Wallet

Before purchasing the Early Bird Ticket:

* Connect a supported wallet
* Confirm wallet authorization

Wallet connection enables settlement and platform interaction.

<Note>
  Whitelisting can take up to 1 day, so you'll have to wait.
</Note>

## 3. Purchase an Early Bird Ticket

You can buy a ticket or get one for free with a [promo code](/silvana-book/introduction/faq/promo-code) from one of our partners.

<img alt="Ticket" />

> An Early Bird ticket costs 15 CC. During platform use, transaction fees may also apply depending on the type of operation.

After purchase:

* Access is granted immediately
* Confirmation screen appears

<Check>
  There you go! Now you can explore and use Silvana Book's functions! Enjoy your trading experience and have fun!
</Check>

## Support

If you have trouble creating or accessing an account, [contact us](https://t.me/silvana_chat). The Silvana team can assist with account-related questions or access problems.

<Warning>
  Occasional network congestion or delayed confirmations may affect transaction speed. During this stage, fees may be higher or vary depending on current network throughput and the DvP settlement flow.

  At the early stages, we try to compensate early users for the paid fees! This is our reward for the time you spent testing Silvana Book.
</Warning>

# We want you to be our early bird!


# Claim Points
Source: https://docs.silvana.one/silvana-book/introduction/earn-hub/claim-points



Turn your Earn Hub points into USD Stablecoin and receive the converted amount in your connected wallet.

<Callout icon="message-check">
  The Initial Point Claim will take place in two waves. The first wave will cover Early Bird participants who registered before **June 26** and points earned before that date. The second wave will open claiming to additional users, with new claimable amounts added after each season.
</Callout>

<Callout icon="message-check">
  The minimum amount for a single claim is **1,000 points**. While your claimable balance stays below this threshold, the points remain in Earn Hub until you reach it.
</Callout>

Any points not converted during the current stage will remain in your Earn Hub balance and can be claimed later.

### Before You Claim

* Make sure a wallet is connected to enable the Claim Points button.
* The connected wallet must be linked to the same Silvana account.
* Converted USD Stablecoin will be sent to this wallet.

<Warning>
  The conversion rate is not fixed. The rate applied to each claim may differ, which can affect the final USD Stablecoin amount.
</Warning>

# Convert Your Points

<Steps>
  <Step title="Click Claim Points">
    Open the [Earn Hub dashboard](/silvana-book/introduction/earn-hub/earn-hub) and click the **Claim Points** button. 
  </Step>

  <Step title="Enter the Amount">
    Set the amount of points you want to convert.

    <img alt="Claim 2 Step 1" title="Claim 2 Step 1" />
  </Step>

  <Step title="Review the Conversion">
    Review the conversion details, then click **Convert Points** to continue.

    <img alt="Claim 3 Step 1" title="Claim 3 Step 1" />
  </Step>

  <Step title="Confirm Your Conversion">
    Make sure the amount and receiving wallet are correct, then click **Confirm Conversion**.

    <img alt="Claim 4 Step 1" title="Claim 4 Step 1" />
  </Step>

  <Step title="Follow the Conversion Status">
    Once confirmed, your conversion request is submitted for processing and will be completed within **3 days**.

    You can follow its progress in **Claim History** or through the **Notification Center**.

    <img alt="Claim 5 Step" title="Claim 5 Step" />

    <Accordion title="Claim Notifications">
      Claim updates are also sent to the **Notification Center**, so you can follow the conversion without returning to Claim History.

      <img alt="Claim Notifications" />

      | **Notification** | **Meaning** |
      | - | - |
      | **Points conversion submitted** | Your conversion request has been submitted and is currently **pending**. |
      | **Claim received** | Your conversion has been **claimed**, and the USD Stablecoin has been credited to your wallet. |
      | **Points conversion declined** | Your conversion was **rejected**, and the points were returned to your Earn Hub balance. |
    </Accordion>
  </Step>
</Steps>

# Claim History

Every conversion request is recorded in Claim History, where you can check the converted amount, current status, receiving wallet, and claim date.

<img alt="Claim History New" />

### Conversion Statuses

| **Status** | **Description** |
| - | - |
| **Pending** | Your conversion request has been submitted and is still being processed. The request is expected to be completed within **3 days**. |
| **Claimed** | The conversion is complete, and the USD Stablecoin has been credited to your wallet. |
| **Rejected** | The conversion was not completed. The points used for the request are returned to your Earn Hub balance, so you can try again. |

## Read More

<Columns>
  <Column>
    <Card title="How to Earn" href="/silvana-book/introduction/earn-hub/how-to-earn">
      Explore every way to earn through Earn Hub activities
    </Card>

    <Card title="Terminal" href="/silvana-book/introduction/terminal">
      Discover Silvana Terminal and learn how to use its key trading features.
    </Card>
  </Column>

  <Column>
    <Card title="Earn Hub Dashboard" href="/silvana-book/introduction/earn-hub/earn-hub">
      Learn about the Earn Hub Dashboard and how its main sections work.
    </Card>

    <Card title="Portfolio" href="/silvana-book/introduction/portfolio">
      View your supported assets, balances, and positions across Silvana.
    </Card>
  </Column>
</Columns>


# Earn Hub Dashboard
Source: https://docs.silvana.one/silvana-book/introduction/earn-hub/earn-hub



[**Earn Hub**](https://app.silvana.one/earn-hub) is Silvana Book’s reward space, where your trading activity turns into points, progress, and rewards.

Stay active, and Earn Hub records your progress in the current round while showing your results and your next steps.

<Callout icon="lightbulb-on">
  In Earn Hub, activity is organized into [**seasons**](/silvana-book/introduction/earn-hub/seasons). Each season is a fixed period during which your trading activity, tasks, and leaderboard position are tracked and combined into a final result.
</Callout>

# Dashboard

The Earn Hub dashboard gives you a quick view of your current earning opportunities and overall progress. Your achievements also appear as icons next to your account, highlighting your progress and milestones at a glance.

<img alt="Earn Hub Dashboard New 1" />

<Callout icon="info">
  [Claim Points](/silvana-book/introduction/earn-hub/claim-points) button lets you convert available Earn Hub points into USD Stablecoin and send the converted amount to your connected wallet. Use the button when you are ready to claim available points.
</Callout>

| Section | Description |
| - | - |
| **Tasks** | See available [platform](/silvana-book/introduction/earn-hub/platform-tasks), [social](/silvana-book/introduction/earn-hub/social-campaigns), and [partner](/silvana-book/introduction/earn-hub/partner-tasks) tasks, and monitor your progress as you complete them. |
| **History** | <Badge>being updated</Badge> |
| [**Referrals**](/silvana-book/introduction/earn-hub/referrals) | Share your personal referral link, follow invited users, and check rewards earned through the referral program. |

# History

<Warning>
  We’re currently reworking the History section to make it more useful and easier to follow. A refreshed version is on the way.
</Warning>

# All Activity

The All Activity section brings every account operation into one table, including swaps, buys, sells, and claims, with key details shown in one place.

Use the filters above the table to narrow the list by operation type or wallet, making it easier to find and review specific activity.

<img alt="Earnhub All Activity 1" />

# Where rewards come from

The system tracks multiple indicators of participation, including:

* successfully settled transactions
* trading activity
* trading volume
* completed achievements
* leaderboard position.

Rewards are calculated based on these metrics and distributed periodically at the end of each program round. Read more about rewards [here](/silvana-book/introduction/faqs).

<Warning>
  Only **successfully settled transactions** count toward rewards. Failed transactions are not rewarded.

  Make sure preapproval is enabled for the relevant asset in your wallet to avoid reward delivery issues.
</Warning>


# How to Earn
Source: https://docs.silvana.one/silvana-book/introduction/earn-hub/how-to-earn



Trading is only the beginning. Earn Hub brings together every opportunity to participate, complete activities, and unlock benefits across the Silvana ecosystem.

<Card title="Join Seasonal Activities" icon="trophy" href="https://app.silvana.one/earn-hub/maximize-returns">
  Every season brings new goals, activities, and opportunities to earn. Stay active and maximize your progress before the season ends.
</Card>

# Start Earning with Silvana Book

Whether you're new to Silvana Book or already an active user, there's always another way to participate. Explore the options below and find what suits you best.

<CardGroup>
  <Card title="Platform Tasks" icon="list-check" href="/silvana-book/introduction/earn-hub/platform-tasks">
    Complete trading and platform activities available in [Earn Hub](/silvana-book/introduction/earn-hub/earn-hub).

    * Trading milestones
    * Product activities
    * Regular reward opportunities
  </Card>

  <Card title="Promo Codes" icon="ticket" href="/silvana-book/introduction/faq/promo-code">
    Redeem campaign or partner promo codes to receive exclusive benefits.

    * Campaign rewards
    * Account subsidies
    * Extra points
  </Card>

  <Card title="Social Campaigns" icon="megaphone" href="/silvana-book/introduction/earn-hub/social-campaigns">
    Participate in community events and social activities announced by Silvana.

    * Community challenges
    * [X](https://x.com/silvana_book), [Telegram](https://t.me/silvana_chat), and [Discord](https://discord.com/invite/CVuVruNsd) activities
    * Seasonal events
  </Card>

  <Card title="Partner Tasks" icon="handshake" href="/silvana-book/introduction/earn-hub/partner-tasks">
    Complete joint campaigns across the Silvana ecosystem.

    * Trading partner assets & hot pairs
    * Cross-platform activities
    * Exclusive campaign rewards
  </Card>

  <Card title="Referrals" icon="users" href="/silvana-book/introduction/earn-hub/referrals">
    Share your referral link and receive rewards when eligible users join Silvana.

    * Personal referral link
    * Referral rewards
    * Long-term program benefits
  </Card>
</CardGroup>


# Partner Tasks
Source: https://docs.silvana.one/silvana-book/introduction/earn-hub/partner-tasks



Partner Tasks are collaborative activities created together with projects building alongside Silvana.

Every campaign tells a different story. Some focus on trading, others on exploration or community participation, giving you new ways to engage while earning additional benefits.

<CardGroup>
  <Card title="Discover New Assets" icon="coins">
    Explore markets and trading pairs introduced via ecosystem collaborations.
  </Card>

  <Card title="Join Collaborative Campaigns" icon="handshake">
    Participate in activities created with projects across the Silvana ecosystem.
  </Card>

  <Card title="Unlock Exclusive Benefits" icon="gift">
    Access rewards and bonuses available through selected partner campaigns.
  </Card>

  <Card title="Experience New Products" icon="rocket">
    Be among the first to interact with new launches and ecosystem initiatives.
  </Card>
</CardGroup>

# Discover New Opportunities

Browse the current partner tasks available in **Earn Hub → Tasks → Partner**. Each activity is built around a different collaboration and includes its own objectives, participation requirements, and available benefits.

<Frame>
  <img alt="Partner Tasks" />
</Frame>

## There's Always Something New

Each [season](/silvana-book/introduction/earn-hub/seasons) introduces fresh collaborations and new partner tasks to explore. Check Earn Hub regularly so you don't miss the next opportunity.

<Columns>
  <Column>
    <Card title="How to Earn" href="/silvana-book/introduction/earn-hub/how-to-earn">
      Explore every available earning opportunity
    </Card>

    <Card title="Promo Codes" href="/silvana-book/introduction/faq/promo-code">
      Redeem codes and unlock exclusive benefits
    </Card>
  </Column>

  <Column>
    <Card title="Social Campaigns" href="/silvana-book/introduction/earn-hub/social-campaigns">
      Join community activities and seasonal events
    </Card>

    <Card title="Referral Program" href="/silvana-book/introduction/earn-hub/referrals">
      Invite friends and earn together
    </Card>
  </Column>
</Columns>


# Platform Tasks
Source: https://docs.silvana.one/silvana-book/introduction/earn-hub/platform-tasks



Platform Tasks reward you for using Silvana Book as part of your everyday trading. Instead of requiring additional actions outside the platform, these tasks focus on the activity you already perform: placing trades, exploring markets, and staying active over time.

<Callout icon="file-circle-info">
  Most tasks are completed automatically. As you continue trading, [Earn Hub](/silvana-book/introduction/earn-hub/earn-hub) tracks eligible activity in the background and updates your progress without requiring any manual submission.
</Callout>

<Frame>
  <img alt="Image" />
</Frame>

# Categories

Whether you're placing your first trade or building a long trading streak, there's always a new challenge to complete. Explore the task categories below and discover different ways to stay active on Silvana Book.

<CardGroup>
  <Card title="Getting Started" icon="rocket">
    Complete your first activities and become familiar with Silvana Book.

    * First trades
    * Explore supported assets
    * Learn the basics
  </Card>

  <Card title="Trading Milestones" icon="flag">
    Reach trading goals as your platform activity grows.

    * Trade different assets
    * Complete trading objectives
    * Expand your experience
  </Card>

  <Card title="Daily Challenges" icon="calendar-days">
    Take on short-term goals designed to reward daily activity.

    * Daily objectives
    * Time-limited tasks
    * Frequent point opportunities
  </Card>

  <Card title="Long-Term Activity" icon="chart-line">
    Build consistent trading habits through recurring challenges.

    * Weekly activity
    * Monthly activity
    * Consistency rewards
  </Card>
</CardGroup>


# Referrals
Source: https://docs.silvana.one/silvana-book/introduction/earn-hub/referrals



Share your personal referral details, track referral activity, and see how your network contributes to your Earn Hub rewards.

<Callout icon="people-arrows">
  The Referrals tab keeps the entire invitation flow in one place. You can copy your referral details, share a QR code, follow each referral, and check how much activity your invited friends generate.
</Callout>

# **Earn by Inviting Friends**

<Steps>
  <Step title="Share Your Referral">
    Open Earn Hub, go to Referrals, then copy your referral link or code. You can also click Invite Friends to share a QR code.

    <Frame>
      <img alt="Silvana Earn Hub Update (1)" />
    </Frame>

    <Accordion title="Summary of Invitations">
      The Summary of Invitations panel gives you a quick overview of your referral performance over different time periods. Review invited users, total activity, rewards earned, and how many referred users have started trading.
    </Accordion>
  </Step>

  <Step title="Use an Invite">
    A referral must be applied when a new Silvana account is created.

    * **Referral link or QR code:** the referral code is added automatically.
    * **Referral code:** paste the copied code into the corresponding field.

    <Frame>
      <img alt="Referrals" />
    </Frame>
  </Step>

  <Step title="Monitor Activity">
    Open Referral Activity to view invited accounts, eligible trading activity, and referral earnings.

    <Note>
      Referral earnings are generated from eligible activity, so inviting a user alone does not generate rewards.
    </Note>

    <Frame>
      <img alt="Activity Ref" />
    </Frame>
  </Step>
</Steps>

<Warning>
  Rewards come from points earned for eligible trades, not from trade volume. Only trading points are considered – points from tasks, achievements, and other activities do not generate referral rewards.
</Warning>

## Read More

<Columns>
  <Column>
    <Card title="How to Earn" href="/silvana-book/introduction/earn-hub/how-to-earn">
      Explore every way to earn through Earn Hub activities
    </Card>

    <Card title="Promo Codes" href="/silvana-book/introduction/faq/promo-code">
      Redeem codes for exclusive rewards and benefits
    </Card>
  </Column>

  <Column>
    <Card title="Social Campaigns" href="/silvana-book/introduction/earn-hub/social-campaigns">
      Complete community activities and earn rewards
    </Card>

    <Card title="Partner Tasks" href="/silvana-book/introduction/earn-hub/partner-tasks">
      Explore collaborations across the Silvana ecosystem
    </Card>
  </Column>
</Columns>


# Seasons
Source: https://docs.silvana.one/silvana-book/introduction/earn-hub/seasons



Earn Hub tracks platform activity through **seasons** – fixed periods that consolidate your trading activity, completed tasks, and leaderboard results into a single overall outcome.

Participation happens through your regular activity on Silvana Book. During a season, your swap transactions count toward progress, so staying active throughout the period matters. Based on the updates shared in the community, each period is announced with its own dates, and new seasons continue as the program moves forward.

<Callout icon="bell-ring">
  For the latest schedule, status changes, and reward updates, users should follow Silvana’s [**official channels**](https://docs.silvana.one/faq).
</Callout>

| **Season** | Starts (UTC) | Ends (UTC) | **Status** | **Reward distribution** |
| :- | :- | :- | :- | :- |
| Season 1 | March 1 | March 14 | Finished | Finished |
| Season 2 | March 15 | March 31 | Finished | Finished |
| Season 3 | April 1 | April 14 | Finished | Finished |
| Season 4 | April 15 | April 30 | Finished | Finished |
| Season 5 | May 1 | May 14 | Finished | Finished |
| Season 6 | May 15 | May 31 | Finished | Finished |
| Season 7 | June 1 | June 14 | Finished | Finished |
| Season 8 | June 15 | June 30 | Finished | Finished |
| Season 9 | July 3 | July 14 | Finished | Finished |
| Season 10 | July 15 | July 31 | Finished | Finished |
| Season 11 | August 1 | August 14 | Finished | Finished |
| Season 12 | August 15 | August 31 | Finished | Finished |
| Season 13 | September 1 | September 14 | Finished | Soon |
| Season 14 | September 15 | September 30 | Finished | Soon |
| Season 15 | To be announced | To be announced | Paused | - |


# Social Campaigns
Source: https://docs.silvana.one/silvana-book/introduction/earn-hub/social-campaigns



Social Campaigns are community-driven initiatives that help introduce Silvana to new audiences while rewarding users for participating.

Campaigns may be organized with regional communities, ecosystem projects, or social platforms and can include announcements, code drops, community activities, and social quests.

# Ways to Participate

## 1. Follow Campaign Communities

Community сampaigns take place across Silvana’s [official channels](/silvana-book/introduction/get-started/useful-links) and the groups of collaborating communities.

<Callout icon="pencil">
  Stay updated on Silvana on [**X**](https://x.com/silvana_book), [**Telegram**](https://t.me/silvana_chat), and [**Discord**](https://discord.com/invite/CVuVruNsd) channels to catch new announcements, campaign updates, code drops, and limited-time activities.
</Callout>

Do not forget to share your Earn Hub progress with friends and community members directly on socials. Celebrate your results, invite others to join the campaign, and keep participating to unlock more achievements!

<Frame>
  <img alt="Social Achievements" />
</Frame>

## 2. Complete Social Tasks

Open the Social tab in Earn Hub and explore the available campaigns. Select one that interests you, read the requirements, complete the activities, and claim your rewards after verification.

<Frame>
  <img alt="Image" />
</Frame>

## Read More

<Columns>
  <Column>
    <Card title="How to Earn" href="/silvana-book/introduction/earn-hub/how-to-earn">
      Explore every way to earn through Earn Hub activities
    </Card>

    <Card title="Partner Tasks" href="/silvana-book/introduction/earn-hub/partner-tasks">
      Explore collaborations across the Silvana ecosystem
    </Card>
  </Column>

  <Column>
    <Card title="Promo Codes" href="/silvana-book/introduction/faq/promo-code">
      Redeem codes for exclusive rewards and benefits
    </Card>

    <Card title="Referral Program" href="/silvana-book/introduction/earn-hub/referrals">
      Invite friends and grow your rewards together
    </Card>
  </Column>
</Columns>


# Promo Codes
Source: https://docs.silvana.one/silvana-book/introduction/faq/promo-code



Promo codes apply a predefined bonus to a new Silvana Book account. The code is redeemed during registration, while the available benefit and eligibility conditions depend on the campaign or partner that issued it.

<Callout icon="bell-ring">
  Active codes may be distributed through official Silvana [community chats](/silvana-book/introduction/get-started/useful-links), campaign announcements, and partner activities. Availability may be limited, so always check the conditions shared with the code.
</Callout>

## How to Apply a Promo Code

<Steps>
  <Step title="Create an Account">
    Open the [Silvana App](https://app.silvana.one/login) and select Create account.
  </Step>

  <Step title="Fill in Your Details">
    Enter your first name, last name, email, and country of residence.
  </Step>

  <Step title="Enter the Promo Code">
    Enter the code exactly as provided in the **Campaign Code** field.

    <Frame>
      <img alt="Image" title="Image" />
    </Frame>
  </Step>

  <Step title="Finish Registration">
    Complete the remaining registration steps. Once your account is created, the promo code will be applied automatically.

    <Tip>
      The bonus type, amount, timing, and eligibility conditions may differ between [campaigns](/silvana-book/introduction/earn-hub/social-campaigns). There is no universal bonus value for all promo codes; the relevant campaign or partner announcement remains the source of truth.
    </Tip>
  </Step>
</Steps>

## Read More

<Columns>
  <Column>
    <Card title="How to Earn" href="/silvana-book/introduction/earn-hub/how-to-earn">
      Explore every way to earn through Earn Hub activities
    </Card>

    <Card title="Partner Tasks" href="/silvana-book/introduction/earn-hub/partner-tasks">
      Explore collaborations across the Silvana ecosystem
    </Card>
  </Column>

  <Column>
    <Card title="Social Campaigns" href="/silvana-book/introduction/earn-hub/social-campaigns">
      Complete community activities and earn rewards
    </Card>

    <Card title="Referral Program" href="/silvana-book/introduction/earn-hub/referrals">
      Invite friends and grow your rewards together
    </Card>
  </Column>
</Columns>


# FAQs
Source: https://docs.silvana.one/silvana-book/introduction/faqs



This page brings the most useful Silvana Book questions into one place.

## About Silvana Platform

<AccordionGroup>
  <Accordion title="What is Silvana, and what does the platform provide?">
    Silvana is the **agent interaction layer for tokenized assets**. It gives agents, applications, and institutions the execution, orchestration, proving, and settlement infrastructure required to operate tokenized assets securely.

    You can also use Silvana [APIs](/agentic-api/intro), [SDKs](/sdk/introduction/sdk-intro), and execution primitives to build secure, agent-driven applications.
  </Accordion>

  <Accordion title="What is Silvana Book?">
    Silvana Book is a private orderbook for high-performance trading on Canton. It combines private off-chain order matching with atomic on-chain Delivery-versus-Payment settlement.

    Silvana Book applies the wider Silvana infrastructure to private trading and settlement on Canton. See [**Meet Silvana Book**](/silvana-book/introduction/meet-silvana-book) for the complete product overview.
  </Accordion>

  <Accordion title="What makes Silvana Book different from public exchanges?">
    Silvana Book keeps order matching away from the public network, which protects order intent, balances, and strategy logic from unnecessary exposure. Accepted trades use deterministic terms, while Canton [DvP](/silvana-book/introduction/how-silvana-book-ensures-security) coordinates delivery and payment atomically.

    This architecture gives traders private order flow, direct asset control, reduced exposure to frontrunning and MEV, and a clear separation between fast execution and final settlement.
  </Accordion>

  <Accordion title="How do agents participate in Silvana Book trading?">
    Agents can submit and cancel orders, consume market events, react to fills, manage portfolios, enforce risk policies, and coordinate settlement workflows and more.

    Explore ready-to-use agents in [**Agent Space**](https://app.silvana.one/agents), or build your own. For more details, see the [**Silvana Agents**](/platform/overview/agents) article.
  </Accordion>

  <Accordion title="Who can use Silvana Book most effectively?">
    Silvana Book serves traders, market makers, liquidity providers, institutions, treasuries, DAOs, token issuers, and developers who need private execution, programmable workflows, and strong settlement guarantees.
  </Accordion>

  <Accordion title="Does Silvana operate only on the Canton Network?">
    Silvana is designed as a broader, chain-agnostic execution platform. Silvana Book currently uses Canton for private asset operations and atomic DvP settlement, while the wider Silvana stack can coordinate agents and workflows across additional systems.
  </Accordion>
</AccordionGroup>

## Onboarding

<AccordionGroup>
  <Accordion title="Do I still need an Early Bird ticket or whitelist?">
    Early Bird tickets, whitelists, and onboarding queues are no longer required. The [Early Bird Program](/silvana-book/introduction/early-bird-program) concluded when Silvana V2 launched on June 26, 2026.

    Complete the current registration, verification, and wallet connection flow instead. See [**Onboarding**](/silvana-book/introduction/get-started/onboarding) for the latest steps.
  </Accordion>

  <Accordion title="What does the current onboarding process include?">
    The current [onboarding flow](/silvana-book/introduction/get-started/onboarding) includes these stages:

    1. Create your account and passkey.
    2. Verify the email address linked to your account.
    3. Complete the required identity verification.
    4. Add [a campaign](/silvana-book/introduction/faq/promo-code) or [referral code](/silvana-book/introduction/earn-hub/referrals) when you have one.
    5. Connect a supported wallet and approve the required wallet action.

    A wallet confirmation may include a network fee displayed by the wallet before approval.
  </Accordion>

  <Accordion title="Is a campaign or referral code required for onboarding?">
    Campaign and referral codes are **optional**. You can continue onboarding without one unless a specific campaign states otherwise.

    A valid code may connect your account to [a campaign](/silvana-book/introduction/faq/promo-code), partner activity, or [referral program](/silvana-book/introduction/earn-hub/referrals). The related announcement remains the source of truth for eligibility and benefits.
  </Accordion>

  <Accordion title="What should I do when KYC remains pending or gets rejected?">
    Verification time depends on the identity-verification provider and the quality of the submitted information. Make sure your details match your documents, your images are clear, and your location is eligible.

    When verification is rejected, or the product continues requesting KYC, review the status shown in the onboarding flow before creating another account. Contact [support](https://forms.gle/BBjTi7znBso2iWcR8) when the status remains unchanged after you have completed every requested step.
  </Accordion>

  <Accordion title="What does the Geo-Blocked Account screen mean?">
    This screen means that access is unavailable from the detected jurisdiction. Geographic restrictions may reflect sanctions, local regulations, product eligibility rules, or other compliance requirements.

    Disable any VPN and retry from your actual location. Check [**Geographic Availability**](/silvana-book/introduction/get-started/geographic-availability) for the current jurisdiction policy.
  </Accordion>

  <Accordion title="How can I solve passkey or login problems?">
    If you're having trouble signing in, try the following:

    * Use a modern browser with passkey support. **Chrome** or **Brave** are recommended.
    * Enable browser pop-ups, as authentication windows may open in a separate tab.
    * Avoid switching browsers during the mobile login flow.
    * Create or synchronize a passkey on every device you plan to use.
    * If the problem persists, contact [our support](https://forms.gle/BBjTi7znBso2iWcR8) for assistance.
  </Accordion>

  <Accordion title="Why does the application ask me to onboard again?">
    First, confirm that you signed in with the same account and email used during verification. Then refresh the session, reconnect the wallet, and review the onboarding status shown in your profile.

    When the account previously traded successfully but the onboarding screen still appears, submit a support request with your account email, public wallet identifier, and a screenshot of the unexpected screen.
  </Accordion>
</AccordionGroup>

## Earn Hub and Rewards

<AccordionGroup>
  <Accordion title="Which trading activities count toward task progress?">
    A trade counts only when it reaches successful settlement and satisfies the specific task conditions. A task can require a particular market, action type, amount, number of trades, or activity period.

    The task card remains the source of truth for qualification rules.
  </Accordion>

  <Accordion title="Do failed, canceled, or expired transactions earn points?">
    Failed settlements, canceled orders, and expired quotes do not count as successfully settled trading activity. An order submission or wallet fee payment alone does not complete a trading task.
  </Accordion>

  <Accordion title="Why has my Earn Hub progress not updated yet?">
    Activity can require processing after settlement before it appears in Earn Hub. First, confirm that the trade shows **Settled**, then verify that its pair, amount, action, and timestamp satisfy the task.

    Refresh Earn Hub and reconnect the wallet when needed. Contact [support](https://forms.gle/BBjTi7znBso2iWcR8) with specific transaction identifiers and dates when qualifying activity remains missing.
  </Accordion>

  <Accordion title="How do several connected wallets affect my points?">
    Earn Hub records progress by account. Successfully settled activity from every wallet connected to that account contributes to eligible task progress, points, and achievements.

    Switching between connected wallets does not create a separate Earn Hub profile.
  </Accordion>

  <Accordion title="What is the difference between points and rewards?">
    Points record eligible activity and task completion inside Earn Hub. Rewards are the assets or benefits made available through a season, campaign, achievement, referral, or claim flow.
  </Accordion>

  <Accordion title="How do campaign codes and referrals work?">
    [Campaign codes](/silvana-book/introduction/faq/promo-code) can connect eligible users to a partner or Silvana campaign. [Referral](/silvana-book/introduction/earn-hub/referrals) rewards depend on the qualifying activity completed through the personal referral link shown in [Earn Hub](/silvana-book/introduction/earn-hub/earn-hub).
  </Accordion>

  <Accordion title="Why haven’t my rewards arrived in my wallet?">
    Check that preapproval is enabled for the relevant asset in your wallet to help prevent issues with reward delivery. The exact setting may differ depending on the wallet you use.

    If the rewards are still missing, please contact [support](https://docs.google.com/forms/d/e/1FAIpQLScHRVjBfIzgeL8Mg58tq2HhhQ_Ep65EpOyr2UG-qrRkh6NczQ/viewform) for assistance.
  </Accordion>
</AccordionGroup>

## Swap

<AccordionGroup>
  <Accordion title="Why did my quote expire before I could submit it?">
    Quotes are valid for a limited time to protect against price changes and replay attacks. If your quote expires before submission, simply request a new quote and try again.
  </Accordion>

  <Accordion title="Why can't I get a quote for my swap?">
    A quote may be unavailable if the liquidity provider does not currently have enough inventory for the requested trade. Try requesting a new quote, adjusting the trade amount, or trying again later.
  </Accordion>

  <Accordion title="What does a missing preapproval message mean?">
    A preapproval is required before you can trade certain tokens. If you see a preapproval message, click **Create \[token] preapproval** and complete the process.

    This message is not related to missing transactions or Earn Hub activity. Preapprovals help reduce network traffic and gas fees.
  </Accordion>

  <Accordion title="Can I log out while a swap is still pending?">
    Yes. A submitted transaction can continue after you log out. However, make sure you complete every required wallet confirmation before leaving the page.
  </Accordion>
</AccordionGroup>

## Terminal

<AccordionGroup>
  <Accordion title="What is the difference between limit and market orders?">
    A limit order enters the private orderbook at the price and quantity you specify. It remains available according to its Time in Force and fills only when compatible liquidity becomes available.

    A market order uses the liquidity currently available in the orderbook and attempts immediate execution within the displayed order range.
  </Accordion>

  <Accordion title="What does Time in Force control for an order?">
    Time in Force determines how long an order remains active and how the order handles immediate or partial execution. The available option and its behavior are described directly in the order form.

    Review this setting before submitting an order, especially when immediate execution matters.
  </Accordion>

  <Accordion title="What does LP-only matching mean inside Terminal settings?">
    LP-only matching limits eligible matches to liquidity providers that support the required DvP settlement flow. The setting is enabled by default to improve settlement compatibility.

    Review the setting before placing an order when available liquidity appears limited.
  </Accordion>

  <Accordion title="Why can one order contain several settlement records?">
    A larger order can match against several available offers. Each matched portion creates its own settlement record, while all settlements remain connected to the original order.

    The order becomes complete when settlements cover its full amount, even while individual settlement flows are still progressing.
  </Accordion>

  <Accordion title="Where can I review orders, settlements, and completed trades?">
    The [Terminal](/silvana-book/introduction/terminal) activity panel separates **Open Orders**, **Order History**, **Settlements**, and **Trade History**. These tabs represent different stages of the trading flow.

    A completed trade appears in **Trade History** after its settlement reaches the settled state.
  </Accordion>

  <Accordion title="Can I cancel several open orders together?">
    Use **Close all** in the **Open Orders** tab to select and cancel multiple active orders. You can also open an individual order and cancel its remaining active amount.
  </Accordion>

  <Accordion title="What should I do when Terminal displays &#x22;Action Required&#x22;?">
    Open the related settlement proposal and complete the requested step. The action may involve confirmation, DvP signing, fee payment, token allocation, or another wallet approval.

    Enable browser pop-ups and check other tabs because the wallet confirmation can open separately. When Terminal shows that the buyer or seller must act, the other party should wait for that step to finish.
  </Accordion>

  <Accordion title="Why did my Terminal transaction fail after I paid the DvP fee?">
    If a transaction fails during wallet signing, the cause may be a wallet-side issue, such as changes to network fees. Wallet fees are managed by the wallet provider and are not controlled or reimbursed by Silvana. If needed, you can use another [supported wallet](/silvana-book/introduction/supported-wallets).
  </Accordion>
</AccordionGroup>

## Settlement and Transaction Status

<AccordionGroup>
  <Accordion title="Why does my wallet request several confirmations?">
    Silvana uses a **multicall function** to combine the required actions into a single transaction, so you should normally need only **one wallet confirmation**.

    If the same transaction asks for confirmation multiple times, something may have gone wrong and additional attempts can result in extra wallet fees. Avoid repeatedly signing the transaction and contact [support](https://docs.google.com/forms/d/e/1FAIpQLScHRVjBfIzgeL8Mg58tq2HhhQ_Ep65EpOyr2UG-qrRkh6NczQ/viewform?usp=send_form) so the team can check the issue.
  </Accordion>

  <Accordion title="What should I check when settlement appears stuck?">
    Follow this sequence before creating another transaction:

    1. Open the settlement and identify which party must act next.
    2. Check blocked pop-ups and any wallet window opened in another tab.
    3. Confirm that the wallet has enough unlocked balance for every required fee.
    4. Complete any missing token preapproval or allocation action.
    5. Avoid repeated submissions until the current order and settlement status are clear.

    When the status remains unchanged, contact [support](https://forms.gle/BBjTi7znBso2iWcR8) with the order, proposal, and transaction identifiers.
  </Accordion>

  <Accordion title="Why are my funds locked, and how can I unlock them?">
    Funds can be reserved while a DvP settlement is active or after an unsuccessful settlement leaves an allocation waiting for expiry. The assets remain associated with your wallet but cannot be reused during the lock period.

    Open [**Portfolio**](/silvana-book/introduction/portfolio) and switch to the **Locked** tab to view your locked funds. Funds are normally released automatically. If a lock has expired, you can release the funds manually using **Unlock**.
  </Accordion>

  <Accordion title="What happens when a transaction fails?">
    If DvP settlement fails, the assets are not exchanged. Any third-party wallet fee that you have already confirmed may still be charged and is not reimbursed by Silvana.

    If you believe the transaction failed because of a platform issue, contact [support](https://forms.gle/BBjTi7znBso2iWcR8) and provide the transaction details.
  </Accordion>

  <Accordion title="Where can I find transaction records and identifiers?">
    Use the [Terminal](/silvana-book/introduction/terminal) activity panel for orders, settlement proposals, and completed trades.
  </Accordion>
</AccordionGroup>

## Wallets and Transaction Fees

<AccordionGroup>
  <Accordion title="Which wallet should I connect to Silvana Book?">
    You can find the current list of supported wallets in [**Supported Wallets**](/silvana-book/introduction/supported-wallets). Only compatible wallets can be used with Silvana features that require Canton DvP.
  </Accordion>

  <Accordion title="Can one account connect more than one wallet?">
    One Silvana account can connect multiple supported wallets. Activity, task progress, achievements, and points are associated with the account across its connected wallets.

    Each wallet can be connected to only one Silvana account.
  </Accordion>

  <Accordion title="How can I switch to another connected wallet?">
    Connect the new supported wallet through your account via the dropdown at the top right, then select it for the next action. Reconnecting or changing wallets does not move account-level Earn Hub progress to a different account.
  </Accordion>

  <Accordion title="Why does my wallet disconnect from the application?">
    A wallet session can expire after inactivity, a browser restart, a network change, or a wallet-side update. Use the **Connect** button in the upper-right corner and approve the connection again.

    Check blocked pop-ups and other browser tabs when the wallet window does not appear.
  </Accordion>

  <Accordion title="Why can one transaction include several different fees?">
    A transaction may include a Silvana service fee and a separate wallet gas fee. Silvana does not set or receive the wallet gas fee. Its amount depends on real-time network conditions and may vary by wallet.
  </Accordion>

  <Accordion title="Why can the wallet fee change between transaction attempts?">
    Wallet and network fees depend on real-time network conditions, the selected wallet, available spendable outputs, and the settlement actions required for that transaction. The amount can therefore change between two otherwise similar attempts.

    Review wallet confirmation before signing, especially after retrying a failed or expired transaction.
  </Accordion>
</AccordionGroup>

## Privacy and Support

<AccordionGroup>
  <Accordion title="Where can I get help with a Silvana issue?">
    Submit a request through the [**Silvana Support Form**](https://forms.gle/BBjTi7znBso2iWcR8).

    For wallet-specific problems, contact the support team of your wallet provider directly.
  </Accordion>

  <Accordion title="Are my orders and balances visible to the public?">
    Silvana Book does not publish private orders, balances, or strategy logic to a public mempool. Matching happens inside a private environment, while the product exposes only the market and account information required for authorized participants.

    Canton settlement also preserves participant-level privacy and selective visibility.
  </Accordion>

  <Accordion title="Does Silvana hold my private keys or custody my assets?">
    Silvana does not receive your wallet private keys. Required actions are prepared by the application and authorized through your connected wallet.

    Your assets remain under your control until the [DvP settlement](/silvana-book/introduction/how-silvana-book-ensures-security) transfers them under the accepted transaction terms.
  </Accordion>

  <Accordion title="Can an agent execute any transaction without my approval?">
    Agents operate within the permissions, policies, and signing flow defined for the application. This design supports [automation](/platform/overview/agents) without giving agents unrestricted control over user assets.
  </Accordion>

  <Accordion title="Why can Silvana restrict or suspend an account?">
    Access can be restricted because of geographic eligibility, compliance requirements, security signals, or enforcement of the Silvana Terms of Service. These decisions require account-specific review.
  </Accordion>
</AccordionGroup>


# Geographic Availability
Source: https://docs.silvana.one/silvana-book/introduction/get-started/geographic-availability



Silvana Book applies geo-blocking during [**onboarding**](/silvana-book/introduction/get-started/onboarding) to ensure access aligns with regulatory restrictions, using a restricted-country list maintained in the product configuration. This may affect your access to Silvana Book. Read the onboarding FAQ [here](/silvana-book/introduction/faqs).

<Warning>
  Check if the country of registration is in the list below.
</Warning>

If the country specified during registration differs from the country provided during [**KYC verification**](/silvana-book/introduction/get-started/kyc-verification), this mismatch may trigger additional compliance checks and can result in onboarding being blocked.

<Danger>
  To avoid delays or access restrictions, ensure the country information you provide during registration and KYC verification is accurate and consistent.
</Danger>

## Restricted Countries

| Country | Code |
| :- | :- |
| Afghanistan | AF |
| Algeria | DZ |
| Australia | AU |
| Austria | AT |
| Bahrain | BH |
| Bangladesh | BD |
| Belarus | BY |
| Belgium | BE |
| Bolivia | BO |
| Brazil | BR |
| British Virgin Islands | VG |
| Bulgaria | BG |
| Burundi | BI |
| Cambodia | KH |
| Cameroon | CM |
| Canada | CA |
| Central African Republic | CF |
| Congo (Brazzaville) | CG |
| Côte d’Ivoire | CI |
| Croatia | HR |
| Cuba | CU |
| Cyprus | CY |
| Czech Republic | CZ |
| Democratic Republic of the Congo | CD |
| Denmark | DK |
| Ecuador | EC |
| Egypt | EG |
| Eritrea | ER |
| Estonia | EE |
| Ethiopia | ET |
| Finland | FI |
| France | FR |
| Germany | DE |
| Greece | GR |
| Guinea-Bissau | GW |
| Haiti | HT |
| Hungary | HU |
| Iraq | IQ |
| Iran | IR |
| Ireland | IE |
| Israel | IL |
| Italy | IT |
| Japan | JP |
| Kazakhstan | KZ |
| Kenya | KE |
| Kosovo | XK |
| Laos | LA |
| Latvia | LV |
| Lebanon | LB |
| Libya | LY |
| Lithuania | LT |
| Luxembourg | LU |
| Mali | ML |
| Malta | MT |
| Mexico | MX |
| Morocco | MA |
| Mozambique | MZ |
| Myanmar | MM |
| Nicaragua | NI |
| Nepal | NP |
| Netherlands | NL |
| Nigeria | NG |
| North Korea | KP |
| Pakistan | PK |
| Palestine | PS |
| Panama | PA |
| Philippines | PH |
| Poland | PL |
| Portugal | PT |
| Quatar | QA |
| Romania | RO |
| Russia | RU |
| Singapore | SG |
| Slovakia | SK |
| Slovenia | SI |
| Somalia | SO |
| South Africa | ZA |
| South Korea | KR |
| South Sudan | SS |
| Spain | ES |
| Sri Lanka | LK |
| Sudan | SD |
| Sweden | SE |
| Switzerland | CH |
| Syria | SY |
| Tanzania | TZ |
| Thailand | TH |
| Tunisia | TN |
| Turkey | TR |
| Uganda | UG |
| Ukraine | UA |
| United Arab Emirates | AE |
| United Kingdom | GB |
| United States | US |
| Uzbekistan | UZ |
| Venezuela | VE |
| Vietnam | VN |
| Yemen | YE |
| Zimbabwe | ZW |


# KYC Verification
Source: https://docs.silvana.one/silvana-book/introduction/get-started/kyc-verification



To start trading on Canton with Silvana Book, you have to complete the KYC verification procedure during [onboarding](/silvana-book/introduction/get-started/onboarding). It is intended to validate user identity and prevent access from restricted geographic locations.

We partner with [Persona](https://withpersona.com/) and [SumSub](https://sumsub.com/) for KYC verification.

<Warning>
  Make sure you provide truthful information and submit valid and original documents. Otherwise, your KYC verification may be flagged for manual review.
</Warning>

Until verification is completed, access to certain platform features may be limited.

# Verification Flow

To pass the KYC check, you have to submit the following data and documents:

1. The country that issued the personal identity document.

<Warning>
  Some countries are [restricted](/silvana-book/introduction/get-started/geographic-availability) from using Canton and, consequently, Silvana Book. Keep this in mind when submitting the country data.
</Warning>

2. Photos of the personal identity document of your choice.

<Note>
  The check runs automatically. Wait until it proceeds.
</Note>

<Warning>
  Follow the guidelines and provide clear, high-quality photos with readable data.
</Warning>

The check runs automatically. Wait until the submitted data is processed. If the KYC verification has been successful, you'll see this screen:

<Frame>
  <img alt="KYC Completed" />
</Frame>

Now wait for KYC approval, which may take longer.

# Manual Check

If you fail to provide valid and truthful information and documents, or the submitted documents do not meet the quality requirements, KYC verification may fail or proceed to manual review. In the latter case, you'll have to wait up to one week for it to finish.

# KYC Statuses

The verification flow is lengthy, and at each step, you'll be notified of the current check status.

Below is the full list of KYC statuses:

| Status | Description |
| - | - |
| Pending | Verification is being processed. |
| Completed | Verification has been successfully completed. |
| Review Needed | Verification is under review. |
| Initiated | Verification has started. |
| Declined | KYC data has been checked, and verification has been declined. |
| Failed | Verification has failed. |
| Expired | Verification time has run out. |


# Onboarding
Source: https://docs.silvana.one/silvana-book/introduction/get-started/onboarding

Silvana Book onboarding guide.

# Get Started

Welcome to Silvana Book. Follow this step-by-step guide to create your account and complete the onboarding process.

## Step 1: Create Account

Open the [Silvana App](https://app.silvana.one/login) and select **Create account**.

Complete the registration form with the following information:

* First name
* Last name
* Email
* Country of residence
* [Campaign](/silvana-book/introduction/faq/promo-code) or [referral code](/silvana-book/introduction/earn-hub/referrals), if one has been shared with you.

Select **Create account with Passkey** and follow your browser’s instructions to create the passkey.

<Frame>
  <img alt="Image" />
</Frame>

<Warning>
  Use accurate personal information that matches the details you will provide during KYC. Your country of residence is also used to confirm regional availability.
</Warning>

## Step 2: Verify Email

A verification message will be sent to the email address entered during registration.

Open the message and follow the verification link. Once your email has been confirmed, return to Silvana to continue onboarding.

<Frame>
  <img alt="Image" />
</Frame>

## Step 3: Complete KYC

After verifying your email, complete the [KYC process](/silvana-book/introduction/get-started/kyc-verification) by following the on-screen instructions and submitting the required information.

After completing your KYC, you'll see the following screen while your verification is being reviewed.

<Frame>
  <img alt="KYC Completed" />
</Frame>

## Step 4: Connect Wallet

Now open the Silvana app and select **Connect Wallet**.

Choose a supported wallet and approve the connection request. The wallet is used to access balances, place orders, and confirm trading and settlement actions.

<Warning>
  One Silvana account can be connected to multiple wallets, but the same wallet cannot be linked to multiple accounts.
</Warning>

Voila! Now you're good to go. Use Silvana Book and enjoy yourself!

<Frame>
  <img alt="Congrats" />
</Frame>

<Note>
  **Passkey Recommendations**

  * Use Chrome or Brave if you experience repeated passkey issues.
  * Allow browser pop-ups during authentication and wallet approval.
  * Check other browser tabs if the login screen appears to be stuck.
  * Avoid switching browsers during authentication on mobile devices.
</Note>

## Restricted Countries

Silvana Book applies [geo-blocking](/silvana-book/introduction/get-started/geographic-availability) during onboarding to ensure access aligns with regulatory restrictions, using a restricted-country list maintained in the product configuration.

If your location falls within a restricted jurisdiction, you will see a **Geo-Blocked Account** screen indicating that access is currently unavailable.

## Onboarding FAQ

If you have more questions about the onboarding procedure, please see our [Onboarding FAQ](/silvana-book/introduction/faqs) or [contact us](https://t.me/silvana_chat).


# Useful Links
Source: https://docs.silvana.one/silvana-book/introduction/get-started/useful-links



Find key resources for learning about Silvana and Silvana Book, joining the community, and getting started with the platform.

Use the links below to explore the product, follow updates, and find answers to common onboarding and trading questions:

* What is [**Silvana Book**](/silvana-book/introduction/meet-silvana-book);
* What is [**Silvana**](/platform/overview/meet-silvana);
* **[Docs & deep dive](https://docs.silvana.one);**
* Our **[Telegram Community Channel](https://t.me/silvana_chat);**
* Our [**Telegram News Channel**](https://t.me/official_silvana);
* Our [Discord Channel](https://discord.com/invite/cyJBu4QVtt);
* Follow updates on [**X**](https://x.com/silvana_book);
* Onboarding [flow](/silvana-book/introduction/get-started/onboarding);
* [**FAQs**](/silvana-book/introduction/faqs) — answers about the platform, onboarding, trading, and rewards.

# **Welcome to Silvana! Trade with ease! 🚀**


# How Silvana Book Ensures Security
Source: https://docs.silvana.one/silvana-book/introduction/how-silvana-book-ensures-security

This article reveals how Silvana leverages Canton's DvP flow for transaction security.

# What's Wrong with Swaps Today?

Traditional swap mechanisms have serious structural limitations:

## Counterparty Risk

In many swap flows,

a) one party transfers an asset first, and\
b) the counterparty is expected to complete their side afterward.

This creates a window where one side is exposed. Even smart-contract swaps can fail due to partial execution, reverted transactions after one transfer, and off-chain coordination errors.

## Liquidity Pool Vulnerabilities

Liquidity pools are a common way to execute swaps. However, these arrangements are inefficient because they expose participants to slippage, impermanent loss, and pricing that depends on arbitrary curve mechanics rather than real market demand.

## Escrow and Custody Assumptions

Typical swaps often rely on a) escrow contracts, b) intermediaries, and c) temporary custody of funds. This introduces trust assumptions, additional attack surfaces, and operational complexity.

## Settlement Uncertainty

In standard swaps, execution and settlement are often decoupled, finality may depend on multiple transactions, and failures can leave systems in inconsistent states.

## Poor Fit for Private or Institutional Trading

Public swap mechanisms expose trade intent, allow front-running and MEV, and leak pricing and strategy information.

# Delivery Versus Payment (DvP) - Canton’s Response to Existing Insecurities

**Canton Network** implements **Delivery vs Payment (DvP)** transaction model that ensures **atomic settlement** while maintaining **enterprise-level privacy** and **security**.

DvP is a settlement mechanism that ensures asset transfer occurs simultaneously with the payment. In traditional finance, DvP prevents scenarios in which one party delivers assets without receiving payment, and vice versa.

Canton Network extends this concept to a decentralized, multi-party environment in which transactions can involve multiple participants across independent blockchains while maintaining institutional-grade privacy and security.

<Check>
  With atomic settlement, DvP effectively eliminates counterparty risk.
</Check>

## Two-Step Confirmation Process

Canton implements a two-phase confirmation process that ensures transaction integrity:

#### Phase 1: Participant Preparation

Each participant prepares a **confirmation request** that provides different views of the transaction. This allows parties to see only the sub-transactions relevant to them while maintaining privacy for other participants.

#### Phase 2: Sequencer Ordering

The confirmation request is submitted to a **sequencer** that orders all confirmation requests across the network. Critically, the sequencer performs only ordering and delivery functions – it cannot access or manipulate transaction content because message contents are encrypted.

## Privacy Through Sub-Transaction Isolation

Another key security feature is **sub-transaction level privacy**.

Each party only receives and records the parts of a transaction that apply to them. In a DvP scenario, participants see only the sub-transactions where their parties are stakeholders.

<Check>
  DvP prevents unnecessary disclosure of information and protects competitive strategies.
</Check>

This approach is essential for institutional use cases like treasury management and collateral trading, where competitors must not be able to front-run strategies or observe payment flows. It also prevents undesirable activities such as arbitrage, MEV, or front-running.

## Encryption and Sequencing Architecture

The sequencer's message contents are encrypted and not visible to the sequencer itself. This design ensures the following:

* **Blind Ordering**: the Sequencer can order transactions without accessing their content;
* **Tamper Resistance**: the Sequencer cannot manipulate transaction details;
* **Privacy Preservation**: transaction data remains confidential during the ordering process.

<Check>
  This enables private execution environments, making it suitable for institutional, bilateral, or agent-driven trading where confidentiality matters.
</Check>

Canton's Global Synchronizer uses a [**2/3 majority Byzantine Fault Tolerant (BFT) consensus protocol**](https://docs.sync.global/overview/overview.html?utm_source=chatgpt.com) operated by independent Super Validators.

<Check>
  This ensures fault tolerance, decentralization, and reliability
</Check>

## No Pools

DvP removes the need for liquidity pools by enabling direct, atomic exchanges between buyers and sellers at agreed prices. Assets and payments settle simultaneously, eliminating slippage, impermanent loss, and pool-based pricing distortions. This order-based approach ensures fair price discovery and reduces risk for participants.

# Comparison with Traditional Systems

| Feature | Traditional Arrangements | Canton DvP |
| - | - | - |
| **Settlement Time** | T+2 or longer | Near-instant |
| **Counterparty Risk** | Managed by intermediaries | Eliminated through atomicity |
| **Privacy** | Limited, requires trusted parties | Built-in, cryptographic |
| **Interoperability** | Single system | Cross-chain atomic |
| **Finality** | Reversible in some cases | Cryptographic finality |

# How Silvana Book Leverages DvP

Orders are matched off-chain in a private environment. Agents, orchestrated by Silvana's Coordination Layer, execute on the validator nodes where parties are located.

Final settlement is executed on-chain via DvP, binding asset delivery and payment into a single, indivisible operation.

This guarantees that trades either fully settle at the agreed price or fail safely without exposing participants to counterparty risk, escrow dependencies, or partial execution, enabling fast, private, and deterministic trading workflows.


# Meet Silvana Book
Source: https://docs.silvana.one/silvana-book/introduction/meet-silvana-book

Learn how we disrupt trading practices and flow and address existing vulnerabilities with Silvana Book's innovative solution.

# Introduction

**Silvana Book** is a private orderbook designed for high-performance trading on **Canton**, combining ultra-fast off-chain order matching with secure, atomic on-chain settlement. It enables market participants to trade with full asset control, strong privacy guarantees, and deterministic execution, without exposing orders or strategies to the public network.

# Basic Principles and Advantages

## Privacy by Default

Order matching runs in a private environment. Trading activity, balances, and strategies are not publicly visible, preventing information leakage and external interference. This is particularly critical for enterprises and corporate traders seeking to keep their operations confidential to avoid frontrunning, unwanted market fluctuations, third-party arbitrage, or MEV-seeking attempts.

## Ultimate Security

By leveraging [**Canton’s DvP**](/silvana-book/introduction/how-silvana-book-ensures-security) execution flow, Silvana Book ensures secure trading. Both parties execute their respective parts of the transaction, and assets are transferred only when all conditions are met.

<Note>
  If any party fails to fulfil its contractual obligations, the transaction will not be finalized and will be rolled back.
</Note>

## Full Asset Control

No assets are escrowed during matching. If any party fails to meet settlement conditions, the transaction is rolled back, and balances remain unchanged, ensuring non-custodial safety, Silvana Book.

<Note>
  Assets never leave a party’s wallet, which effectively means parties retain directcontrol of their assets until a transaction is finalized.
</Note>

## Ultra-Fast Agentic Execution

Bid and ask orders are matched off-chain using an optimistic state, allowing near-instant execution (\< 1s), while final settlement is confirmed later on the Canton Silvana Book. All operations are carried out by autonomous off-chain agents that automate the orderflow.

<Tip>
  Lay back. Focus on trading. And let the agents do the rest.
</Tip>

## No Slippage

Orders are settled at the intended price. Since matching is private and isolated from public order flow, there is no market impact or external price pressure, Silvana Book.

## No Pools

DvP handles swaps and other operations without pools that rules out serious threats and vulnerabilities associated with pool trading, such as loss of custody or control over assets, price manipulation, MEV exploitation, liquidity and market risks, etc.

# Solution and Design

The system separates **execution** from **settlement**:

* **Order matching** happens **off-chain** inside a private matching engine.
* **Bids and asks are matched off-chain via agents.** Upon matching, an optimistic state is generated.
* **Settlement** **occurs on Canton**, using a [Delivery-versus-Payment (DVP)](/silvana-book/introduction/how-silvana-book-ensures-security) flow, under which assets are swapped simultaneously when both parties create their token allocations.

<img alt="Orderbook" />

This design achieves sub-second **optimistic** execution latency while preserving on-chain security and finality.


# Portfolio
Source: https://docs.silvana.one/silvana-book/introduction/portfolio



Portfolio gives you an overview of supported assets, available and locked balances, and recent trading activity in Silvana Book.

<Callout icon="info">
  Estimated Balance is calculated only for assets with pricing available in Silvana. Tokens without available pricing can still appear in your Portfolio, but their value is excluded from the total balance.
</Callout>

<Frame>
  <img alt="Portfolio Holdings" />
</Frame>

<Accordion title="Holdings">
  The Holdings chart gives you a quick visual breakdown of your Portfolio by asset.

  See your asset distribution at a glance, making it easier to track portfolio allocation across supported assets.
</Accordion>

# Unlocked and Locked Funds

Locked funds still belong to you. When assets participate in a DvP flow, the required amount can be reserved while the transaction progresses through settlement.

| Balance | Meaning | Available to use? |
| - | - | - |
| **Unlocked** | The funds are available and can be used for new operations | Yes |
| **Locked** | The funds are temporarily reserved by a contract or settlement process | After the lock is released |

## How to Unlock Funds

<Note>
  In normal conditions, locked funds are released **automatically** when the corresponding flow completes, or the lock expires.
</Note>

Occasionally, a lock may remain after its expected expiration because of a technical issue. In this case, Silvana provides a manual unlock flow for eligible funds.

<Steps>
  <Step title="Check the locked balance">
    Open Portfolio → Assets, expand the relevant asset, and find the balance or contract associated with the locked amount.
  </Step>

  <Step title="Wait for the lock to expire">
    The system normally releases the funds automatically. Manual unlocking becomes relevant only when the lock remains after its expiration window.
  </Step>

  <Step title="Select Unlock">
    When manual unlocking is available, use the **Unlock button** for the locked funds.
  </Step>

  <Step title="Approve the transaction">
    Silvana creates the unlock transaction and sends an approval request to your connected wallet. Review the request and sign it in the wallet.
  </Step>

  <Step title="Check your Portfolio">
    Once the unlock transaction completes, the released amount becomes available under **Unlocked** and can be used again.
  </Step>
</Steps>

# Assets

The **Assets** tab gives you a detailed view behind the Portfolio overview.

Here you can inspect each asset individually, including its total amount and how that balance is divided between Unlocked and Locked funds.

<Frame>
  <img alt="P Assests" />
</Frame>

# Activity

Switch to **Activity** to see what has already happened with your assets.

Each entry shows the operation type, assets and amounts, settlement status, and time. Use the type filter to view each activity separately.

<img alt="P Activity2" />

<Check>
  A **settled** status means that the corresponding operation completed successfully, helping you review previous trades and confirm whether a recent operation has reached final settlement.
</Check>


# Supported Wallets
Source: https://docs.silvana.one/silvana-book/introduction/supported-wallets

This article tells about out wallet arrangements and the wallets we currently support.

# Basic Arrangements

Silvana Book integrates with non-custodial Canton wallets and follows the [**Delivery versus Payment**](/silvana-book/introduction/how-silvana-book-ensures-security) **(DvP)** flow, allowing users to retain full control over their assets and signing keys while Silvana coordinates execution and settlement.

Supporting DvP requires wallets to handle multi-step interactions, offer-and-acceptance flows, and obtain clear user confirmations. This is more complex than traditional single-step blockchain transfers and enables:

* atomic settlement between independent parties
* reduced counterparty risk
* strong guarantees around trade finality

<Callout icon="user-lock">
  Transactions are executed securely and non-custodially without transferring keys, wallet access, or asset control to Silvana Book.
</Callout>

<Callout icon="star-shooting">
  Our goal is not only to integrate existing wallets but also to build an ecosystem in which wallets, agents, and execution systems can operate seamlessly together.
</Callout>

# Wallet Support and Integration

The following wallets are currently supported or planned for future integration:

| Wallet | Integrated in Silvana | DvP/CIP56/SDK |
| :- | :- | :- |
| [**Loop**](https://cantonloop.com/sign-in?continue=%2F) | <Icon icon="check" /> | <Icon icon="check" /><Icon icon="check" /><Icon icon="check" /><br /> |
| [**Supa**](https://supa.finance/signin) | <Icon icon="check" /> | <Icon icon="check" /><Icon icon="check" /><Icon icon="check" /> |
| [Walley](https://walley.cc/login) | <Icon icon="check" /> | <Icon icon="check" /><Icon icon="check" /><Icon icon="check" /> |
| [Lattice](https://app.lattice.cash/login) | <Icon icon="check" /> | <Icon icon="check" /><Icon icon="check" /><Icon icon="check" /> |
| [Send](https://send.cantonwallet.com/) | <Badge>coming soon</Badge> | <Icon icon="check" /><Icon icon="check" /><Icon icon="check" /> |
| [**Zoro**](https://zorowallet.com/login) | ➖ | <Icon icon="check" /><Icon icon="check" /><Icon icon="question" /> |
| [**Console**](https://consolewallet.io/) | ➖ | ➖<Icon icon="check" /><Icon icon="check" /> |
| [**Vala Wallet**](https://vala-wallet.cc/) | ➖ | ➖<Icon icon="check" /><Icon icon="check" /> |

<Check>
  Full list of known Canton wallets here: [Modo Explorer](https://cc.modo.link/mainnet/apps?cat=Wallets)
</Check>

While DvP is a native capability of the Canton network, only a small number of wallets currently expose this functionality to users.

<Danger>
  **Multiple wallets**

  One account can have multiple wallets, but one wallet can't be connected to many accounts!
</Danger>

# **Join us for safer and more secure trading!**

Keep exploring with these articles:

<CardGroup>
  <Card title="Rewards FAQ" href="/silvana-book/introduction/faqs">
    Common questions about points, rewards, and payouts.
  </Card>

  <Card title="Earn Hub" href="/silvana-book/introduction/earn-hub/earn-hub">
    Learn how Earn Hub works in Silvana Book.
  </Card>

  <Card title="How To Provide Liquidity" href="/guides/trading/how-to-provide-liquidity">
    Follow the steps for adding liquidity to markets.
  </Card>

  <Card title="Supported Trading Strategies" href="/silvana-book/for-traders/supported-trading-strategies">
    Choose the trading approach that fits you.
  </Card>
</CardGroup>


# Terminal
Source: https://docs.silvana.one/silvana-book/introduction/terminal



Silvana Terminal is the main trading workspace for Silvana Book.

<Callout icon="rectangle-terminal">
  Since Silvana separates off-chain matching from on-chain DvP settlement, the terminal makes every trade state visible: from active order and match result to counterparty action and final settlement.
</Callout>

This means execution and settlement are visible as separate stages. A trade can be matched quickly, then continue through settlement until both sides complete the required steps.

The terminal helps you track this path without leaving the trading screen.

# Market Workspace

The market workspace is where you start from.

<img alt="Image" />

| **Area** | **What it shows** |
| :- | :- |
| Market selector | Available markets, favorites, and quick market switching. |
| Market header | Current price, 24h change, index price, mark price, high, low, and volume. |
| Chart | Live price movement and market indicators for the selected pair. |
| Order Book | Current bid and ask levels for the market. |
| Trades | Recent executed trades and live market activity. |
| Order form | Buy and sell controls for limit and market orders. |
| Activity Panel | Open orders, order history, settlements, and trade history across markets. |

The same workspace keeps both market and trade data visible. You can select a market, place an order, monitor the book, and track whether your trade is still open, already matched, or waiting for settlement actions.

<Expandable title="chart view tips">
  Market candles show general price movement for the selected pair.

  * Silvana candles show activity executed through Silvana, where available.
  * You can enable Market candles, Silvana candles, or both views together to compare them on the same chart.
  * Your settlement-level trades are also shown on the chart as markers.
  * Settlement markers help you see where a trade is pending, where it has settled, and how it relates to the price movement around it.
  * Hover over a marker to review the trade details and current settlement status directly from the chart.
</Expandable>

# Prerequisites

To start trading, you have to:

* be **[onboarded](https://docs.silvana.one/onboarding);**
* [**connect your wallet**](https://docs.silvana.one/early-bird-program#2-connect-wallet) to your account;
* be logged in.

<Note>
  Check the [list of supported wallets](/silvana-book/introduction/supported-wallets).

  If your wallet becomes disconnected for any reason, you can reconnect it using the **Connect** button in the top-right corner of the interface.
</Note>

## Step 1. Selecting a Market

Use the market selector to switch between available trading pairs. Each market opens in the terminal with its own chart, price data, order book, and order form.

<Callout icon="star">
  Favorite markets can be pinned for faster access. Open market tabs allow you to move between several pairs without losing context.
</Callout>

<img alt="Coins" title="Coins" />

## Step 2. Placing an Order

Choose the side, order type, price, amount, and time in force from the order form.

* For a limit order, the order is placed in the private orderbook at the specified price and quantity.
* For a market order, the terminal uses available liquidity to execute immediately based on the current market state.

<img alt="Image" title="Image" />

<Tip>
  In Terminal Settings, **LP-only matching** is enabled by default to help ensure your orders are matched with liquidity providers that support DvP settlement.
</Tip>

<Expandable title="time in force details">
  Time in Force selector defines how long an order can remain active after you submit it.

  | **Option** | **Meaning** |
  | :- | :- |
  | **Good Till Cancel (GTC)** | The order stays open until it is filled or manually canceled. |
  | **Immediate Or Cancel (IOC)** | The order executes as much as possible immediately, then cancels the remaining amount. |
  | **Fill Or Kill (FOK)** | The order must be filled in full immediately, or it is canceled entirely. |
  | **Good Till Date (GTD)** | The order stays active until a selected date or time, then expires automatically. |
</Expandable>

## Step 3. Review Order Details

After you place an order, the terminal creates an order record. Open the order details to check the order status, fill progress, order parameters, and related settlement records.

<img alt="Image" title="Image" />

An order may include one or multiple settlements, depending on its size and available offers. Once settlements cover the full amount, the order is considered complete, regardless of how those settlements proceed afterward.

<Tip>
  Use **Close all** in the **Open Orders** tab to select and cancel multiple active orders at once instead of closing them one by one.
</Tip>

## Step 4. Track Settlement Proposal

Follow the proposal status to see which side must act next. The settlement flow may require confirmation, DvP signing, fee payment, token allocation, or completion.

<Frame>
  <img alt="Settlement Main" />
</Frame>

<Expandable title="settlement states details">
  Silvana Terminal shows different positions of the same trade as it moves through the system.

  | State | Meaning |
  | :- | :- |
  | **Awaiting Buyer/Seller: Sign Settlement** | The matched trade is waiting for one side to confirm settlement. The other side waits until this step is completed. |
  | **Awaiting Buyer/Seller: Sign DvP** | The settlement is waiting for one side to sign the DvP contract before the flow can continue. |
  | **Action Required: Pay DvP Fee** | Your wallet confirmation is required to pay the DvP fee before settlement continues. |
  | **Action Required: Allocate Tokens** | Your side must allocate the required assets for the DvP settlement. |
  | **Action Required: Pay Allocation Fee** | Your wallet confirmation is required to pay the allocation fee for the token allocation step. |

  <Warning>
    A matched trade does not always mean that settlement has finished. The terminal shows both execution status and settlement progress, so you always know the order's current position.
  </Warning>
</Expandable>

<Expandable title="settlement action alerts ">
  The Terminal helps you find settlements that need attention.

  1. Notifications show when a new settlement proposal is received. Click Open Settlements to review the related settlement details.

  <Frame>
    <img alt="Notifications" />
  </Frame>

  2. Action strip appears at the top of the terminal when one or more settlements require action. Use it to jump directly to the settlement that needs confirmation or signing.

  <Frame>
    <img alt="Settlement String" />
  </Frame>

  3. Settlements table marks the relevant row, so you can quickly see which settlement is waiting for your action.

  <Frame>
    <img alt="Table Set" />
  </Frame>
</Expandable>

## Step 5. Review Your Activity Panel

Once settlement is complete, the trade appears in the activity panel at the bottom of the terminal.

<Frame>
  <img alt="Image" />
</Frame>

<Expandable title="activity panel details">
  The panel helps you check what is still open, what has already been processed, and where each completed record is stored.

  | Tab | What it shows |
  | :- | :- |
  | **Open Orders** | Active orders that are still waiting for execution or cancellation. |
  | **Order History** | Past order records, including filled, cancelled, and completed orders. |
  | **Settlements** | Settlement records and DvP proposal results. |
  | **Trade History** | Executed trades with market, side, price, amount, and total details. |

  Use **Hide Other Pairs** to focus the panel on the currently selected market pair.
</Expandable>

<Check>
  Congratulations – your trade has been completed and recorded in the terminal!
</Check>

## Wallet Confirmations

Some settlement steps may require wallet confirmation. The terminal indicates when action is required on your end.

<Warning>
  Make sure browser pop-ups are enabled before starting settlement. Loop approval requests may open in a separate tab or window, and blocked pop-ups can prevent the confirmation flow from continuing.
</Warning>

# Key Takeaway

Before submitting an order, make sure the trading details are accurate and that the status shown in the terminal after the order is placed matches the status.

<Check>
  * Check the selected market before placing an order.
  * Make sure the order side is correct: **Buy** or **Sell**.
  * Review the price, quantity, available balance, and Time in Force.
  * For market orders, check the available amount and order range before confirmation.
  * After the order is placed, follow its state in the terminal.
  * If the order enters settlement, track the proposal status closely.
  * When the terminal displays “Action Required,” approve the requested step.
  * If the terminal is waiting for the buyer or seller, no action is required from the other party until they complete their step.
  * Settlement is complete only when the proposal status changes to **Settled**.
</Check>


# Orderbook Use Cases
Source: https://docs.silvana.one/silvana-book/orderbook-use-cases

Practical implementations of Silvana Book.

With Silvana Book, you can unlock a vast array of use cases:

## High-Frequency Real-Time Trading

By decoupling matching from settlement, Silvana Book makes trading ultra-fast regardless of the workload. Orders are placed, updated, and matched off-chain in a low-latency environment, allowing strategies to react to market conditions in real time without on-chain bottlenecks.

## Institutional OTC and Block Trading

Silvana Book enables large bilateral trades to be executed privately without exposing intent to the public market. Orders are matched off-chain and settled atomically via DvP, eliminating front-running, slippage, and counterparty risk.

## Agent-Driven Portfolio Balancing

With programmable portfolios, AI or rule-based agents can continuously rebalance positions based on predefined risk strategies. Trades execute deterministically through the orderbook, allowing automated exposure management without manual intervention or custody handoffs.

## Confidential Market Making

Market makers can place bids and asks without revealing full strategy, inventory, or pricing logic. Selective disclosure and ZK proofs allow participants to prove the correctness of execution while keeping sensitive trading data private.

## Private Orderflow for DAOs and Treasuries

DAOs and on-chain treasuries can rebalance assets, perform swaps, or manage liquidity internally without leaking intent to public AMMs. Every transaction is provable and auditable, while execution remains confidential.

## Secure Operations with Real World Assets (RWAs)

Silvana Orderbook supports atomic DvP settlement between tokenized assets and payment instruments. This enables safe trading of real-world assets, private securities, or structured products without escrow, intermediaries, or settlement risk.

## Provable Trading and Compliance Reporting

Every executed trade produces cryptographic proofs that can be used for audits, compliance checks, and reporting. Institutions can demonstrate correctness, solvency, and historical integrity without exposing full transaction details.

## Multi-Asset and Cross-Module Trading

The orderbook can operate across multiple asset types and protocol modules, enabling complex trades such as asset-for-asset, asset-for-liquidity, or asset-for-rights exchanges, all settled atomically via DvP.

## Full Trading History with Privacy Controls

Participants can view a complete, provable trading history of their activity while selectively disclosing data to regulators, partners, or auditors. This balances transparency with confidentiality.

## Yield-Generated Asset Investment

Automated trading agents monitor markets and execute optimized strategies in real time by picking the highest yield-bearing options out there: bonds, tokenized stocks, real estate, commodities, etc. This enables efficient, hands-off execution of complex trading strategies and maximizes the achievable APR.