No seed phrase, no single key, no unilateral mover.
Crypto wallet infrastructure for an operator holds player and treasury funds, signs transfers under policy, and proves the reserves exist. neoVault™ does this with MPC threshold signing across HSM-backed shards, hot/warm/cold tiering measured against live player liability, and a Merkle proof of reserves any player can check. Every transfer clears a policy engine and a sanctions screen before a signature is requested.
Threshold signing · 3-of-5
tx_9f2a1c3-of-5
MPC signing threshold
6
Chains, 20+ assets
< 400ms
Policy check to signature
Hourly
Proof-of-reserve attestation
There is no key to steal
Threshold signing removes the key as an object that exists at all. Five shards, held separately, produce a valid signature together without any of them reconstructing the whole. At no point does a complete key sit somewhere it could be copied, photographed, or subpoenaed from a single party.
Key custody specification
Tiers sized against live liability
Hot, warm, and cold tiers are sized against outstanding player liability and rebalanced as it moves. The hot tier carries only what settlement needs. The cold tier holds the rest behind a signing ceremony. A compromise of the hot tier is a bad day, not a solvency event.
- Tier floors and ceilings expressed as a share of live liability
- Automatic rebalance proposals, executed under dual control
- Cold-tier movement requires a full ceremony, never a console click
Treasury vs player liability
liveEvery control runs before the signature
Once a transaction is on-chain, nobody can reverse it. Every control below is evaluated while the transfer is still an intention.
Velocity limits
Per-asset and per-window caps evaluated before a signature is requested. A withdrawal that breaches the ceiling is held for approval.
Address allowlists
Treasury destinations are enumerated in advance and time-locked on change, so a compromised console cannot add a new payout address and drain to it in the same session.
Time-locks & dual control
Above a configurable threshold, transfers require two named approvers and a delay window in which somebody can still say no.
Screening before broadcast
Sanctions lists and chain-analytics risk scores are checked while the transaction is still cancellable.
A player can verify their own balance is covered
Each player receives the cryptographic path from their own balance to a signed root. The claim is checkable by the person with the most to lose, and by an auditor.
Step 1
Liability snapshot
Every player balance is hashed into a leaf of a Merkle tree at a fixed cadence. The leaf commits to the balance and a per-player salt, so no player learns anything about any other.
Step 2
Root published
The tree's root is signed and published alongside the total liability it represents. Publishing the root commits to the entire set, so no player can be omitted later.
Step 3
Reserves attested
On-chain reserve addresses are proven under the operator's control by signing a challenge message, and the total is compared against the published liability figure.
Step 4
Player verifies their own leaf
Any player is given the sibling path from their balance to the signed root. They confirm their money is inside the attested total without seeing anyone else's.
Travel Rule and screening, built into the transfer path
Under the EU Transfer of Funds Regulation and FATF Recommendation 16, transfers between providers must carry originator and beneficiary information. neoVault attaches that payload as part of the transfer.
Travel Rule payload
Originator and beneficiary data attached to qualifying transfers, exchanged with counterparty providers over supported protocols, and retained for the period your regime requires.
Sanctions & analytics
Destination addresses screened against sanctions lists and chain-analytics risk scoring before broadcast, with the decision and its reasons written to the audit trail.
One identity, everywhere
KYC status, limits, and self-exclusion travel with the player from the gaming platform into the wallet. There is no second player record.
Wallets, policy, and proofs over one API contract
REST for actions, WebSocket for state, identical to every other module on the platform.
{ "player_id": "plr_9f2a1c", "assets": ["BTC", "ETH", "USDC"], "policy_tier": "player_standard"}// 201 Created{ "wallet_id": "wlt_71ac93", "addresses": { "BTC": "bc1q...8f2a", "ETH": "0x4b81...02cd" }, "custody": "mpc_3_of_5"}Simulate before you sign
Policy decisions are queryable, so your own systems can predict a hold before withdrawal time.
Idempotent transfers
Every write takes an idempotency key. A retried withdrawal never double-spends, whatever your network did.
Proofs are self-contained
A reserve proof verifies against the published root with no call back to us, including years later.
Policy as configuration
Tiers, thresholds, approvers, and allowlists are versioned config with an audit entry per change.
What custody infrastructure does not do
Four boundaries worth knowing before a procurement conversation.
We are not your custodian
You hold shards and, where the market requires one, the authorisation. We supply the signing infrastructure and hold one shard of several, so we could not move your assets alone even if compelled to.
Proof of reserves is not an audit
It proves that attested reserves cover published liabilities at a point in time. It says nothing about off-chain obligations, borrowings against those reserves, or solvency in an accounting sense. Those questions need an auditor.
We do not bridge player funds
Assets are issued and held natively on each chain. Bridges are where this industry has lost the most money, and the failure mode is total.
Screening is a control
Sanctions and analytics screening catches what the data knows about. It reduces exposure. It does not eliminate it.
What treasury and security teams ask
Through threshold reconstruction. A valid signature needs three of five shards, so losing one (a departed employee, a failed HSM, a lost device) costs nothing operationally. The remaining shards keep signing while the lost one is regenerated. Regenerating a shard requires two independent custodians acting together under a documented procedure.
Map your treasury policy to shards and thresholds
A technical session with the engineers who built this: key ceremony documentation, the policy engine against your own limits, and what a proof-of-reserves page would look like on your brand.