Skip to content

Contract Analysis

DISCLAIMER // NFA // DYOR

This analysis is based on verified source code retrieved from Etherscan 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-13

Metadata

Primary Contract

PROPERTY VALUE
Contract Address 0xCa5E50710F656F2e537cE2Fc8504dB6E24eD3515 (etherscan)
Network Ethereum Mainnet
Contract Type Standalone ERC20 Token
Token Name Xcellar
Token Symbol XCL
Decimals 18
Deployment Date Oct-02-2025
Deployment Block 20875291
Contract Creator 0xf78c012a8ebc37757036dad9a2f9d73246ed646e (etherscan)
Compiler Version v0.8.30+commit.73712a01
Total Functions 2 custom + inherited ERC20/Ownable
External Contract Dependencies 0 (OpenZeppelin inheritance only)
Upgrade Mechanism ☑ None - Not Upgradable
Verification Status ☑ Source code verified on Etherscan
Audit Status △ No audit submitted
TYPE ADDRESS NOTES
Owner 0xf78c012a8ebc37757036dad9a2f9d73246ed646e (etherscan) Initially set to deployer
Presale Wallet Query via presaleWallet() Received presale allocation at deployment
Rewards Contract (Proxy) 0x2a9848c39fff51eb184326d65f1238cc36764069 (etherscan) Proportional ETH rewards distribution
Rewards Contract (Implementation) 0xe528d428c188a80c4824aad89211d292f9a62d77 (etherscan) Rewards logic contract

Executive Summary

XcellarToken (XCL) appears to be a straightforward ERC20 token with a Deflationary Burn mechanism. The contract follows a simple, transparent design with no proxy patterns or complex mechanisms.

Primary Purpose: Standard fungible token with voluntary burn capability for supply reduction.

Intended Audience: Token holders who can freely transfer and optionally burn their tokens.

Key Mechanisms:

  • Fixed supply at deployment (stored as Immutable variable)
  • Two-way initial distribution (presale wallet + deployer)
  • Voluntary burn function for any token holder
  • Standard Ownable pattern with no special token powers

Significant Trust Assumptions:

  • Trust OpenZeppelin library implementations are secure
  • Trust initial distribution was conducted fairly
  • Trust that presaleWallet and deployer will distribute tokens appropriately

Notable Observations:

  • ☑ Simple, auditable code (69 lines custom)
  • ☑ Uses battle-tested OpenZeppelin libraries
  • ☑ No admin powers to manipulate tokens
  • ☑ No transfer fees or taxes
  • △ Owner can transfer or Renounce Ownership
  • △ All tokens distributed immediately at deployment (no vesting)

Architecture

graph TD
    User([Users/Token Holders])
    Deployer([Deployer])
    Presale([Presale Wallet])
    XCL[XcellarToken Contract<br/>0xCa5E...3515<br/>ERC20 + Ownable]
    OZ_ERC20[OpenZeppelin ERC20]
    OZ_Ownable[OpenZeppelin Ownable]

    Deployer -->|deploys & becomes owner| XCL
    Deployer -->|receives remaining tokens| XCL
    Presale -->|receives presale allocation| XCL
    User -->|can transfer tokens| XCL
    User -->|can burn own tokens| XCL

    XCL -.->|inherits| OZ_ERC20
    XCL -.->|inherits| OZ_Ownable

    Owner[Owner/Admin]
    Owner -->|can transfer ownership| XCL
    Owner -->|can renounce ownership| XCL

System Overview

XcellarToken is a standalone ERC20 token contract that extends OpenZeppelin's standard implementations. At deployment, a fixed total supply is minted and distributed between a presale wallet and the deployer. After deployment, the supply can only decrease through voluntary burns by token holders.

The contract does:

  • Mint a fixed supply at deployment (split between presale and deployer)
  • Allow token holders to burn their own tokens
  • Follow standard ERC20 transfer and approval mechanics

The contract does not:

  • Allow minting after deployment
  • Give the owner any special token powers
  • Implement pause, freeze, or blacklist functionality
  • Charge transfer fees or taxes

Design Patterns Used

Access Control

Roles & Permissions

ROLE ASSIGNED BY REVOKABLE CALL COUNT
Owner Constructor (msg.sender) Yes - via transfer or renounce Single
Token Holder Receiving tokens No Unlimited
Public N/A N/A Anyone

Permission Matrix

FUNCTION OWNER TOKEN HOLDERS ANYONE
transfer() ☑ (if holds tokens) ☑ ☒
transferFrom() ☑ (with approval) ☑ (with approval) ☑ (with approval)
approve() ☑ (if holds tokens) ☑ ☒
burn() ☑ (if holds tokens) ☑ ☒
balanceOf() ☑ ☑ ☑
totalSupply() ☑ ☑ ☑
TOTAL_SUPPLY() ☑ ☑ ☑
presaleWallet() ☑ ☑ ☑
presaleAllocation() ☑ ☑ ☑
transferOwnership() ☑ ☒ ☒
renounceOwnership() ☑ ☒ ☒

Critical Access Control Notes

Owner Has NO Special Token Powers:

  • ☒ Owner cannot mint new tokens
  • ☒ Owner cannot burn others' tokens
  • ☒ Owner cannot pause transfers
  • ☒ Owner cannot freeze accounts
  • ☒ Owner cannot blacklist addresses
  • ☒ Owner cannot take or move user tokens

Owner Can Only:

  • ☑ Transfer ownership to another address
  • ☑ Renounce ownership permanently

Time Locks & Delays

ACTION TIME LOCK CAN CANCEL PURPOSE
Transfer Ownership None N/A ☒ Immediate, no protection
Renounce Ownership None N/A ☒ Immediate, irreversible

Economic Model

Token Distribution Flow

flowchart LR
    Deployment[Contract Deployment<br/>Total Supply Created]

    Deployment ==>|presaleAllocation| Presale[Presale Wallet]
    Deployment ==>|remaining tokens| Deployer[Deployer Wallet]

    Presale ==>|can transfer| Users[User Wallets]
    Deployer ==>|can transfer| Users
    Deployer ==>|can transfer| Exchange[Exchanges/Pools]

    Exchange <==>|buy/sell| Users

    Users -.->|voluntary burn| Void[Burned<br/>address 0x0<br/>Permanently Destroyed]

Supply Mechanics

PROPERTY VALUE
Initial Supply Configurable at deployment (stored in TOTAL_SUPPLY)
Max Supply Initial supply (cannot increase)
Min Supply 0 (if all tokens burned)
Supply Direction Deflationary only

Supply Equation:

Current Circulating Supply = TOTAL_SUPPLY - Total Burned Tokens

Fee Structure

OPERATION FEE RECIPIENT PURPOSE
Transfer 0% N/A No transfer fees
Burn 0% N/A User pays gas only
Approval 0% N/A Standard ERC20

Summary of Observations

XcellarToken appears to be a clean, simple token implementation with minimal risk from the contract code itself.

Strengths:

  • ☑ Simple, auditable code (only 69 lines of custom logic)
  • ☑ Uses battle-tested OpenZeppelin libraries
  • ☑ No admin powers to manipulate tokens
  • ☑ Immutable - cannot be upgraded or changed
  • ☑ No hidden functions, fees, or taxes
  • ☑ Full ERC20 standard compliance
  • ☑ Built-in overflow protection (Solidity 0.8.30)

Considerations:

  • △ Ownership exists but provides no token-related powers
  • △ All tokens minted at deployment with no vesting mechanism
  • △ Burns are irreversible - users should be careful
  • △ Not upgradeable - bugs cannot be fixed, but simplicity reduces risk
  • △ Initial distribution concentration depends on deployment parameters
  • △ Professional audit status unknown

This analysis was performed for educational purposes and should not be considered an official security audit or financial advice. The main risks are economic and operational (distribution, market conditions, team actions) rather than technical contract vulnerabilities.

References

RESOURCE NOTES
Etherscan: Contract Verified source code and transaction history
OpenZeppelin Contracts ERC20 and Ownable implementations

Changelog

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