Keys, contracts, and bridges held to a published policy.
Blockchain security for a gaming platform covers four things: how keys are held, how contracts reach production, whether player funds ever cross a bridge, and whether the operator's own actions can be rewritten. neoShield™ answers each with a control you can verify: MPC custody, three audits and a timelock per release, no bridges in the player-funds path, and an anchored audit trail.
Operator audit trail
hash-chainedEvery entry hashes the one before it.
3
Independent audits per release
24h
Timelock on privileged deploys
0
Bridges in the player-funds path
3-of-5
Signing threshold, no whole key
Seven attacks, and the control that answers each
The attacks we consider realistic against a gaming platform holding digital assets, and the mechanism that addresses each one.
| Threat | How it plays out | Control |
|---|---|---|
| Key compromise | A stolen or coerced private key signs an unauthorised transfer. | MPC threshold signing. No complete key is ever assembled, so there is nothing whole to steal. |
| Smart contract bug | A logic error or reentrancy path drains a contract. | Three independent audits per release, invariant testing, and a 24-hour timelock before any privileged deploy takes effect. |
| Bridge exploit | A wrapped-asset bridge is drained and the backing disappears. | No bridges in the player-funds path. Assets are issued natively per chain. |
| Oracle manipulation | A price or outcome feed is moved to force a favourable settlement. | Dual-source confirmation, deviation bounds, and staleness checks. A single feed cannot settle anything on its own. |
| Insider transfer | Privileged staff move funds or edit a limit. | Dual control above threshold, address allowlists, time-locks, and an audit trail the insider cannot rewrite. |
| Chain reorganisation | A transaction treated as confirmed is undone by a reorg. | Per-chain confirmation depth tuned to observed reorg history. Settlement is held until the threshold is met. |
| Front-running / MEV | Transaction ordering is exploited between submission and inclusion. | Private transaction submission, and no player order flow on-chain. |
Six stages from specification to production
A contract reaches production after three independent audits, invariant fuzzing, a public testnet run of the exact bytecode, and a 24-hour timelock.
Stage 1
Specification & threat model
Every contract starts with a written threat model naming what it holds, who can call it, and what an attacker would want from it. Contracts that cannot justify holding value are redesigned so they do not.
Stage 2
Three independent audits
Three separate firms review each release without sight of one another's findings. Where the reports disagree, we have found something one of them missed.
Stage 3
Invariant & property testing
Properties that must never be violated (supply conservation, access control, settlement idempotency) are expressed as machine-checked invariants and fuzzed against millions of generated states.
Stage 4
Public testnet
The exact bytecode that will go to production runs on a public testnet with the source verified, so anyone can read what is about to be deployed.
Stage 5
Timelocked deploy
Privileged deploys and parameter changes sit behind a 24-hour timelock. The delay gives monitoring, auditors, and counterparties a window to object before a change is live.
Stage 6
Runtime monitoring
Once live, the contract is watched continuously against the same invariants it was tested on. A violation trips a circuit breaker.
Key management
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, in memory or during recovery, does a complete key sit somewhere it could be copied.
It also answers the insider question. Our staff cannot move your funds, because the cryptography does not permit it.
Key custody specification
Controls that act before they alert
Each mechanism below halts the specific path it protects first, then tells someone.
Anomaly detection
Every on-chain action is scored against the operator's own baseline. A withdrawal pattern that does not match the last ninety days is held for review.
Circuit breakers
Invariant violations, velocity spikes, and oracle deviations trip an automatic halt on the affected path only.
Named pause authority
The people who can pause a contract are named in your agreement and act under dual control. Every use is written to the audit trail with a stated reason.
Reorg handling
Confirmation depth is set per chain from observed reorg history. A transaction is treated as final only once that depth is reached.
The record an inspection actually turns on
Every gaming regulator requires that operator actions are logged completely and cannot be altered afterwards. A database with a retention policy protects the record until someone with database access has a reason to change it. With anchoring, an edited entry breaks its own hash, breaks every hash after it, and stops matching a root already published on a chain neither of us controls.
What gets written to the trail
Everything a regulator would ask about after an incident, captured at the moment it happens.
- RTP and paytable changes
- Bonus rule creation and edits
- Player limit and self-exclusion changes
- KYC status overrides
- Payment and PSP routing configuration
- Admin role grants and revocations
- Contract deploys and parameter changes
- Manual settlement adjustments
Hash-chained, then anchored
Each entry commits to the one before it. Chains are batched and the root is anchored to a public chain hourly, so an edit can go unnoticed for at most one batch.
Evidence bundles on request
A signed, self-contained export covering any window: entries, hashes, anchor references, and the verification method. Readable by an examiner with no blockchain knowledge.
Portable, and yours
Bundles verify against the public chain years later without our involvement. Leaving the platform does not cost you the ability to prove what happened on it.
We do not bridge player funds
This is a standing position. It is the one architectural decision on this page we do not negotiate deal by deal.
Why it matters
Bridges account for the largest single losses in this industry, and the failure mode is total. When a bridge is drained, the wrapped asset stops being backed and the loss lands on whoever holds it. For an operator, that is the players.
What we do instead
Assets are issued natively on each chain we support. That means more integrations, more liquidity relationships, and more engineering per chain. We absorb that cost.
Where bridges still appear
Never in the player-funds path. Treasury operations may use audited, size-capped routes under dual control, disclosed in your contract.
What security teams ask first
No single party, including us. Signing requires a 3-of-5 threshold across shards held by separate custodians. Above configurable thresholds, transfers also require dual approval and must clear a policy engine (allowlists, velocity limits, time-locks) before a signature is requested.
Send us your due-diligence questionnaire.
A technical session with the engineers who built this: key ceremony documentation, audit reports, the threat model above applied to your architecture, and a live look at an evidence bundle.