Skip to content

Contract Analysis

DISCLAIMER // NFA // DYOR

This analysis is based on decompiled bytecode — the contract source code is not verified on
Etherscan. Function names, parameter types, and internal logic are inferred from selector
matching, transaction input decoding, and event log analysis. We are not smart contract
security experts. This document should not be considered a comprehensive security audit or
financial advice. Always verify critical information independently.

⊙ generated by robots | curated by humans

Analysis Date: 2026-03-29

Metadata

Primary Contract

PROPERTY VALUE
Contract Address 0xD8706D2D...dC2C2c (etherscan)
Network Ethereum Mainnet
Contract Type Standalone (not upgradeable)
Deployment Date 2026-03-27 03:53 UTC
Deployment Block 24746335
Contract Creator 0x9fbcc72a...63ea03 (etherscan)
Creation TX 0xc7eb1823...011731b (tx)
Compiler Version Solidity 0.8.20
Total Functions 23
External Contract Dependencies 0
Upgrade Mechanism ☑ None — Not Upgradeable
Verification Status ☒ Not verified on Etherscan
Audit Status ☒ No audit report available
TYPE ADDRESS NOTES
Owner 0x9fbcc72a...63ea03 (etherscan) Deployer. Same address that deployed the XCL Rewards proxy (0x2a9848c3...764069). EOA.
Distributor 0x867a2c98...db3157 (etherscan) Set at deployment. EOA. Authorized to deposit rewards and batch-credit user balances.
Fee Recipient 0xe1f3fbb1...264a84 (etherscan) Receives all registration fees. EOA. Has received 0.174 ETH (174 registrations x 0.001 ETH).
XCL Rewards (v1) 0x2a9848c3...764069 (etherscan) Previous Xcellar rewards contract (upgradeable proxy). Same deployer as this contract.
XCL Token 0xCa5E5071...eD3515 (etherscan) The Xcellar ERC20 token. Not directly referenced by this contract on-chain.

Executive Summary

RewardPoolRegistry is a standalone Ethereum contract deployed on March 27, 2026 that appears to serve as a new reward distribution mechanism within the Xcellar ecosystem. The contract was deployed by the same address (0x9fbcc72a...63ea03) that deployed the original XCL Rewards proxy, establishing a direct operational link between the two systems.

The contract implements a paid registration model where users call registerPool() with a 0.001 ETH fee to enroll. Registration fees are immediately forwarded to a designated fee recipient Externally Owned Account (EOA). Once registered, users become eligible to receive Ether (ETH) reward credits from the distributor or owner via depositToUser() or batchDeposit(). Credited rewards accumulate in a per-user balance that users can withdraw through claim() or claimAmount().

At the time of analysis (2 days after deployment), 174 addresses have registered, paying a combined 0.174 ETH in fees. No rewards have been deposited, no claims have been made, and the contract holds 0 ETH. The contract is essentially an empty pool with a registered user list — waiting for the distributor or owner to fund it.

Key trust assumptions:

  • The owner can drain the entire contract balance via emergencyWithdraw() at any time, with no timelock, no Multisig, and no restriction
  • The distributor and owner control all reward crediting — there is no on-chain calculation or formula; balances are set by fiat
  • Registration fees flow to an EOA with no on-chain accountability for how they are used
  • The contract is not verified on Etherscan, requiring bytecode analysis

Architecture

graph TB
    subgraph Users["Registered Users (174)"]
        U1["User Wallets"]
    end

    subgraph Contract["RewardPoolRegistry<br/>0xD8706D...C2C2c"]
        REG["registerPool()<br/>0.001 ETH fee"]
        BAL["rewardBalance mapping"]
        CLAIM["claim() / claimAmount()"]
    end

    subgraph Admin["Privileged Roles"]
        OWNER["Owner<br/>0x9fbcc72a...63ea03"]
        DIST["Distributor<br/>0x867a2c98...db3157"]
    end

    subgraph Recipients["External Recipients"]
        FEE["Fee Recipient<br/>0xe1f3fbb1...264a84"]
    end

    U1 -->|"0.001 ETH"| REG
    REG -->|"forwards fee"| FEE
    DIST -->|"depositToUser /<br/>batchDeposit + ETH"| BAL
    OWNER -->|"depositToUser /<br/>batchDeposit + ETH"| BAL
    BAL -->|"claim / claimAmount"| U1
    OWNER -->|"emergencyWithdraw"| OWNER

    style Contract fill:#f5f5f5,stroke:#333
    style OWNER fill:#ffe1e1,stroke:#c00
    style DIST fill:#fff3e0,stroke:#e65100
    style FEE fill:#fff3e0,stroke:#e65100

System Overview

RewardPoolRegistry is a self-contained reward ledger. It does not interact with any external contracts — no token contracts, no oracles, no governance systems. All operations are pure ETH transfers.

  • Users pay a one-time registration fee to enroll in the reward pool
  • The distributor or owner credits ETH to registered users by sending ETH to the contract along with the target address
  • Users withdraw their credited balance via claim() (full balance) or claimAmount() (partial withdrawal)
  • The owner has unilateral emergency withdrawal authority over the entire contract balance

The contract does not implement any reward calculation logic. There is no formula linking token holdings to reward amounts. The distributor decides who gets how much, and credits those amounts manually via transactions.

Design Patterns Used

  • ReentrancyGuard: The claim(), claimAmount(), and registerPool() functions use a Reentrancy mutex (slot 0 toggles between 1 and 2)
  • Ownable: Standard single-owner access control pattern with transferOwnership()
  • Pull-over-Push: Users must actively claim rewards rather than having them pushed automatically

Access Control

Roles & Permissions

ROLE ASSIGNED BY REVOKABLE CALL COUNT
Owner Constructor (deployer) ☑ — via transferOwnership() Unlimited
Distributor Constructor, then setDistributor() ☑ — owner can change at any time Unlimited
Fee Recipient Constructor, then setFeeRecipient() ☑ — owner can change at any time Receives ETH passively
Registered User Self-registration via registerPool() ☒ — permanent once registered Unlimited claims

Permission Matrix

FUNCTION OWNER DISTRIBUTOR REGISTERED USER ANYONE
registerPool() ☑ ☑ ☒ (already registered) ☑
claim() ☑ ☑ ☑ ☑ (if registered with balance)
claimAmount(uint256) ☑ ☑ ☑ ☑ (if registered with balance)
depositToUser(address) ☑ ☑ ☒ ☒
batchDeposit(address[],uint256[]) ☑ ☑ ☒ ☒
setDistributor(address) ☑ ☒ ☒ ☒
setFeeRecipient(address) ☑ ☒ ☒ ☒
setRegistrationFee(uint256) ☑ ☒ ☒ ☒
emergencyWithdraw() ☑ ☒ ☒ ☒
transferOwnership(address) ☑ ☒ ☒ ☒

Time Locks & Delays

ACTION TIME LOCK CAN CANCEL PURPOSE
Emergency Withdraw ☒ None N/A △ Immediate — no protection for user funds
Set Distributor ☒ None N/A △ Immediate — new distributor active instantly
Set Fee Recipient ☒ None N/A △ Immediate — fees redirected instantly
Set Registration Fee ☒ None N/A △ Immediate — fee change active for next registration
Transfer Ownership ☒ None N/A △ Immediate — no two-step verification

Economic Model

Fee Structure

FEE TYPE AMOUNT RECIPIENT PURPOSE
Registration Fee 0.001 ETH (configurable) Fee Recipient EOA (0xe1f3fbb1...264a84) One-time enrollment cost

Fund Flow

ETH enters the contract through two channels:

  1. Registration fees (0.001 ETH per user) — immediately forwarded to the fee recipient, never held by the contract
  2. Reward deposits via depositToUser() or batchDeposit() — held by the contract until claimed by users

ETH leaves the contract through three channels:

  1. Registration fee forwarding to fee recipient (automatic, on registration)
  2. User claims via claim() or claimAmount()
  3. Owner emergency withdrawal (drains entire balance)

The contract also has a receive() fallback that accepts plain ETH transfers. Any ETH sent without calling a function is accepted but not credited to any user — it sits in the contract balance until claimed by the owner via emergencyWithdraw().

Current State (as of 2026-03-29)

METRIC VALUE
Registered Users 174
Total Fees Collected 0.174 ETH
Contract ETH Balance 0 ETH
Total Pending Rewards 0 ETH
Rewards Deposited 0 ETH
Rewards Claimed 0 ETH

The contract is 2 days old. Users have registered but no rewards have been deposited yet.

Summary of Observations

RewardPoolRegistry appears to be a straightforward ETH reward distribution ledger for the Xcellar ecosystem. Users pay a small fee to register, then wait for the distributor to credit rewards to their balance. The mechanics are simple and the contract is relatively small (~5.8KB of bytecode).

The contract's primary strength is its simplicity. There is no complex math, no external dependencies, no proxy pattern, and no token interactions. The reentrancy guard protects claim functions. The pull-based withdrawal pattern is a well-understood safe design.

The primary concern is the degree of centralization. The owner has unrestricted emergencyWithdraw() access with no timelock, no multisig requirement, and no on-chain constraint. The distributor controls reward crediting entirely off-chain — there is no verifiable formula linking token holdings, staking duration, or any other metric to reward amounts. Users must trust that the distributor will credit fair amounts and that the owner will not drain the pool.

The contract is not verified on Etherscan, which means users cannot inspect the source code through standard tools. The analysis presented here is based on bytecode decompilation.

Compared to the previous XCL Rewards contract (0x2a9848c3...764069), this new contract drops the upgradeable proxy pattern in favor of a standalone deployment. It also introduces a paid registration model (0.001 ETH) that the previous contract did not have. The same deployer address connects both contracts to the Xcellar project.

This analysis was performed for educational purposes and should not be considered an official security audit or financial advice. We recommend verifying the source code, understanding the trust assumptions, and consulting with blockchain security professionals before committing funds.

References

RESOURCE NOTES
Etherscan - Contract Primary contract page (unverified)
Etherscan - Creation TX Deployment transaction with constructor arguments
OpenChain Signature Database Function selector and event topic hash lookups
4byte.directory Additional function and event signature lookups
XCL Rewards Contract Analysis Previous Xcellar rewards contract analysis for comparison
XCL Token Contract Analysis Xcellar token contract analysis for ecosystem context

Change Log

DATE AUTHOR NOTES
2026-03-29 Artificial. Generated by robots. Gas: 65 tok
? ? Reviewed, edited, and curated by humans.