Contract Analysis

DISCLAIMER // NFA // DYOR

This analysis is based on decompiled bytecode and observations of the contract behavior. We are not smart contract security experts. This document aims to explain what the contract appears to do based on the code. It should not be considered a comprehensive security audit or financial advice. Always verify critical information independently and consult with blockchain security professionals for important decisions.

⊙ generated by robots | curated by humans

Analysis Date: 2025-12-14

Metadata

Proxy Contract

PROPERTY	VALUE
Contract Address	`0x2a9848c39fff51eb184326d65f1238cc36764069` (etherscan)
Network	Ethereum Mainnet
Contract Type	EIP-1967 Transparent Proxy
Deployment Date	Dec-08-2025 01:20:35 AM UTC
Deployment Block	23964783
Contract Creator	`0x9fBcc72A6bc74d0060e14fe8b8f4b7ccFA63eA03` (etherscan)
Compiler Version	v0.7.6
Total Functions	~40 (2 custom + inherited)
External Contract Dependencies	1 (XCL Token)
Upgrade Mechanism	Transparent Proxy (Admin controlled)
Verification Status	△ Source code not verified on Etherscan
Audit Status	△ Unknown (contract not verified)

Implementation Contract

PROPERTY	VALUE
Contract Address	`0xe528d428c188a80c4824aad89211d292f9a62d77` (etherscan)
Network	Ethereum Mainnet
Contract Type	Rewards Distribution Logic
Deployment Date	Dec-08-2025 01:13:47 AM UTC
Deployment Block	23964749
Contract Creator	`0x9fBcc72A6bc74d0060e14fe8b8f4b7ccFA63eA03` (etherscan)
Implementation Storage Slot	`0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
Admin Storage Slot	`0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`

TYPE	ADDRESS	NOTES
XCL Token Contract	`0xCa5E50710F656F2e537cE2Fc8504dB6E24eD3515` (etherscan)	External token used for proportional rewards
Contract Deployer	`0x9fBcc72A6bc74d0060e14fe8b8f4b7ccFA63eA03` (etherscan)	Deployed both proxy and implementation

Executive Summary

Based on the decompiled code analysis, this contract system appears to implement a proportional rewards distribution mechanism with the following characteristics:

Primary Purpose: Distributes ETH rewards to registered users proportionally based on their XCL token holdings.

Intended Audience: XCL token holders who register to receive ETH rewards.

Key Mechanisms:

Uses a "rewards per share" accounting model to track accumulated rewards efficiently
Users register with their token balances, operators deposit ETH rewards
Rewards distributed based on proportional ownership of tracked token balances
Periodic balance snapshots maintain accurate distribution

Quick Stats:

CATEGORY	COUNT
Total Functions Identified	~40
User-Callable Functions	5
Admin-Only Functions	12+
Operator Functions	6+
External Contract Dependencies	1
Timelock Period	24 hours

Significant Trust Assumptions:

Admin controls upgradeability, operator management, parameter changes, and emergency withdrawals
Operators control reward deposits, registration windows, pause functionality, and blacklisting
External token contract balance queries are trusted
Proportional distribution depends on periodic balance snapshots

Notable Observations:

☑ Gas-efficient reward distribution using rewards-per-share (no iteration over users when depositing)
☑ 24-hour Timelock on critical admin operations
☑ Transparent Proxy pattern prevents admin/implementation function selector conflicts
☑ Multiple pause mechanisms (global, per-user, blacklist)
△ Single admin has extensive powers including manual balance updates
△ Proxy admin can instantly upgrade implementation without timelock
△ Reentrancy vulnerabilities observed in claim flows
△ Source code not verified on Etherscan

Architecture

graph TD
    User([User Wallet])
    Proxy[Proxy Contract<br/>0x2a9848...064069]
    Impl[Implementation Contract<br/>0xe528d428...a62d77]
    Token[XCL Token Contract<br/>0xCa5E50...3515]
    Admin[Admin]
    Operator[Operator Role]

    User -->|register/claim/deregister| Proxy
    Proxy -.->|delegatecall| Impl
    Impl -->|balanceOf queries| Token

    Admin -->|can upgrade| Proxy
    Admin -->|full control| Impl
    Operator -->|deposit rewards| Impl
    Operator -->|manage registration| Impl

    Impl -->|stores ETH| Impl
    Impl -->|distributes ETH| User

    style User fill:#e1f5ff
    style Proxy fill:#fff4e1
    style Impl fill:#ffe1f5
    style Token fill:#e1ffe1
    style Admin fill:#ffe1e1
    style Operator fill:#fff4e1

System Overview

The system consists of two contracts working together:

Proxy Contract (0x2a9...069): An EIP-1967 Transparent Proxy that delegates all calls to the implementation, except admin calls
Implementation Contract (0xe52...d77): Contains the rewards distribution logic

The proxy pattern allows the implementation to be upgraded while maintaining the same address and storage state.

Design Patterns Used

PATTERN	PURPOSE
EIP-1967 Transparent Proxy	Implementation stored at standardized storage slot, admin cannot call implementation functions
Upgradeable Pattern	Contract logic can be replaced while maintaining state
Access Control	Role-based access (Admin, Operators, Users)
Timelock	24-hour delay on sensitive admin operations
Pausable	Contract and individual addresses can be paused
Rewards Per Share	Efficient proportional distribution without iterating over all users
Snapshot System	Periodic balance snapshots to track changes

Access Control

Roles & Permissions

ROLE	ASSIGNED BY	REVOKABLE	COUNT
Admin	Constructor (msg.sender)	Yes - 24-hour timelock + 2-step transfer	Single
Operator	Admin adds via `addOperator()`	Yes - Admin queues removal with 24-hour timelock	Multiple
Registered User	Self-service via `register()`	Yes - Self or Admin/Operator	Unlimited
Blacklisted	Admin/Operator via `blacklistAddress()`	Yes - Admin only	Per address

Permission Matrix

FUNCTION	ADMIN	OPERATOR	REGISTERED USER	ANYONE
View functions	☑	☑	☑	☑
`register()`	☑	☑	☒	☑ (if eligible)
`claimRewards()`	☑	☑	☑	☒
`deregister()`	☑	☑	☑	☒
`pause/unpause`	☑	☑	☒	☒
`open/close registration`	☑	☑	☒	☒
`deposit rewards`	☑	☑	☒	☒
`blacklist address`	☑	☑	☒	☒
`force deregister`	☑	☑	☒	☒
`add/remove operator`	☑	☒	☒	☒
`emergency withdrawal`	☑	☒	☒	☒
`manual balance update`	☑	☒	☒	☒
`upgradeTo`	☑ (proxy admin)	☒	☒	☒

Critical Access Control Notes

Admin Powers:

☑ Upgrade contract logic (via proxy - no timelock)
☑ Emergency withdrawals (24-hour timelock)
☑ Manually set any user's balance to arbitrary value
☑ Add/remove operators (removal has 24-hour timelock)
☑ Remove addresses from blacklist
☑ Change minimum balance requirement (24-hour timelock)

What Admin Cannot Do Without 24-Hour Warning:

☒ Cannot instantly transfer admin role
☒ Cannot instantly remove operators
☒ Cannot instantly withdraw funds
☒ Cannot instantly change parameters

Timelock & Delays

ACTION	TIME LOCK	CAN CANCEL	PURPOSE
Admin Transfer	24 hours	Yes (admin)	Prevent instant takeover
Remove Operator	24 hours	Yes (admin)	Allow coordination
Change Min Balance	24 hours	Yes (admin)	Prevent lockout
Emergency Withdrawal	24 hours	Yes (admin)	Warn community
Proxy Upgrade	☒ None	N/A	△ Critical risk

stateDiagram-v2
    [*] --> Queued: Admin queues action

    Queued --> Waiting: Timelock starts<br/>24 hours

    Waiting --> Cancelled: Admin cancels
    Waiting --> Executable: 24 hours elapsed

    Executable --> Executed: Admin executes action
    Executable --> Cancelled: Admin cancels

    Executed --> [*]
    Cancelled --> [*]

Economic Model

Reward Distribution Mechanism

The contract implements a Rewards Per Share accounting system for efficient proportional distribution:

Formula:

rewardsPerShare += (depositAmount * 10^18) / totalTrackedBalance
pendingRewards = (userBalance * rewardsPerShare / 10^18) - rewardDebt

When rewards deposited:

Operator sends ETH to contract
rewardPool increased by deposit amount
If participants exist: rewardsPerShare increased proportionally

When user claims:

Calculate pending: (balance * rewardsPerShare / 10^18) - rewardDebt
Transfer pending ETH to user
Decrease rewardPool by pending amount
Update rewardDebt to current accumulated amount

Token Flow

flowchart TD
    ExtToken[External Token Contract]
    User[User Wallet]
    Contract[Rewards Contract]
    Operator[Operator Wallet]
    Admin[Admin]

    User -.->|1. Must hold tokens| ExtToken
    User -->|2. register| Contract
    Contract -->|3. Query balance| ExtToken
    Contract -->|4. Store snapshot| Contract

    Operator -->|5. Deposit ETH| Contract
    Contract -->|6. Store in reward pool| RewardPool[(Reward Pool)]
    Contract -->|7. Calculate rewards/share| Contract

    User -->|8. claimRewards| Contract
    RewardPool -->|9. Transfer ETH proportional to tokens| User

    Admin -.->|Emergency: withdraw| RewardPool

    style ExtToken fill:#e1ffe1
    style User fill:#e1f5ff
    style Operator fill:#fff4e1
    style Admin fill:#ffe1e1
    style Contract fill:#ffe1f5
    style RewardPool fill:#fff4e1

Fee Structure

OPERATION	FEE	RECIPIENT	PURPOSE
Transfer	N/A	N/A	N/A (ETH rewards only)
Registration	0%	N/A	User pays gas only
Claim	0%	N/A	User pays gas only

All deposited ETH goes to reward pool for distribution. No protocol fees observed.

Summary of Observations

Based on analysis of the decompiled bytecode, this contract system implements a proportional ETH rewards distribution mechanism.

Strengths:

☑ Gas-efficient reward distribution using rewards-per-share
☑ 24-hour timelock protection on critical admin operations
☑ Transparent proxy pattern prevents selector conflicts
☑ Multiple pause mechanisms for emergency control
☑ Two-step admin transfer prevents accidental loss of control
☑ Comprehensive event emissions for transparency
☑ Rate-limited balance updates prevent spam

Considerations:

△ Single admin has extensive powers including manual balance updates
△ Proxy admin can instantly upgrade implementation (no timelock)
△ Reentrancy vulnerabilities observed in claim flows
△ Complete reliance on external token contract
△ Economic model depends on operators continuously funding rewards
△ Analysis based on decompiled bytecode (source not verified)
△ No professional audit information available

Overall Risk Assessment: High to Critical

The contract's most significant risks stem from centralized control with instant upgrade capability, reentrancy vulnerabilities in claim flows, complete dependence on external token contract, and trust-based economic model with no guarantees.

References

RESOURCE	NOTES
Etherscan: Proxy	Transaction history and contract interaction
Etherscan: Implementation	Implementation bytecode
EIP-1967	Standard Proxy Storage Slots

Changelog

DATE	AUTHOR	NOTES
2025-12-14	Artificial.	Generated by robots.
2025-12-15	Denizen.	Reviewed, edited, and curated by humans.