Square Token SQUA logo squaretoken.org — Historical Archive Project Inactive — Site Offline Since Jan 31, 2025
SQUA Archive / Smart Contract / Source Code

SQUA Smart Contract
SquareToken.sol — archived source code

The original source code of the Square Token (SQUA) smart contracts, as deployed on BNB Smart Chain and verified on BscScan. This page preserves the contract code for historical and research purposes. The project is defunct — no transactions should be initiated with this contract.

Contract Address 0xb82beb6ee0063abd5fc8e544c852237aa62cbb14 Network BNB Smart Chain (BSC) — BEP20 Compiler Solidity 0.7.6 Libraries OpenZeppelin ERC20, ERC20Capped, ERC20Burnable GitHub Repo github.com/square-token/squaretoken (inactive, 0 stars, 2 forks) Security Audit None submitted — unaudited contract Deploy Date January 2022 Current Status Abandoned — no active development

Primary Sources & Block Explorer Links

The contract is permanently on-chain. All data below is publicly verifiable on BscScan:


SquareToken.sol

The main token contract inheriting from OpenZeppelin's ERC20, ERC20Capped, and ERC20Burnable. Source verified on BscScan.

SquareToken.sol
Solidity 0.7.6 · UNLICENSED · BNB Smart Chain View on BscScan →
// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.7.6;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20Capped.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20Burnable.sol";

// Interface for the TokenSeller contract — controls sell availability per address
interface ITokenSeller {
    function sellAvailability(address _adr) external view returns (uint256);
}

contract SquareToken is ERC20, ERC20Capped, ERC20Burnable {

    string public constant NAME   = "Square Token";
    string public constant SYMBOL = "SQUA";
    uint256 public constant CAP   = 5000000 * 10**18;

    ITokenSeller public tokenSeller;

    constructor(address _tokenSeller)
        ERC20(NAME, SYMBOL)
        ERC20Capped(CAP)
    {
        // Validate TokenSeller address
        require(_tokenSeller != address(0), "TokenSeller cannot be zero address");
        tokenSeller = ITokenSeller(_tokenSeller);
        // ⚠ Mint ENTIRE supply to contract deployer (owner)
        _mint(msg.sender, CAP);
    }

    /**
      * @dev Hook called before any token transfer.
      * Checks sellAvailability from TokenSeller to gate transfers.
      * Minting (from == address(0)) is always allowed.
      */
    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 amount
    ) internal virtual override(ERC20, ERC20Capped) {
        uint256 sellingAvailability = tokenSeller.sellAvailability(from);
        // Allow minting and honor TokenSeller allowance
        if (from != address(0)) {
            require(
                sellingAvailability >= amount,
                "SquareToken: transfer amount exceeds sell availability"
            );
        }
        super._beforeTokenTransfer(from, to, amount);
    }
}
⚠ Key Finding: TokenSeller Transfer Gate

The _beforeTokenTransfer hook requires every transfer to be approved by the TokenSeller contract via sellAvailability(). This means the project team could control — and restrict — which wallets were able to sell or transfer their SQUA tokens at any time, simply by adjusting the TokenSeller contract. This is a significant centralization risk that was not prominently disclosed to investors.


TokenSeller.sol — Transfer Control Mechanism

The TokenSeller contract is the second deployed contract in the SQUA system. It functions as a gatekeeper: every token transfer checks TokenSeller.sellAvailability(address) to determine whether and how much a given address is permitted to transfer.

This architecture implements the vesting schedule described in the whitepaper — private sale participants were locked for 30 days, ecosystem fund tokens were locked for 3 months. The TokenSeller contract enforced these restrictions at the blockchain level, meaning no wallet could bypass the vesting by transferring to another address.

What this means in practice

The TokenSeller contract gave the project operators the technical ability to freeze or restrict transfers for any wallet at will. Whether this capability was used inappropriately is unknown — the contract's transaction history is visible on BscScan, but interpreting it requires knowledge of the original TokenSeller deployment parameters.

View full transaction history on BscScan →


Security Assessment: What the Code Shows

A structured review of the contract code against common BEP20 security criteria:

CheckResultNotes
OpenZeppelin base ✓ Pass Uses audited OZ ERC20, ERC20Capped, ERC20Burnable libraries
Capped supply ✓ Pass Hard cap of 5,000,000 enforced by ERC20Capped — cannot be increased
Burn function ✓ Present ERC20Burnable included; however only ~3 tokens were ever burned in practice
Mint pattern ⚠ Risk Entire 5M supply minted to deployer at construction — no distribution lock
Transfer control ⚠ Risk TokenSeller can restrict any wallet's ability to transfer — centralized gate
Security audit ✗ None No audit submitted to BscScan, CertiK, or any public registry
SPDX license ⚠ UNLICENSED Code is proprietary — not open source despite being publicly verifiable
Ownership renounced ✗ No No evidence of ownership renouncement on BscScan
Reentrancy protection ✓ N/A Token contract without complex DeFi logic — standard OZ protections apply
Proxy / upgradeable ✓ Pass Not upgradeable — contract logic is immutable once deployed

Understanding BEP20 & Smart Contracts

For context on the technology involved: a BEP20 token is a smart contract deployed on BNB Smart Chain that implements a standard interface for fungible tokens — similar to Ethereum's ERC20 standard. A smart contract is self-executing code stored permanently on the blockchain — once deployed, its core logic cannot be altered. OpenZeppelin is the industry-standard library for secure contract development; using it as a base is a positive signal, but it does not guarantee the overall design is safe or non-custodial.

The TokenSeller Risk in Plain Language

Imagine buying tokens at a private sale, then discovering that whether you can actually transfer or sell those tokens depends on a separate contract controlled by the project team. That is exactly what the SQUA architecture implements. The vesting mechanism — while described in the whitepaper as a feature — relied entirely on the project team maintaining and correctly configuring the TokenSeller contract.

When GoFintech Group collapsed and the team abandoned the project, the TokenSeller contract was left in whatever state it was last configured. Depending on those settings, some wallets may have found their tokens permanently restricted. This is a direct consequence of using a centralized transfer gate rather than a time-locked vesting contract controlled by the blockchain itself.