Qubicle Honeypot

What happened

Qubicle (QBE) has no global pause or transfer switch. Its trap is a per-holder time lock: transfer and transferFrom revert while locked[sender] < now is false, and lock(address addr, uint periodInDays) can be called by the saleAgent for any address. The saleAgent is set by setSaleAgent, which the owner (or the current agent) can call, and the lock length has no upper bound in the code.

A locked holder cannot move or sell QBE until the lock expires, and the contract has no unlock function. De.Fi's REKT database lists QBE as an exit scam/honeypot, stating that the owner could disable the transfer function.

How it happened

1. QBEToken overrides transfers with a lock check: require(locked[msg.sender] < now); in transfer and require(locked[_from] < now); in transferFrom, so a locked address cannot send tokens directly or have them pulled by a router.
2. lock sets the lock: require(locked[addr] < now && (msg.sender == saleAgent || msg.sender == addr)); locked[addr] = now + periodInDays * 1 days;. The saleAgent can therefore lock any address that is not already locked, for any number of days it chooses.
3. The saleAgent is assigned by setSaleAgent: require(msg.sender == saleAgent || msg.sender == owner); saleAgent = newSaleAgnet;. The owner can point it at any address, including one it controls.
4. Nothing in the contract clears locked[addr] before it expires, so a holder locked this way is stuck for the whole period; a holder locked for a very long period cannot sell at all.
5. The code shows this capability only. It does not show which address is the current saleAgent or that any holder was locked; no transaction was opened.

Protocol details

Classification Token

Protocol Type Exit Scam/Honeypot

Affected asset / contract QBE

Evidence

• report Report sec.gov
• address QBEToken source (Etherscan) etherscan.io
• code Code reference github.com
• analysis Sourcify match for 0xc029ba3dc12e1834571e821d94a07de0a01138ea repo.sourcify.dev