I spent a long time reading the repository. Not the website. Not Twitter. What I was looking for was institutional architecture hiding in plain sight.
The main repo, SilvanaOne/silvana-book-agent, is written in Rust. 149 commits on the main branch. Last push: August 14, 2026. But look at the numbers next to it: 0 stars, 0 forks. No open issues. No community discussions. This repository is alive, but almost no one is reading it.
This is not about a "cool crypto project." This is about how an execution layer treats tokenized assets in a way that public infrastructure could never do.
Silvana, an execution layer on top of Canton Network, is not a DEX. Not a CEX. Not an AMM.
It is something that those three categories cannot be: private execution infrastructure with atomic settlement.
The Architecture (Not a Marketing Deck)
1. Silvana Book - Private CLOB + Off-Chain Matching
Silvana Book is a private Central Limit Orderbook (CLOB). But the difference does not stop there.
On public chains like Solana, the CLOB is built on the ledger. Every order placement, modification, or cancellation requires a consensus-verified transaction. Market makers must pay gas every time they update a quote. In high volatility, these costs kill high-frequency strategies.
Silvana solves this with a structural bifurcation: execution (matching) is separated from settlement.
The matching engine runs off-chain in a private environment. Agents and institutions send encrypted orders through an authenticated gRPC channel. The engine matches bids and asks based on price-time priority, generating fills off-chain, without ever exposing orderbook depth, unexecuted limit orders, or market maker inventory to the public.
Only when a match is successfully identified does the system transition to the on-chain settlement phase.
What does this mean? Liquidity providers can run Grid Market Making strategies or respond to RFQ (Request for Quote) in sub-second speeds without paying ledger fees for every state update. Only the fill enters Canton. The rest? It never touches the network.
2. Four gRPC Services - Not Your Average REST
They did not build a slow, stateless JSON-REST API. They built four gRPC services with protobuf serialization:
- DAppProviderService: Two-phase transaction flow. PrepareTransaction, then local verify/sign, then ExecuteTransaction.
- SettlementService: Bidirectional SettlementStream for RFQ plus the DvP lifecycle: handshake, preconfirmation, Accept_Dvp, Allocate.
- OrderbookService: Order submission, real-time market data push, RFQ initiation.
- PricingService: Price stream from external venues to anchor on-chain pricing.
Why gRPC instead of REST? REST uses JSON. It is text-based, human-readable, but heavy. Parsing JSON DOM consumes CPU cycles that should be allocated to the pricing algorithm. gRPC uses Protocol Buffers (Protobuf), a densely packed binary format. Data is validated at compile-time, not runtime. For a trading agent processing thousands of updates per second, this is not a luxury. It is a necessity.
More importantly: bidirectional streaming. REST requires aggressive polling to maintain orderbook state. gRPC maintains a persistent, multiplexed TCP connection. Round-trip time is reduced to the physical limits of network routing. This is the latency standard expected by HFT in TradFi, now present in decentralized infrastructure.
3. Two-Phase Flow - Private Key Never Leaves
Operations that change ledger state, such as transfer, DvP, multicall, or CIP-56, are never executed via a single RPC call.
The flow is strict:
Prepare. Verify. Sign. Execute.
Prepare: The agent sends its intent to DAppProviderService. The backend builds the Daml command, fetches disclosed contracts from the Active Contract Set (ACS), calculates ledger fees, and returns a 34-byte multihash of the transaction bundle.
Verify: The agent uses the tx-verifier crate, a core SDK component, to run an independent 3-layer SHA-256 hashing protocol. This ensures the backend-prepared transaction exactly matches the agent's original intent. If the backend is compromised or malicious, the agent will detect it before signing anything.
Sign: The agent signs locally using a Canonical Ed25519 signature via the message-signing crate. The private key never leaves the local environment.
Execute: The signed payload is sent back to Silvana infrastructure for sequencing on Canton.
This is not "trust us." This is cryptographic verification that allows the agent to not trust the backend execution layer. Architecture that separates trust, rather than concentrating it.
4. "Gasless" - Not Free, But Abstracted
On public blockchains, you hold native tokens to pay gas. On Silvana, fees are measured as "traffic" in Canton Coin (CC), UTXO-like structures that are burned to consume network resources.
But Silvana abstracts this. Through endpoints like GetPrepaidTrafficBalance and PreparePayFee, agents can allocate CC amulets to cover operational costs. In a delegation model, a gateway operator (like Cove Wallet API) can pay traffic fees on behalf of the user, while the user still signs asset movements with their own Ed25519 key.
What you feel: gasless. What happens at the protocol layer: fees are subsidized by the application layer. Protocol-enforced mechanics (Daml execution plus BFT sequencing) still require traffic payment. But who pays for it? That can be configured.
Comparison: Why Is This Different from Public Chains?
I will not compare Silvana with other projects in the Canton ecosystem. That would be unfair and irrelevant.
But I will compare it with the infrastructure it is actually replacing.
vs dYdX v4 (Cosmos App-Chain)
dYdX v4 migrated to a sovereign blockchain using the Cosmos SDK. Its orderbook is in-memory, maintained by every validator. Order messages are gossiped off-chain between validators. The block proposer runs a deterministic matching engine and proposes the resulting matches to the network.
Performance? High. Decentralization? Strong. But there is a fatal trade-off: every validator has real-time visibility into every open limit order. Validator nodes can see market depth, trader intent, and liquidation thresholds before block inclusion. This is not theory. This is validator-level MEV that is structurally possible.
Silvana? Its matching engine is private. Resting orders are invisible to the public, invisible to Canton infrastructure operators (Synchronizers). dYdX optimizes for trustless matching consensus among many validators. Silvana prioritizes institutional privacy, centralizing matching computation off-chain but cryptographically decentralizing DvP settlement.
vs CowSwap (Ethereum Intent Protocol)
CowSwap pioneered intent-based trading. Users submit signed "intents," parameters of what they want to sell and what they expect to receive. A solver network competes off-chain to aggregate these intents into batch auctions. The optimal solver submits the batched payload to the GPv2Settlement smart contract on Ethereum.
CowSwap effectively eliminates front-running and sandwich attacks because intents are hidden from the mempool until the solver submits the finalized batch. But there is a fatal limitation: settlement happens on the Ethereum public ledger. Participant identities, asset amounts, portfolio changes, all of it is etched permanently into the public blockchain.
Silvana and CowSwap both remove execution from the public mempool. But Silvana uses Canton's sub-transaction privacy. Even post-settlement, transaction data remains partitioned and encrypted. A block trade on Silvana is known only to the specific transacting counterparties. On CowSwap, the same trade becomes a permanent public record.
vs TradFi FIX Engines / Dark Pools
FIX is a standardized messaging protocol for order entry, cancellation, execution reports, and market data across TradFi venues. Silvana uses custom typed gRPC, a private off-chain matching engine, and agent automation. Settlement in Silvana is built-in atomic Canton DvP. In TradFi, settlement is separated into post-trade clearing and settlement rails.
Dark pools hide liquidity and matching without public display of orders. Silvana does the same, but adds autonomous agent quoting with configurable spreads, real-time bidirectional streams, and balance validation, plus optimistic matching and on-chain atomic DvP multicall. Finality comes from the Canton ledger, not a CSD or custodian settlement.
The Red Flags (Because Architects Do Not Only Look at the Good Parts)
I will not give you a polished version. Here is what I found behind the code.
1. High Fees - Not a Bug, But Architecture
From the official Trading FAQ: "The fee amount largely depends on Canton Network's throughput. The network may be congested. Current fees reflect Super Trusted Mode, which operates through a DvP flow and does not rely on any centralized liquidity pool. Because of this advanced settlement mechanism, cost may be higher than typical swaps."
DvP atomic settlement is expensive. This is not a bug. It is a trade-off they chose: settlement security versus transaction cost. They mention future reductions post-beta, but for now, this is the reality.
2. Minimal GitHub Engagement
silvana-book-agent: 0 stars, 0 forks. silvana-lib (TypeScript): 1 star. Older repo (Sui/Mina focus): 3 stars. No open issues. No external PRs.
This can be interpreted two ways: (a) the project is still very early with few external developers, or (b) their code has not yet passed the stress test of an open-source community. I do not know which is true. But the numbers are there for you to judge yourself.
3. Optimistic Matching Risk
Matching happens off-chain (optimistic state). Settlement uses Canton DvP (atomic, non-custodial). But what happens if a counterparty fails at the settlement phase? Rollback. There is no escrow during matching. This means there is a window of risk between the off-chain match and the on-chain settlement, although that window is minimized by Canton's atomicity.
4. Sequencer Backpressure
Agents have explicit backpressure logic: shed RFQ quoting first, then fees, then background (DvpProposal GC). Configurable pauses: FEE_PAUSE_SECS=10, BACKGROUND_PAUSE_SECS=60, SEQUENCER_OVERLOAD_THRESHOLD=0.5. This shows they are thinking about scale, but it also shows the sequencer can be overloaded.
5. Wallet Support Still Expanding
Loop: full DvP/SDK. DFNS MPC: in progress. Others: partial or planned. This is not a major red flag, but it indicates the ecosystem is still being built.
6. Ops Issue
August 2026 Zealy sprint: "technical error, rewards were not distributed as planned." Apology plus doubled next pool. This is minor, but it shows the team is still handling operational friction.
Education: Why Does This Architecture Matter?
I often see a naive question: "Why don't big institutions just use Uniswap?"
1. MEV Is a Hidden Tax
On a public chain, if I know you are about to buy $10M worth of ETH, I can front-run you. This is illegal in TradFi (the SEC goes after it), but legal in DeFi. Institutions will not risk their reputation and their clients' funds in an environment like that.
Silvana eliminates MEV at two layers: (a) there is no public mempool because matching is off-chain, and (b) Canton synchronizer nodes cannot see the contents of the transactions they sequence, only encrypted metadata.
2. DvP Is Not a Luxury, It Is Compliance
CPMI-IOSCO PFMI Principle 12 requires Exchange-of-Value settlement systems to eliminate principal risk by linking the final settlement of one obligation to the final settlement of the other simultaneously.
In TradFi, this is achieved through centralized clearinghouses and RTGS networks. In Silvana, this is achieved mathematically: the Daml transaction graph is evaluated as an atomic unit. Delivery of a tokenized asset and payment of a settlement currency occur in the exact same state transition. There is no temporal gap. No trusted clearinghouse is needed.
3. CIP-56 vs ERC-20
ERC-20 manages a unified public ledger of balances. CIP-56 uses Daml interfaces (such as HoldingV1:Holding) to define assets as private, UTXO-like contracts with strict authorization logic. CIP-56 supports a multi-step TransferInstruction workflow, allowing transfers to be proposed, cryptographically locked, and then accepted or rejected by the receiver. This feature is necessary for regulated entities that must run Anti-Money Laundering (AML) checks before receiving funds.
4. Why gRPC for Agents?
REST/JSON is suitable for human-driven web interfaces. But for programmatic, AI-driven trading agents, REST is a bottleneck. JSON parsing overhead, DOM generation, payload bloat, all of this consumes CPU that should be used for the pricing algorithm.
gRPC with Protobuf sends data in a densely packed binary format. The schema is defined upfront. Data is validated at compile-time. Bidirectional streaming enables a persistent connection for real-time state synchronization. This is not "nice to have." It is a prerequisite for competitive algo trading.
The Code, Not the Hype
I will not say "Silvana is the future" or "this will disrupt the industry." I do not have a crystal ball.
What I can say: the code I read shows an architecture that does not promote itself. There is no complex tokenomics. No yield farming. No airdrop.
There is only:
- A private orderbook with off-chain matching
- Four gRPC services for agents
- Rust and TypeScript SDKs for builders
- Two-phase signing with local Ed25519 verification
- Atomic DvP settlement on a network that processes over $6 trillion in on-chain assets
The repositories are there. The documentation is there
. The fees are high but documented. The GitHub is quiet but the code is alive. What you do with this information is up to you.
masked. red. watching the settlement.
