Security

Security and assurance

What an integrator needs to know before routing funds through Valtu, and how to check it yourself instead of taking our word for it. Each item says plainly whether it exists today.

Enclave attestation

Keys are generated, held and used only inside AWS Nitro Enclaves. You can check which image is running, at any moment, without trusting Valtu:

1. Pick a random nonce (8 to 64 bytes) and call GET /v1/attestation?nonce=<hex>. No API key is needed.
2. Each returned document is signed by AWS (COSE_Sign1, ES384) with a certificate that chains to the AWS Nitro Enclaves root. It carries the image measurements (PCR0/1/2), your nonce, so it was made just now for you, and the enclave's statement of the public keys it holds.
3. Compare PCR0 with the published measurements, and the keys with the published public keys. Rulings, notarizations and signatures come from those keys, so they come from that image. Production runs two enclave hosts: you get one document per host, and every one must pass.

import { randomBytes } from "node:crypto";
import { verifyAttestation } from "@valtu/wallet-kit";

const nonce = randomBytes(32).toString("hex");
const { attestations } = await valtu.attestation(nonce);
for (const a of attestations) {
  const v = verifyAttestation(a.document, { nonce, expectedPcr0: PUBLISHED_PCR0 });
  console.log(v.pcrs[0], v.statement?.keys);   // throws AttestationError if anything doesn't hold
}

GET /v1/attestation?nonce=9f2c…e1

200 OK
{"nonce": "9f2c…e1", "format": "aws-nitro-cose-sign1",
 "attestations": [{"document": "hEShATgioFkRX…", "statement": {"v": 1, "service": "valtu-enclave", "role": "all",
   "keys": {"policy": "02…", "signer": "03…", "notary": "02…", "quorum": "…"}}}]}

verifyAttestation has no dependencies, so you can read it in full. It checks the certificate chain up to AWS's root (pinned by its published SHA-256), each certificate's validity, the ES384 signature, the nonce and PCR0. Any COSE and X.509 library can do the same.

Reproducible builds and published measurements

The enclave image is built reproducibly. Everything that affects PCR0 is pinned: the Rust image, a Debian snapshot, timestamps, the Amazon Linux image and the nitro-cli version. Anyone with the source at the release commit gets the same measurements. KMS releases the keys' secrets only to an attestation whose image hash is the published PCR0.

This release was built twice from scratch with identical results. A second build by an independent person, on their own machine, is still owed before real funds. Source access for auditors and partners is available on request.

Production keys

The enclaves' keys were created on 13 October 2026 in an offline key ceremony, on a machine never connected to a network. Their public keys are compiled into the image (the anchors file above), so the measurement covers them, and every enclave reports them in its attestation. Signed results from Valtu verify against these keys:

A backup of the secrets is split with Shamir secret sharing and held offline; recovering it needs a threshold of holders together (see the whitepaper). Wallets created before 14 October 2026 used keys from a test ceremony; production moved to these keys that day, and those wallets were given new addresses.

Audit, reserves and records

• External security audit: not done yet. The enclave applications, the coordinator, the deployment and these procedures still need review by an independent firm. It's required before the service holds significant customer funds.
• Internal security review: done (October 2026), by the team with automated review tools. Its findings were fixed. The last, released on 15 October, makes the enclave take its time from the hardware's signed attestation rather than the host's clock. It doesn't replace the external audit.
• Reserves. GET /v1/balances and every wallet address can be checked on-chain. Signed liability attestations aren't offered yet.
• Records. The workspace audit log is append-only, enforced by the database, and exports to CSV. Enclave organization state is versioned append-only and notarized every 12 hours.

Supported chains, finality and reorganizations

Default confirmation depths for every network Valtu supports. Which networks are live, and the values in force, are what GET /v1/networks reports; the tokens per workspace are at GET /v1/assets. Live today: Ethereum, BNB Chain, Polygon, Base, Lisk, TRON and Bitcoin. Solana is paused.

Deposits are recorded PENDING when seen and become CONFIRMED only once they're deep enough and still on the canonical chain. That's the only state to credit on. Each block is checked to link to the one before it. A deposit dropped by a reorganization before then becomes ORPHANED. One dropped after confirmation becomes NEEDS_REVIEW, which means the depth was too shallow for that chain. Each status has its own webhook.

Withdrawals are CONFIRMED at the same depth. The same externalId always returns the same transfer, so a retry never pays twice. A withdrawal that can't be sent within 30 minutes (no funds or gas, signer unavailable, rejected by nodes) is CANCELLED. That happens only from states where the network never acknowledged the transaction. A broadcast transaction that's never accepted becomes NEEDS_REVIEW.

Known gaps:

• EVM deposits made by contract-internal transfers aren't detected without a tracing node.
• TRON, Solana and Bitcoin workspace transfers have run end to end only on test networks. Use capped amounts on them first.

Webhook delivery guarantees

Recovery procedures

Availability

Production runs two enclave hosts and two API instances, each pair spread over two availability zones, with a Multi-AZ database. A monitor in a separate AWS region checks the website, the dashboard, the API, signing and each network's deposits every minute and publishes the results at status.valtu.io, with 90 days of history. The same summary is at GET /v1/status (no API key needed).

There's no uptime commitment yet.

SDK checksums

The wallet kit package is reproducible: the copy served here and a local build from the same commit are byte-for-byte identical. Checksums for the current release are at /site/downloads/SHA256SUMS.txt.

curl -sSLO https://valtu.io/site/downloads/valtu-wallet-kit-0.8.2.tgz
curl -sSL https://valtu.io/site/downloads/SHA256SUMS.txt | grep 0.8.2 | shasum -a 256 -c -

Pin the exact version and its integrity hash in your lockfile; don't install -latest in production.

Reporting a vulnerability

Email security@valtu.io with the details and how to reproduce them, and please give us reasonable time to fix the issue before you disclose it. Don't access other customers' data or move funds beyond what you need to show the issue. Contact details are also at /.well-known/security.txt.