WENBlocks
  • Getting Started
    • Overview
      • Technical Architecture
    • Key Features
  • Staking
    • Overview
    • Creating a Stake
    • Withdrawing the Stake
    • Claiming Rewards
  • Liquidity Program
    • How It Works
  • WNT
    • WNT — The Engine of the WEN Ecosystem
  • Airdrops
    • Airdrop Schedule
    • Server Management
    • Penalty Structure
    • How It Works
    • Example
  • Smart Contracts
  • Security
    • Overview
    • Internal Audits
    • External Audits
    • AI Audits
      • Grok
  • CODE
    • WENBlocksManager.sol
    • wnmContract.sol
    • wblkToken.sol
    • wuniContract.sol
    • wntToken.sol
    • syncnode.py
    • airdropGenerator.js
    • dayTrigger.js
  • Conclusion
    • Conclusion
  • Socials
    • Links
Powered by GitBook
On this page
  • Server Architecture and Security
  • Security Considerations
  • Data Verification
  1. Airdrops

Server Management

The WENBlocksManager uses a server-controlled model for airdrop creation:

  • Only the designated server address can create new airdrops

  • The server address can be updated by the current server

  • This ensures automated, scheduled airdrop creation while maintaining security

modifier onlyServer() {
    require(msg.sender == server, "Only server can call");
    _;
}

function updateServer(address newServer) external onlyServer {
    require(newServer != address(0), "Invalid server");
    server = newServer;
}

Server Architecture and Security

The airdrop server operates with multiple layers of security:

  1. Running Sync Scripts: The server runs the official syncnode.py script from XENBlocks to maintain synchronization with the XENBlocks blockchain

  2. Data Push Schedule: The server pushes new airdrop data to the smart contract once per week (every 7 days)

  3. Redundancy: Two airdrop servers operate in tandem - if the primary server fails, the secondary server automatically takes over

  4. Smart Contract Protection: In case of server compromise, the smart contract function updateServer() allows transferring control to a new secure server address

  5. Manual Override: The server update function can effectively pause airdrops by setting the server address to a dead wallet, preventing any further airdrop creation until the issue is resolved

Security Considerations

  • The server only has permission to create airdrops, not to modify existing ones or access funds

  • All airdrop data is verifiable through Merkle proofs

  • The source code for the server scripts is public, ensuring transparency

  • Users can independently verify their airdrop allocations against the official XENBlocks leaderboards

Data Verification

All airdrop data can be independently verified:

  • The server source code is available

  • Users can run their own syncnode to verify data

  • Merkle proofs ensure data integrity

  • The official XENBlocks leaderboards serve as the source of truth

This architecture ensures that even if the server is compromised, the protocol's security remains intact, as the server can only create new airdrops based on verifiable XENBlocks data.

PreviousAirdrop ScheduleNextPenalty Structure

Last updated 1 month ago