Skill Drift is built to be transparent about its security posture. The protocol makes deliberate trade-offs in its early phase to prioritize speed and reliability, and it documents the risks those trade-offs introduce. This page explains the current trust model, the protections in place, the known risks you should be aware of, and how the protocol plans to address them.Documentation Index
Fetch the complete documentation index at: https://docs.driftidentity.xyz/llms.txt
Use this file to discover all available pages before exploring further.
Trust model
Phase 1: centralized Oracle
During the Genesis phase, stat updates are signed by a centralized Oracle server. This is a deliberate design choice, not an oversight. Why centralized? A centralized Oracle is faster to operate, cheaper to run, and more reliable than a distributed system at early scale. You get deterministic, low-latency stat verification without complex on-chain coordination. What does this require from you? You need to trust that the operator does not forge stat updates. The protocol mitigates this in several ways:- The Oracle cannot create stats for profiles that do not exist on-chain
- All signatures use EIP-712 typed data, which is publicly verifiable by anyone
- Per-profile nonces prevent any signed payload from being replayed
- The contract owner can rotate the
authorizedSigneraddress instantly if the Oracle key is compromised
Phase 2: the Jury
In Phase 2, the protocol transitions to a decentralized Jury system. High-stat Drifters will verify the actions of newer users, replacing the centralized Oracle as the primary source of stat attestations. The Jury system provides:- Economic alignment — Jurors stake their own reputation when validating others
- Scalability — Multiple parallel verification channels replace the single Oracle
- Censorship resistance — No single entity controls who can earn stat updates
Smart contract protections
The contracts use OpenZeppelin libraries throughout. The protections currently in place are:| Protection | Implementation |
|---|---|
| Reentrancy guard | OpenZeppelin ReentrancyGuard on all ETH-transferring functions |
| Access control | onlyOwner for admin functions; msg.sender validation for all duel operations |
| Integer overflow | Solidity ^0.8.24 built-in overflow and underflow checks |
| Signature replay | EIP-712 nonces prevent the same signed payload from being submitted twice |
| Self-challenge prevention | attackerProfileId != targetProfileId check blocks dueling yourself |
Known risks
MEV and block producer influence
Duel resolution usesblock.prevrandao as its randomness source. On Base, this value is derived from the L1 Ethereum beacon chain. While it is difficult to manipulate, a sophisticated block producer could theoretically influence duel outcomes by selectively including or excluding transactions.
Planned mitigation: Future phases may integrate Chainlink VRF or a comparable decentralized randomness beacon to remove this trust dependency.
Oracle key compromise
If the Oracle’s private key is stolen, an attacker could sign fraudulent stat updates and submit them against existing profiles. Mitigation in place: The contract owner can rotate theauthorizedSigner address instantly — no redeployment required. The 24-hour update cooldown limits the damage window for any single key compromise.