Is Fabric Protocol (ROBO) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low2 Info

High

Centralized Minting Power for Supply Restoration

H-01The `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.

IssueThe `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.

FixImplement 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.

StatusUnresolved

Medium

Single Metadata Change Limitation

M-01The `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.

IssueThe `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.

FixAssess 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.

StatusUnresolved

Low

Inefficient EIP-712 Domain Separator Computation

L-01The `_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.

IssueThe `_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.

FixCache 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.

StatusUnresolved

Info

Redundant Name and Symbol State Variables

I-01The 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.

IssueThe 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.

FixEnsure 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.

StatusUnresolved

Info

Fixed Total Supply with Owner-Controlled Restoration

I-02The 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.

IssueThe 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.

FixClearly 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.

StatusUnresolved

Category Ratings

TechnicalLow8/10

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).

GovernanceHigh3/10

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).

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

100.0% in top 10

0.0% in wallets100.0% in contracts

Effective Concentration40.0%

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.

Liquidity Depth

$459.4K across 2 pairs

Uniswap v3USDCanalysed$439.9K Uniswap v4USDC$19.5K

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

Key Addresses

1 addresses

Deployer

0x53e2…6181

What Raised This Score

6 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)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
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

Is Fabric Protocol Safe?

Security Findings

Centralized Minting Power for Supply Restoration

Single Metadata Change Limitation

Inefficient EIP-712 Domain Separator Computation

Redundant Name and Symbol State Variables

Fixed Total Supply with Owner-Controlled Restoration

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Fabric Protocol?