Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Fabric Protocol Safe?

ROBOEthereum
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 →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance4/10Upgrades7/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The ERC20Token contract implements a standard ERC20 token with OpenZeppelin's ERC20Permit and Ownable extensions.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 30% (100.0% total → 40.0% effective; 0.0% in EOAs, 100.0% in contracts — moderate)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockUnknown
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
100.0%Contracts
100.0%Contracts
ContractsBubble area = share of supply
100.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking100.0%
Effective concentrationwhat the score reads40.0%
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$459.4K across 2 pairs

The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$439.9KShare of depth95.8%

Security Findings

1 High1 Medium1 Low2 Info
High

Centralized Minting Power for Supply Restoration

The restoreSupply function allows the contract owner to mint new tokens up to the TOTAL_SUPPLY constant. While the total supply is capped, this function grants the owner significant power to re-introduce tokens into circulation that were previously burned, effectively undoing deflationary events. This centralized control over supply restoration can lead to unexpected inflation and impact token value if not managed transparently or with community oversight.H-01

Issue

The restoreSupply function allows the contract owner to mint new tokens up to the TOTAL_SUPPLY constant. While the total supply is capped, this function grants the owner significant power to re-introduce tokens into circulation that were previously burned, effectively undoing deflationary events. This centralized control over supply restoration can lead to unexpected inflation and impact token value if not managed transparently or with community oversight.

Fix

Implement a timelock for the restoreSupply function to introduce a delay before execution, allowing for community review and reaction. Alternatively, consider a multi-signature approval process beyond the standard owner for such a critical function, or remove the function entirely if the intent is for a truly fixed and non-restorable supply.

Status

Unresolved

Medium

Single Metadata Change Limitation

The updateNameAndSymbol function, callable only by the owner, includes a require(!_metadataChanged, "Name and symbol can only be changed once") check. This design choice permanently restricts the ability to update the token's name and symbol after the first modification. While this prevents arbitrary changes, it removes flexibility for future branding, re-organizations, or corrections if a mistake is made during the single allowed update.M-01

Issue

The updateNameAndSymbol function, callable only by the owner, includes a require(!_metadataChanged, "Name and symbol can only be changed once") check. This design choice permanently restricts the ability to update the token's name and symbol after the first modification. While this prevents arbitrary changes, it removes flexibility for future branding, re-organizations, or corrections if a mistake is made during the single allowed update.

Fix

Assess if this single-change limitation aligns with long-term project goals. If future flexibility is desired, consider removing the _metadataChanged flag or implementing a more robust governance mechanism for metadata updates, potentially with a timelock or multi-signature approval for subsequent changes.

Status

Unresolved

Low

Inefficient EIP-712 Domain Separator Computation

The _buildCurrentDomainSeparator function, which is called by DOMAIN_SEPARATOR and _hashTypedDataV4, recomputes the EIP-712 domain separator on every invocation. In OpenZeppelin's standard ERC20Permit implementation, the domain separator is typically cached to avoid redundant computations, especially since the name and symbol (which are part of the domain) are only intended to change once. Repeated computation incurs unnecessary gas costs for permit operations.L-01

Issue

The _buildCurrentDomainSeparator function, which is called by DOMAIN_SEPARATOR and _hashTypedDataV4, recomputes the EIP-712 domain separator on every invocation. In OpenZeppelin's standard ERC20Permit implementation, the domain separator is typically cached to avoid redundant computations, especially since the name and symbol (which are part of the domain) are only intended to change once. Repeated computation incurs unnecessary gas costs for permit operations.

Fix

Cache the EIP-712 domain separator in a state variable and update it only when the token's name or symbol changes via updateNameAndSymbol. This will optimize gas usage for permit calls.

Status

Unresolved

Info

Redundant Name and Symbol State Variables

The contract declares private state variables _name and _symbol in addition to inheriting these properties from the ERC20 base contract. While the name() and symbol() overrides correctly return these private variables, and they are used to facilitate the updateNameAndSymbol function, it introduces a slight redundancy. If not carefully managed, this could lead to inconsistencies, although in this specific implementation, they are updated together.I-01

Issue

The contract declares private state variables _name and _symbol in addition to inheriting these properties from the ERC20 base contract. While the name() and symbol() overrides correctly return these private variables, and they are used to facilitate the updateNameAndSymbol function, it introduces a slight redundancy. If not carefully managed, this could lead to inconsistencies, although in this specific implementation, they are updated together.

Fix

Ensure that the custom _name and _symbol variables are always kept in sync with the underlying ERC20 state if the intention is to override the base ERC20 behavior. The current implementation correctly handles this by overriding the getters and updating the custom variables.

Status

Unresolved

Info

Fixed Total Supply with Owner-Controlled Restoration

The contract defines a TOTAL_SUPPLY constant, implying a fixed maximum supply. However, the restoreSupply function allows the owner to mint tokens up to this TOTAL_SUPPLY if the current supply is lower due to burns. This means the 'fixed' total supply is only a cap, and the circulating supply can fluctuate up to this cap based on owner actions, rather than being strictly immutable after initial minting.I-02

Issue

The contract defines a TOTAL_SUPPLY constant, implying a fixed maximum supply. However, the restoreSupply function allows the owner to mint tokens up to this TOTAL_SUPPLY if the current supply is lower due to burns. This means the 'fixed' total supply is only a cap, and the circulating supply can fluctuate up to this cap based on owner actions, rather than being strictly immutable after initial minting.

Fix

Clearly document and communicate this behavior to all token holders and potential investors. Emphasize that while there is a maximum supply, the actual circulating supply can be increased by the owner up to this maximum if tokens are burned. This transparency is crucial for managing expectations regarding tokenomics.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The ERC20Token contract implements a standard ERC20 token with OpenZeppelin's ERC20Permit and Ownable extensions. The contract features a fixed total supply, user-initiated burning, and an owner-controlled function to restore the supply up to the initial cap. While the technical implementation is robust, leveraging audited libraries and Solidity 0.8+ safety features, the centralized minting capability held by the owner introduces a High economic risk. The owner (a multisig) can mint tokens up to the initial total supply, which could impact token value if not managed transparently. Additionally, the ability to change token metadata (name/symbol) is restricted to a single instance, which might be inflexible for future branding needs.

Technical8/10Low risk

The contract leverages well-audited OpenZeppelin libraries for ERC20, ERC20Permit, and Ownable functionalities (7.2 Code Security). Solidity version 0.8.20 provides default overflow/underflow checks, enhancing numerical safety. The architecture is straightforward, extending standard patterns (7.1 Architecture). However, the custom EIP-712 domain separator implementation recomputes the domain separator on every call, which is less efficient than caching (7.2 Code Security). No reentrancy vectors or oracle manipulation risks were identified (7.2 Code Security).

Governance4/10Medium risk

The contract's economic model features a fixed TOTAL_SUPPLY, but the restoreSupply function grants the owner the power to mint tokens up to this cap if the current supply is lower (7.4 Economic). This centralized minting capability, while capped, introduces a significant economic risk as it allows the owner to inflate the supply after burns. Access control is managed via Ownable, with critical functions like restoreSupply and updateNameAndSymbol restricted to the owner (7.3 Access Control). The updateNameAndSymbol function can only be called once, which might limit future flexibility for branding (7.5 Governance). The owner is a multisig, which mitigates single-point-of-failure risks for operational control (7.8 Operations).

Upgrades7/10Low risk

The contract is not designed to be upgradeable; it does not implement any proxy patterns (7.7 Upgrades). This simplifies the architecture by removing upgrade-related complexities and risks. The immutability of the contract after deployment means its logic cannot be altered, providing a fixed and predictable behavior.

Final RecommendationWhat to do about this score

It is recommended to clearly communicate the owner's ability to restore the token supply up to the initial TOTAL_SUPPLY to all token holders, as this can impact tokenomics.

Consider implementing a timelock for sensitive owner actions, such as restoreSupply, to provide transparency and allow community reaction time. For the EIP-712 domain separator, optimize its computation by caching the value to reduce gas costs for permit operations.

Contract & Record

1 audit on record
TypeERC20Token
NetworkEthereum
Token age5mo
Contract0x32b4…f36e
Deployer0x53e2…6181
Badge for your website
Fabric Protocol security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202648Medium
  2. Aug 15, 202648Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the ROBO contract address?

The Fabric Protocol (ROBO) contract on Ethereum is 0x32b4d049fe4c888d2b92eecaf729f44df6b1f36e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Fabric Protocol a scam?

Quantum Audit's risk score for Fabric Protocol is 48/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Who holds ROBO?

As of Sep 4, 2026, the 10 largest holders own 100.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
EdgeEthereum48Mediumc8ntinuumCTM · Ethereum49MediumSafe TokenSAFE · Ethereum47MediumLQTYEthereum47MediumCurve DAOCRV · Ethereum49MediumVestra DAOVSTR · Ethereum47Medium

Would You Like a More Detailed Audit of Fabric Protocol?

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