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.

Try it yourself
  • Solana Devnet
  • Ethereum Sepolia
  • test USDC
  • no real money
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 passage.

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 / ARCHITECTURE WALKTHROUGH01 / 03
01 / ONLINEYour applicationHas the request. Never the private key.
02 / OFFLINEKey vaultHolds the key. Has no network connection.
01

The payload crosses. The key stays.

The public service sends the wallet ID and payload through a single socket to the vault.

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 price lives in the request.

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

PAYMENT JOURNEY / ILLUSTRATIVE FLOW01 / 06
CLIENTYour applicationPay only for the call you use.
PAYMENT GATEWAYSecurVaultNo delivery before settlement.
01

First, a request.

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

  1. requestsignature asked for
  2. 402amount and address quoted
  3. paymentsigned payment attached
  4. verifyamount, signature, single use
  5. settlewritten to the chain
  6. deliveranswer sent

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 shoppingclosed

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.

instruction injectionclosed

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

Nothing beyond the expected transfer is accepted. The transaction is simulated before it reaches the chain.

fee drainingclosed

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

There is a budget per client and a budget overall. Past the limit, nothing is sent to the chain.

last moment changeclosed

Conditions are checked at the start of the request but not at the end. State that changes in between allows a double spend.

Every condition is rechecked inside the very transaction that consumes the payment.

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.

live demo

Sign it yourself.

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 JOURNEY / 01—04SCROLL · STEP BY STEP ↓
  1. 01

    The request sets off.

    Your application sends the payload to sign. It never needs to know the private key.

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.

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.

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.