houseKeeping wallet keys off our servers
On-chain games need on-chain keys. How a studio handles those keys says more about it than any feature list. Our rule is simple: wallet private keys never live on our application servers.
Keys in secure enclaves
Our wallets are created and held inside secure enclaves run by a dedicated key management provider. The keys are generated there, and none of our services can export them. Our services don't hold keys. They hold API credentials that can ask the enclave to sign, and the enclave decides whether to agree.
One credential per job
Each backend service that needs to sign gets its own credential, tied to its own user, with its own rules. A service that moves funds between our own wallets can't send anywhere else. A service that sends payments can only build the exact transaction shapes we expect.
The rules are enforced by the enclave's policy engine before anything is signed. They check things like:
- which on-chain programs a transaction may touch,
- how many transfers it may contain and where they may go,
- how much a single transaction may move.
Anything outside those rules is refused, no matter which service asks.
Things no service can do
A separate deny policy covers every service credential. None of them can export a key, sign an arbitrary payload, or change users, credentials, policies or organization settings. Changes like that need two of three approvers, so no single credential can rewrite the rules.
Trust, but verify the signer too
Our code doesn't blindly trust the signature it gets back. After every signing request we check that the returned transaction carries exactly the message we sent and a valid signature from the expected address. On top of that, outgoing value has hourly and daily caps that stop activity if something looks wrong.
Credentials are replaceable, keys are not
Because services only hold API credentials, any one of them can be revoked and replaced in minutes, with two-approver sign-off, without touching the wallets themselves.