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: 2026-03-29 (Updated)

Implementation Upgrade

This analysis was originally performed on 2025-12-14 against implementation 0xe528d428...a62d77. On March 27, 2026, the contract was upgraded twice in rapid succession to the current implementation at 0x435dc938...ca965. This update reflects the new implementation which adds 7 new functions, including a priority snapshot fee mechanism and version tracking.

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	67 (current implementation)
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)

Current Implementation Contract

PROPERTY	VALUE
Contract Address	`0x435dc938...5145ca965` (etherscan)
Network	Ethereum Mainnet
Contract Type	Rewards Distribution Logic (v1.0.0)
Upgrade Date	Mar-27-2026 04:13:47 AM UTC
Upgrade Block	24746438
Upgrade TX	`0xaa2a4628...cb20deb` (tx)
Implementation Storage Slot	`0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
Admin Storage Slot	`0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`
Verification Status	△ Source code not verified on Etherscan

Original Implementation Contract

PROPERTY	VALUE
Contract Address	`0xe528d428...f9a62d77` (etherscan)
Network	Ethereum Mainnet
Contract Type	Rewards Distribution Logic (original)
Deployment Date	Dec-08-2025 01:13:47 AM UTC
Deployment Block	23964749

Upgrade History

DATE	IMPLEMENTATION	TX	NOTES
2025-12-08	`0xe528d428...f9a62d77`	Deploy	Original implementation
2026-03-27 03:57 UTC	`0xc09d9bcf...b6134`	`0x04da2b86...8d38db` (tx)	First upgrade (intermediate)
2026-03-27 04:13 UTC	`0x435dc938...ca965`	`0xaa2a4628...cb20deb` (tx)	Second upgrade (current)

TYPE	ADDRESS	NOTES
XCL Token Contract	`0xCa5E5071...24eD3515` (etherscan)	Verified ERC-20 token used for proportional rewards
Proxy Admin	`0x39c98338...34b38a77` (etherscan)	EOA — controls proxy upgrades
Implementation Admin	`0x9fBcc72A...FA63eA03` (etherscan)	Deployed proxy and original implementation
Fee Recipient	`0xe1f3fbb1...37264a84` (etherscan)	EOA — receives priority snapshot fees

Executive Summary

Based on decompiled bytecode analysis, this contract system appears to implement a proportional rewards distribution mechanism for Xcellar (XCL) token holders. The implementation was upgraded twice on March 27, 2026 — both within 16 minutes of each other — adding a priority snapshot fee mechanism and version tracking.

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
Priority snapshot mechanism allows users to pay ETH (0.005 ETH) for immediate balance updates

Quick Stats (as of 2026-03-29):

CATEGORY	VALUE
Total Functions	67
User-Callable Functions	7
Admin-Only Functions	14+
Operator Functions	8+
View Functions	20+
External Contract Dependencies	1
Timelock Period	24 hours
Registered Participants	602
Total Weight (XCL)	~633M XCL
Reward Pool	0 ETH
Total Distributed	0 ETH
Implementation Version	1.0.0
Contract ETH Balance	0 ETH

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
Fee recipient address receives ETH from priority snapshot payments

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)
☑ Version tracking added in upgrade (VERSION() returns "1.0.0")
△ Single admin has extensive powers including manual balance updates
△ Proxy admin can instantly upgrade implementation without timelock
△ Two upgrades executed in 16-minute window on 2026-03-27
△ Reentrancy vulnerabilities observed in claim flows
△ Source code not verified on Etherscan
△ Priority snapshot fees flow to an EOA, not the reward pool
△ 602 participants registered but zero ETH rewards distributed to date

Architecture

graph TD
    User([User Wallet])
    Proxy[Proxy Contract<br/>0x2a9848...764069]
    Impl[Implementation v1.0.0<br/>0x435dc9...ca965]
    Token[XCL Token Contract<br/>0xCa5E50...3515]
    Admin[Impl Admin<br/>0x9fBcc7...eA03]
    ProxyAdmin[Proxy Admin<br/>0x39c983...8a77]
    Operator[Operator Role]
    FeeRecipient[Fee Recipient<br/>0xe1f3fb...4a84]

    User -->|register/claim/deregister| Proxy
    User -->|priority snapshot + 0.005 ETH| Proxy
    Proxy -.->|delegatecall| Impl
    Impl -->|balanceOf queries| Token

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

    Impl -->|distributes ETH rewards| User
    Impl -->|forwards snapshot fees| FeeRecipient

    style User fill:#e1f5ff
    style Proxy fill:#fff4e1
    style Impl fill:#ffe1f5
    style Token fill:#e1ffe1
    style Admin fill:#ffe1e1
    style ProxyAdmin fill:#ffe1e1
    style Operator fill:#fff4e1
    style FeeRecipient 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 (0x435...965): Contains the rewards distribution logic (v1.0.0), upgraded from original 0xe52...d77 on March 27, 2026

The proxy pattern allows the implementation to be upgraded while maintaining the same address and storage state. The proxy admin (0x39c9...8a77) and implementation admin (0x9fBc...eA03) are separate EOA addresses.

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`	☑	☒	☒	☒
`requestPrioritySnapshot`	☑	☑	☑	☑ (payable)
`setFeeRecipient`	☑	☒	☒	☒
`setPrioritySnapshotFee`	☑	☒	☒	☒
`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
Registration	Free	N/A	User pays gas only
Claim	Free	N/A	User pays gas only
Balance Refresh	Free	N/A	User pays gas only
Priority Snapshot	0.005 ETH	Fee Recipient EOA (`0xe1f3fb...4a84`)	Immediate balance snapshot bypass
Snapshot Fee (regular)	0.001 ETH	Fee Recipient EOA	Appears to be a configurable base fee

The March 2026 upgrade introduced a fee mechanism. Priority snapshot fees do not flow into the reward pool — they are forwarded to a designated fee recipient address (an EOA). Reward deposits from operators still flow entirely to the reward pool for distribution.

Summary of Observations

Based on analysis of the decompiled bytecode, this contract system implements a proportional ETH rewards distribution mechanism for Xcellar (XCL) token holders. The implementation was upgraded on March 27, 2026 to add priority snapshot fees and version tracking.

As of this update (March 29, 2026), the contract has 602 registered participants representing approximately 633 million XCL in tracked balances. Despite this registration activity, the reward pool contains zero ETH, and zero ETH has been distributed to date. The contract appears to be in a registration-only phase — users are signing up, but no rewards have been deposited by operators.

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
☑ Version tracking added in upgrade

Considerations:

△ Single admin has extensive powers including manual balance updates
△ Proxy admin can instantly upgrade implementation (no timelock)
△ Two upgrades executed within 16 minutes suggests rapid deployment, possibly without thorough testing
△ Reentrancy vulnerabilities observed in claim flows
△ Complete reliance on external token contract
△ Economic model depends on operators continuously funding rewards
△ Priority snapshot fees flow to an EOA, not the reward pool
△ 602 participants registered but zero ETH distributed
△ 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. The March 2026 upgrade introduced a fee mechanism where ETH from priority snapshots flows to an EOA rather than the reward pool, which adds another trust assumption. The rapid double-upgrade pattern (16 minutes apart) raises questions about the deployment process.

References

RESOURCE	NOTES
Etherscan: Proxy	Transaction history and contract interaction
Etherscan: Original Implementation	Original implementation bytecode
Etherscan: Current Implementation	Current implementation bytecode (v1.0.0)
Etherscan: XcellarToken	Verified XCL token source code
EIP-1967	Standard Proxy Storage Slots

Change Log

DATE	AUTHOR	NOTES
2025-12-14	Artificial.	Initial analysis generated by robots.
2025-12-15	Denizen.	Reviewed, edited, and curated by humans.
2026-03-29	Artificial.	Updated for implementation upgrade to v1.0.0 (`0x435dc9...ca965`). Added upgrade history, 7 new functions (priority snapshot fees, VERSION, fee recipient), updated architecture diagram, fee structure, and risk assessment. Gas: 85 tok