The BankToken contract is an ERC20-compliant token with a fixed maximum supply, inheriting from OpenZeppelin's battle-tested ERC20 and ERC20Capped implementations. The primary security consideration is the centralized minting authority, tgeContract, which holds exclusive power to mint new tokens up to the defined cap. While the contract's technical implementation is robust, the security of the tgeContract is paramount to the overall integrity of the token supply.

On-chain security analysis — is it a scam or legit?
Is Lorenzo Governance Token Safe?
Not verified
This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →The BankToken contract is an ERC20-compliant token with a fixed maximum supply, inheriting from OpenZeppelin's battle-tested ERC20 and ERC20Capped implementations.
Read the full analysis- Ownership not renounced
- Mintable supply, nominal cap 73%/year — effectively unbounded
- Top-10 concentration > 70%
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- LP top1 unlocked holder = 99.5%
- LP top3 unlocked holders = 100.0%
- 1 High finding(s) from audit
Exact factors
- Ownership NOT renounced (admin/mint authority retained)
- Mintable supply, nominal cap 73%/year — effectively unbounded
- Top-10 concentration > 70% (93.1% total → 70.9% effective; 56.2% in EOAs, 36.9% in contracts — extreme)
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- LP top1 unlocked holder = 99.5% (independent LP — depth risk, pool = 99% of DEX liquidity)
- LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
- 1 High finding(s) from audit
Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking36.9%
- Walletsanonymous holders, free to sell56.2%
- Everyone elsethe rest of the supply6.9%
How holder types affect the score
Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.
Holder balances as recorded by the audit of Sep 4, 2026
Liquidity
as of audit · Sep 4- Pancakeswap v3WBNBAnalysed$55.0K99.4%
- Pancakeswap v3WBNB$1340.2%
- Pancakeswap v2WBNB$990.2%
- UniswapUSDT$720.1%
- Pancakeswap v3USDT$90.0%
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x48c8…fc8f0x0564…5448No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized Minting Authority
The mint function in the BankToken contract is restricted to tgeContract via require(msg.sender == tgeContract, "Only TGE contract"). This design centralizes the power to mint new tokens up to the MAX_SUPPLY in a single external address. If the tgeContract address is compromised, an attacker could mint the remaining supply, leading to severe token devaluation and economic instability for the protocol. While the tgeContract is immutable, its operational security is critical.H-01
Issue
The mint function in the BankToken contract is restricted to tgeContract via require(msg.sender == tgeContract, "Only TGE contract"). This design centralizes the power to mint new tokens up to the MAX_SUPPLY in a single external address. If the tgeContract address is compromised, an attacker could mint the remaining supply, leading to severe token devaluation and economic instability for the protocol. While the tgeContract is immutable, its operational security is critical.
Fix
Implement robust security measures for the tgeContract address. This could include using a multi-signature wallet (e.g., Gnosis Safe), a time-lock mechanism for minting operations, or a decentralized autonomous organization (DAO) for governance over minting. Ensure the private keys controlling the tgeContract are stored securely and follow best practices for operational security.
Status
Unresolved
InfoUse of OpenZeppelin Standards
The BankToken contract inherits from OpenZeppelin's ERC20 and ERC20Capped contracts. These libraries are widely used, thoroughly audited, and considered industry standards for secure token implementations. This significantly reduces the risk of common vulnerabilities associated with custom token logic.I-01
Issue
The BankToken contract inherits from OpenZeppelin's ERC20 and ERC20Capped contracts. These libraries are widely used, thoroughly audited, and considered industry standards for secure token implementations. This significantly reduces the risk of common vulnerabilities associated with custom token logic.
Fix
Continue to leverage battle-tested libraries for core functionalities. Regularly monitor OpenZeppelin's security advisories and updates to ensure the project benefits from ongoing security improvements.
Status
Resolved
InfoImmutability of TGE Contract Address
The tgeContract address, which controls the minting function, is declared as immutable. This ensures that the designated minting authority cannot be changed after the contract's deployment. This design choice provides certainty regarding the minting controller and prevents potential malicious reassignments.I-02
Issue
The tgeContract address, which controls the minting function, is declared as immutable. This ensures that the designated minting authority cannot be changed after the contract's deployment. This design choice provides certainty regarding the minting controller and prevents potential malicious reassignments.
Fix
This is a good security practice for critical addresses that should not change. Ensure the initial deployment correctly sets the intended tgeContract address, as it cannot be modified later.
Status
Resolved
Analysis
AI Copilotas of audit · Sep 4The contract leverages OpenZeppelin's robust ERC20 and ERC20Capped implementations, ensuring adherence to established standards and mitigating common vulnerabilities (7.2 Code Security). Solidity 0.8.x's default checked arithmetic, combined with carefully placed unchecked blocks for safe operations, prevents integer overflows/underflows. Access control for the mint function is strictly enforced by checking msg.sender against the tgeContract address (7.3 Access Control). No reentrancy vectors were identified due to the absence of external calls to untrusted contracts.
The token design includes a fixed MAX_SUPPLY of 2.1 billion tokens, enforced by the ERC20Capped base contract (7.4 Economic). The tgeContract holds exclusive power to mint tokens up to this cap, representing a significant centralization of control over the token supply (7.5 Governance). While this is an explicit design choice, the security of the tgeContract is a single point of failure for token inflation. There are no on-chain governance mechanisms within this contract itself.
The BankToken contract is not designed to be upgradeable (7.7 Upgrades). This eliminates risks associated with proxy patterns, upgradeability logic, and potential upgrade path vulnerabilities. The tgeContract address is set as immutable, ensuring it cannot be changed post-deployment.
Prioritize the robust security of the tgeContract as it is the sole entity capable of minting new tokens.
Implement multi-signature wallets, time-locks, or other robust access control mechanisms for the tgeContract to minimize the risk of compromise. Conduct thorough testing of the tgeContract's interaction with the BankToken contract to ensure expected behavior and prevent unintended minting or supply manipulation.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202677High
- Aug 11, 202665High
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the BANK contract address?
The Lorenzo Governance Token (BANK) contract on BNB Chain is 0x3aee7602b612de36088f3ffed8c8f10e86ebf2bf. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is Lorenzo Governance Token a scam?
Quantum Audit's risk score for Lorenzo Governance Token is 77/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is BANK liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $55.3K.
Who holds BANK?
As of Sep 4, 2026, the 10 largest holders own 93.1% of the supply. The Holders section on this page shows who they are by holder type.
Would You Like a More Detailed Audit of Lorenzo Governance Token?
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page