BullBear AI (AIBB) Price

AIBB's constructor mints 10^17 tokens once and credits them all to the deployer address. The contract uses 18 decimals: each AIBB equals 10^18 base units, so the initial issuance equals 10^35 base units. This is the initial issuance at deployment, not the current circulating supply.

Only the contract owner can call launch, and it requires that launch has not occurred previously. On success, it records the launch block number and timestamp, allowing addresses without pre-launch sending permission to pass the launch check for transfers; other conditions, including balances, still apply. This switch describes the token-transfer mechanism and does not indicate whether an AI product is live.

The pre-launch restriction checks the token sender. When the sender is on the canAddLiquidityBeforeLaunch allowlist, it can bypass the requirement that the contract has launched; putting only the recipient on the list does not allow an ordinary sender to pass. Although the variable name refers to adding liquidity, this check is used in the token-transfer path. The constructor puts the deployer and the token contract itself on this list, and the owner can add other addresses through a dedicated function. The allowlist only exempts the launch check; a transfer must still meet conditions such as having sufficient balance.

The owner can register an initial pair once with initializePair, and can later add or remove nonzero addresses with addPair and delPair. Registration is an internal set of addresses; it does not itself prove that an address has an active trading pool. Despite its name, getMinterLength returns the number of pairs, not the number of addresses authorized to mint.

The contract first checks the sender: if it is a registered pair, the transfer is handled as a buy. Otherwise, it checks the recipient; if the recipient is a registered pair, it is handled as a sell. If both are registered pairs, the sender check takes priority, so the buy path applies. An ordinary transfer in which neither party is a pair skips this fee branch. Classifying the direction does not by itself mean a fee is charged: the contract must also have launched, and neither sender nor recipient may be fee-exempt.

No. When the contract has launched, both parties are not exempt, and a registered pair is involved, the contract deducts the buy- or sell-side "treasury amount plus burn amount". These parameters are fixed quantities in token base units, rather than a percentage multiplied by the transfer amount; 10^18 base units equal 1 AIBB. Recipient amount = transfer amount − the treasury amount for that direction − the burn amount for that direction. The owner can separately change both amounts for buys and sells, so fixed amount describes the calculation method, not that the parameters can never change. The net-amount formula applies only to a successful transfer. If the applicable total fee exceeds the transfer amount, the subtraction underflows and the entire transaction reverts. An owner fee increase can therefore cause a previously viable transfer to fail; this does not establish the current fee settings.

In a fee-bearing transfer involving a registered pair after launch, with neither party fee-exempt, the treasury portion moves from the sender to treasureWallet and remains a token transfer. The burn portion is burned from the sender's balance and reduces totalSupply. The applicable amounts are selected by buy or sell direction. The owner sets the treasury recipient; this transfer mechanism itself does not give token holders a right to treasury distributions.

No. Fee exemption is recorded in isFeeExempt and can be set or removed by the owner; if either the sender or recipient is exempt, the buy/sell fee branch is not entered. Pre-launch permission is recorded in a separate list and checks only the sender. Fee exemption alone cannot replace pre-launch sending permission.

transferFrom first checks and spends the allowance that the sender gave the caller, then performs the token transfer. A finite allowance is reduced by the requested gross transfer amount, not by the net amount received after fees; insufficient allowance causes failure. An allowance equal to the maximum uint256 is treated as infinite and is not reduced when used. An approved transfer must still comply with the pre-launch sender restriction. If the contract has launched, neither party is exempt, and a registered pair is involved, the fee is also processed according to the applicable direction.

burn destroys the specified amount of AIBB from the caller's own account and requires a sufficient balance. Once successful, that account's balance and totalSupply both decrease by the same amount. The operation has no step that returns another asset to the caller, so it is not a redemption of another asset using AIBB.

No. burnFrom must first pass the allowance check granted by the target account to the caller, then burn the target account's tokens; the target account must also have enough balance. A finite allowance decreases by the burn amount, while an infinite allowance equal to maximum uint256 does not decrease. A successful burn reduces both the target account balance and total supply, so knowing an address alone does not allow its assets to be burned.

Only the owner may call rescueToken, which transfers the entire balance of a specified ERC-20 token held by the AIBB contract address to the caller. clearStuckEthBalance lets the owner transfer the contract's ETH balance. These functions act on assets held by the contract itself, not the balance of any token-holder account.