Skip to content
SecurVault
  1. starting the vault
  2. key generated and wrapped
  3. network attempt made
  4. ready

The key stays in the vault. Only the signature comes out.

If the server that runs a wallet can see that wallet's key, the key is already unsafe. SecurVault keeps the key in a separate vault that never connects to the internet.

  • Solana Devnet
  • test USDC
  • no real money
  • Ethereum in phase two
liveaes-256-gcm · ed25519

produced

wallet idwaiting
wrapped keywaiting

attempted

unlock with another idwaiting
vault network attemptwaiting

These values were generated inside your browser as you opened this page. None of them went to a server.

  • 402The fee is asked for with this HTTP code. No subscription.
  • 4 / 4All four attack classes the review found are closed.
  • 15 / 15Every payment provider the review audited had a hole.
  • 0Private key bytes that reach this page.

boundary

Two zones, one gate: air-gapped signing

The first is open to the internet and never touches the key. The second never had a network stack. Only two things cross between them.

TRUST BOUNDARY / ARCHITECTURE01 / 03
01 / INTERNET-FACINGYour applicationA request exists. No private key.
02 / NETWORK-ISOLATEDKey vaultThe key is here. No internet connection.
01

Data crosses. The key does not.

The external service sends the wallet identity and signing payload through one gateway.

front doorwallet-service
data to signpresent
wallet idpresent
private keyabsent
vaultsecret-service
master keyhere
unlocked keywhile signing
network stackabsent

The demonstration in your browser is not a real physical separation. It explains the same boundary. The real one is a container that never had a network stack.

payment

HTTP 402

The fee is in the request: x402 payment over HTTP 402

No subscription, no monthly invoice. You make the call, the server names the price, you pay, the answer arrives.

ONE CALL'S PAYMENT JOURNEY01 / 06
CLIENTYour applicationOnly the call you use.
PAYMENT GATESecurVaultNo delivery before settlement.
01

First, a request.

Your app calls the signing service. No payment has been made yet.

attack tests

All four are closed.

An independent review published in 2026 found a hole in every one of the 15 major payment providers it audited. Every countermeasure has a test guarding it.

free shopping

closed

The payment is treated as valid and the service is delivered. The payment then fails on chain, but the work is done.

Delivery waits for settlement. Verification alone is never a green light.

asset theft

closed

The server trusts the transaction sent by the client. An attacker slips their own transfer into it.

Nothing is accepted beyond one transfer to the merchant's account. One signer, a fixed account list, and a simulation before anything reaches the chain.

service denial

closed

The client pays but never gets the service. Endless retries or an expired window leave the payment stranded.

At most three attempts per payment, inside a time window. A payment is released only on proven failure; an uncertain one is resolved by reconciliation.

gas abuse

closed

When the server covers the cost there is no ceiling. An expensive call is repeated until the fund is empty.

Whoever signs the payment pays its own network fee; we never sponsor it. Price and compute are capped, and nothing reaches the chain until every check passes.

We wrote this gate ourselves.

Plugging into an off the shelf payment facilitator would mean inheriting the very holes the review found in all fifteen of them. There is a stage side too: venue internet and third party downtime are demo risks. So the payment gate is our own implementation and the demo path has no outside dependency at all. We also added a fifth check the review does not cover: the payment is consumed by a single atomic query, and every condition is rechecked right before anything is written to the chain.

live demo

Sign it yourself: a Solana Ed25519 signature in your browser

The amount and recipient below are sample data. Press sign and you will watch what happens inside the vault, step by step: the request crosses the gate, the key opens for that moment, the signature is produced, the key is erased, the signature comes back out.

THE SIGNATURE'S JOURNEYSCROLL · STEP BY STEP ↓
  1. 01

    The request leaves.

    Your app sends the data to be signed. It never needs to know the private key.

  2. 02

    The work stays in the vault.

    The key opens only to sign, inside the network isolated zone.

  3. 03

    The trace is cleared.

    The memory area holding the opened key is zeroed. The wrapped key stays in the vault.

  4. 04

    Only the signature returns.

    Your app receives and verifies the signature. Try it yourself below.

01 / 04
main walletsolana devnetsample data
balance1,284.50 USDC
address9xQf3kTn8p…t5ZoXZt7bF

transfer request

preparing the vault

audit logreal signature

inside the vault

wrapped keypreparing the vault
unwrapped key••••••••••••••••0000000000000000
signature

The middle row never showed a real byte in any frame. The unwrapped key never reaches this page; after erasure, the value the vault reports is zeros.

vault report

  1. request reached the vault
  2. key unlocked for this moment
  3. signature produced
  4. key erased from memory
  5. verified on the page
public keypreparing the vault

These five steps really take less than a millisecond, so no eye can follow them. They are replayed here slowly enough to read. Every value on screen is real; the only thing slowed down is the telling.

The wrapped key is bound to its wallet id. Copied into another wallet's row, it still will not open.

Multisig

When one phone is not enough.

In a single signature vault, whoever holds that signature moves everything. Keeping the key in a network isolated engine does not change that: if the party that requests the signature is compromised, funds leave. The answer is not a better way to hide a secret, it is not holding the signature in one hand.

Two vaults, one line

The hot vault handles daily work and has a per transaction ceiling. Every withdrawal above the threshold comes from the cold vault, where the account owner is not a person but two phones out of three.

Two of three

Three of three would freeze the vault forever if a single phone were lost. Two of three means funds can still move when one phone is gone, and no single phone can move them alone.

Guaranteed by the chain

The signing rule lives in Solana's own SPL Multisig account, not on our server. Even if the server is fully compromised, money in the cold vault will not move without two phones.

Optional

Not everyone can find three phones. Nothing changes for those who skip it; the vault is enabled from the Settings screen and the user sets the threshold amount.

No third party smart contract is used. Neither is MPC: it needs rounds between parties during signing, does not fit a flow carried by QR codes, and has no audited library in this language. It stays on the roadmap.

reference integration

We became its first customer.

SecurVault is infrastructure, so there is no single screen to open and look at. The way to show it works was to build something real on top of it: a store that pays out its commissions on chain.

flow

  1. referral linkA marketer's link is the wallet address itself. No separate account, no separate record, no approval to wait for.
  2. purchaseThe store takes the order and has SecurVault sign the payment. Not one line of its own code touches a key.
  3. commissionThe moment the purchase settles, the commission goes to the marketer's address on chain. The balance lives on the chain, not in the store.

two doors

On your machine or in our service.

Same core, two forms. What changes is who runs it and who holds the key.

Self hostedcustody

The whole stack runs on your machine. The key stays in your network isolated container; the master key lives inside a PKCS#11 token and the process never sees its bytes.

who runs it
you
key
yours, inside a token
payment
licence and setup
for
exchanges, fintechs, treasuries, licensed institutions

setup template

  • Setup and proof of network isolation
  • Master key inside a token: PKCS#11, tested with SoftHSM, hardware HSM as target
  • Policy: daily limit, approval threshold, two of three vault
  • Operation: Mini App, panel, API keys for software
  • Append only log and password encrypted backup
Hosted servicewaas

We run the stack. The key stays in our network isolated container; you connect through the SDK and pay for each call inside the request.

who runs it
we do
key
ours, in the isolated vault
payment
x402, per call
for
developers, stores, creators, AI agents

integration templates

  • Store commission: on chain share at the moment of sale
  • Sponsor campaign: payout at view tiers
  • AI agent: sub wallet, Telegram approval above a threshold
  • Telegram wallet: no setup, pay by QR code

A measured word on HSM: the PKCS#11 interface is written and tested with SoftHSM. SoftHSM is software and gives no physical protection; what it buys is that the key leaves the process, and that a hardware HSM plugs into the same interface.

pricing

As many calls as you make.

No fixed fee, no commitment. Enter your monthly volume.

monthly total

118.20$

Enterprise custody providers ask tens of thousands of dollars a year in fixed licensing for the same work. Reading your own settings and viewing your own audit log are free.

Get started

Open it from Telegram.

No install, no extension, no seed phrase to write down. Open the bot and your wallet is prepared free on first sign in.

Open in Telegram

On Solana Devnet with test USDC. No real money is involved.

Telegram Mini App QR code
Scan with your camera