The user-safety layer
xDEVS Chain's signature feature is a set of protections built from standard EVM pieces (system contracts at fixed addresses) plus one opt-in node rule and a set of RPC extensions. Together they address the ways ordinary users actually lose money.
Three rules hold for every feature
- Opt-in. A user who turns nothing on gets ordinary Ethereum behaviour.
- Never reverses a finalized transaction. Protections decide what can happen next; they never undo what already happened.
- No admin key. No protocol key, validator or governance vote can freeze, seize or move user funds. A freeze can only come from guardians the account owner picked.
The pieces
| Threat | Protection | Where it lives | Status |
|---|---|---|---|
| Lost seed phrase | Smart accounts with passkeys and social recovery | XdevsSmartAccount contract | Contracts built |
| Stolen key or device | Guardian Vault: time-locked transfers with a cancel window | Account contract | Contracts built |
| Thief and owner both hold keys | Guardian freeze | Account contract | Contracts built |
| Stolen key of an existing MetaMask address | EOA lock (XIP-0001) | Account contract + node validity rule | Built (node enforces it) |
| Forgotten unlimited approvals | Expiring approvals: XDRC-20, Permit2Expiring, vault allowance policy | Contracts | Contracts built |
| Look-alike names, address poisoning | XNS .xdevs names with confusable-skeleton checks | XNSRegistry contract | Contracts built |
| Look-alike recipient addresses | xdevs_checkRecipient RPC; SDK offline helper | Node RPC / SDK | RPC planned (Phase 4), SDK helper built |
| Blind signing | xdevs_simulateTransaction: asset changes and plain-language warnings | Node RPC | Planned (Phase 4) |
| Front-running (MEV) | Encrypted mempool | Consensus / mempool | Research (Phase 5) |
| Bridge hacks | Light-client bridges only | Policy | Planned (Phase 7) |
"Contracts built" means the Solidity is written and covered by unit, fuzz and invariant tests in Foundry. The contracts are not yet deployed on any network (they are not in the local dev genesis either) and have not been externally audited.
How a protected account fits together
- Get a smart account. A new user creates a passkey account through the factory (no seed phrase at all). An existing MetaMask user delegates their address to the xDEVS Smart Account with an EIP-7702 transaction and keeps the same address.
- Add guardians. Friends, a second device, a hardware key or a recovery service. A threshold of them (for example 2 of 3) can recover the account after a delay.
- Turn on the Guardian Vault. Everyday small payments stay instant. Anything above your threshold, any approval, and any call to an unknown contract waits out a delay (default 24 h) during which you or your guardians can cancel it.
- For a 7702 account, enable the EOA lock. Without it, the old private key could still sign raw transactions that skip the vault. With it, the node accepts only calls that go through the account's own code.
- Use expiring approvals and
.xdevsnames. Approvals die on their own, and names can't be impersonated by look-alikes.
If a key is stolen, the thief is limited to the instant allowance (daily limit). Everything bigger is queued, your guardians can cancel it, freeze the account and recover it to your new device.