Skill Drift Security Model and Trust Assumptions

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.

The Skill Drift contracts have not yet undergone a formal third-party security audit. An audit is scheduled for Phase 2. Interact with the protocol at your own risk until an audit has been completed.

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 authorizedSigner address 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 uses block.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 the authorizedSigner address instantly — no redeployment required. The 24-hour update cooldown limits the damage window for any single key compromise.

Smart contract bugs

As with any smart contract system, undiscovered vulnerabilities may exist. There is inherent risk in interacting with unaudited contracts. Planned mitigation: A formal third-party security audit is scheduled for Phase 2. A bug bounty program is planned to launch at the same time.

Responsible disclosure

If you discover a vulnerability in the Skill Drift contracts or infrastructure, please contact the core team at security@driftidentity.xyz before disclosing it publicly. The team offers a bug bounty for responsibly disclosed critical issues.

When reporting a vulnerability, include the contract address, a description of the issue, and — if possible — a proof-of-concept transaction or call sequence. This speeds up triage significantly.