> ## 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.

# Skill Drift Security Model and Trust Assumptions

> Skill Drift's security posture, contract protections, known risks, and the Phase 2 transition from a centralized Oracle to a decentralized Jury.

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.

<Warning>
  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.
</Warning>

## 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](mailto:security@driftidentity.xyz)** before disclosing it publicly. The team offers a bug bounty for responsibly disclosed critical issues.

<Tip>
  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.
</Tip>