You should not have to trust us.
The key never leaves your side, settlement cannot half-complete, every run can be proved afterwards, and the agents are open to read. Where a claim here is checkable, this page links to where you check it — and where there is nothing to link yet, it says so.
Who can move your funds.
The first security question is not which cipher we use. It is whose signature is required, and the answer is a choice you make when you pick how to run.
DFNS holds the key
One-button deployment from the agent dashboard. There is no key file for you to store, lose or leak, which is the right trade for someone who wanted to trade and not to run infrastructure.
Runs in Google Cloud under your own account.
You hold the key
Fork a template and run it in your own environment. You decide where the private key lives and how transactions are signed; Silvana's ledger service carries them once they are signed.
Deploys onto AWS, Google Cloud or Azure.
You hold the key and the node
Transactions go through your own Canton validator, with custom changes on top of the agent crates. Nothing in the path is operated by us.
On-premises or corporate cloud.
The parts that do not depend on us keeping our word.
A promise can be broken quietly. These three hold because of where the work runs, which is a different kind of statement and the only kind worth putting on a page like this.
Delivery and payment move together, or neither moves
Settlement is Canton DvP. There is no window in which one side has delivered and the other has not — not a short one, not a monitored one. The class of counterparty risk that window creates does not exist here.
How Silvana Book ensures securityYour order is not public before it is filled
Matching happens off-chain and settles on Canton, so intent is not broadcast to a public mempool for anyone to read and trade ahead of. Privacy here is a property of the venue's construction, not a setting.
Silvana BookSigning is message-level, and the key stays your side
Every request carries an Ed25519 signature made where the key is. The two-phase prepare → sign → execute flow means a signature is never a blind one: you sign the transaction you were shown.
Authentication and signatureWhat a run can prove about itself.
Not a report we write about our own systems — four agents in the catalogue whose job is evidence, which anyone can deploy against their own activity.
Audit Attestation
Produces evidence that a run happened as described, without republishing what it traded.
Audit Replay
Re-runs a settled sequence so a third party can reach the same result from the same inputs.
Compliance Screening
Applies the checks before a trade rather than reporting on them after one.
Selective Disclosure
Shows one counterparty or auditor exactly the part that concerns them, and nothing else.
All four are live entries in the agent catalogue rather than roadmap items, and they sit in the same family as the rest of the compliance agents — see the six families.
Nothing here is behind a sales call.
The strongest thing this page can offer is not an assurance about the code. It is the code.
The seven questions this page exists to answer.
Short answers, each one a summary of a section above. Where a claim is checkable, the section it came from links to where you check it.
- Who holds the private key when a Silvana agent trades?
- It depends on how you run. On Standard, DFNS holds the key and there is no key file for you to store or leak. On Pro you hold it in your own environment and decide how transactions are signed. On Enterprise you hold the key and run your own Canton validator, so nothing in the path is operated by Silvana.
- Can a trade settle on one side only?
- No. Settlement is Canton DvP: delivery and payment move together or neither moves. There is no window in which one side has delivered and the other has not, so the class of counterparty risk that window creates does not exist here.
- Is my order visible before it is filled?
- No. Matching happens off-chain and settles on Canton, so intent is never broadcast to a public mempool for anyone to read and trade ahead of. That is a property of how the venue is built rather than a setting you turn on.
- What can Silvana do with my funds without my signature?
- Nothing. Every request carries an Ed25519 signature made where the key is, and the prepare, sign and execute flow means you sign the transaction you were shown rather than a blind one.
- Can I prove afterwards what an agent actually did?
- Yes. Four agents in the catalogue exist for that: one produces evidence that a run happened as described without republishing what it traded, one re-runs a settled sequence so a third party reaches the same result from the same inputs, one applies the checks before a trade rather than reporting after it, and one discloses to a single counterparty or auditor only the part that concerns them.
- Can I read the code before I trust it?
- Yes. Every catalogue agent is a readable crate with its own documentation, the trust boundaries are written out, and the gRPC message and service definitions the SDK is generated from are discoverable by reflection from your own tooling.
- Where do I report a security vulnerability?
- Through the contact form or by writing to hello@silvana.one. Say in the first line that the message is a security report so it is routed before anything else, and include what you did, what you saw, and the environment you saw it on.
Reporting a vulnerability.
If you have found something, this is where it goes.
Until there is a dedicated channel, use the contact form or write directly, and say in the first line that the message is a security report so it is routed before anything else. Please include what you did, what you saw, and the environment you saw it on.
Take it apart before you trust it.
The crates, the demos and the gRPC definitions are all open, and a funded test account for QA is one message away. That order — read, test, then commit — is the one we would use.