Is Gram (prev. Toncoin) (GRAM) Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High2 Med1 Low1 Info

Critical

Incorrect Quorum Calculation for 2/3 Majority

C-01The `generalVote` function calculates the required number of signatures for a 2/3 majority using integer division: `signatures.length >= 2 * oraclesSet.length / 3`. This calculation incorrectly truncates the result, leading to a lower-than-intended quorum for many `oraclesSet.length` values. For example, with 2 oracles, it requires 1 signature instead of 2; with 4 oracles, it requires 2 signatures instead of 3. This significantly weakens the security of the multi-signature scheme, making it easier for a minority of oracles to pass votes.

IssueThe `generalVote` function calculates the required number of signatures for a 2/3 majority using integer division: `signatures.length >= 2 * oraclesSet.length / 3`. This calculation incorrectly truncates the result, leading to a lower-than-intended quorum for many `oraclesSet.length` values. For example, with 2 oracles, it requires 1 signature instead of 2; with 4 oracles, it requires 2 signatures instead of 3. This significantly weakens the security of the multi-signature scheme, making it easier for a minority of oracles to pass votes.

FixModify the quorum calculation to correctly implement ceiling division for 2/3 of the oracle set. The formula `(2 * oraclesSet.length + 2) / 3` should be used to ensure the correct number of signatures is required. Thoroughly test this change with various oracle set sizes.

StatusUnresolved

High

Centralization Risk and Oracle Compromise

H-01The entire security and integrity of the Bridge contract, including token minting, oracle set updates, and burn status control, relies on the honesty and security of the oracle set. A compromise or collusion of 1/3 + 1 oracles (e.g., 2 out of 3, or 3 out of 4 with the current bug) can lead to unauthorized minting of tokens, disabling of the burn mechanism, or taking full control of the oracle set. This represents a significant centralization risk inherent to the design.

IssueThe entire security and integrity of the Bridge contract, including token minting, oracle set updates, and burn status control, relies on the honesty and security of the oracle set. A compromise or collusion of 1/3 + 1 oracles (e.g., 2 out of 3, or 3 out of 4 with the current bug) can lead to unauthorized minting of tokens, disabling of the burn mechanism, or taking full control of the oracle set. This represents a significant centralization risk inherent to the design.

FixWhile this is a fundamental design choice, it is crucial to acknowledge and mitigate the risks associated with oracle centralization. Implement robust off-chain security practices for oracle key management, multi-factor authentication, and continuous monitoring. Consider mechanisms for emergency pauses or community-driven overrides if a supermajority of oracles is compromised, though this would require significant architectural changes.

StatusUnresolved

High

Vote Finalization Before Action Execution

H-02In the `generalVote` function, the `finishedVotings[digest] = true` flag is set *before* the actual action (e.g., `executeMinting`, `updateOracleSet`, `allowBurn = newBurnStatus`) is performed. If the subsequent action reverts due to an unexpected condition (e.g., an internal error in `mint`, or a `require` statement failure in `updateOracleSet`), the vote will still be marked as finished. This prevents any retry for that specific digest, potentially leaving a valid vote in a 'stuck' state where the action was intended but never completed.

IssueIn the `generalVote` function, the `finishedVotings[digest] = true` flag is set *before* the actual action (e.g., `executeMinting`, `updateOracleSet`, `allowBurn = newBurnStatus`) is performed. If the subsequent action reverts due to an unexpected condition (e.g., an internal error in `mint`, or a `require` statement failure in `updateOracleSet`), the vote will still be marked as finished. This prevents any retry for that specific digest, potentially leaving a valid vote in a 'stuck' state where the action was intended but never completed.

FixRefactor the `generalVote` function to set `finishedVotings[digest] = true` *after* the successful execution of the associated action. This ensures that a vote is only marked as complete if its intended effect has been successfully applied to the contract state. Alternatively, implement a mechanism to allow a failed vote to be retried or explicitly cancelled by a supermajority.

StatusUnresolved

Medium

Outdated Solidity Compiler Version

M-01The contract uses Solidity `^0.7.0` and `^0.7.4`. These versions do not include automatic overflow and underflow checks for unsigned integers, which are standard in Solidity 0.8.0 and later. While no direct overflow/underflow vulnerabilities were identified in critical arithmetic beyond the quorum calculation, relying on older compiler versions increases the risk of subtle arithmetic bugs and misses out on other security improvements and optimizations present in newer versions.

IssueThe contract uses Solidity `^0.7.0` and `^0.7.4`. These versions do not include automatic overflow and underflow checks for unsigned integers, which are standard in Solidity 0.8.0 and later. While no direct overflow/underflow vulnerabilities were identified in critical arithmetic beyond the quorum calculation, relying on older compiler versions increases the risk of subtle arithmetic bugs and misses out on other security improvements and optimizations present in newer versions.

FixConsider upgrading the contract to Solidity 0.8.x. This would provide automatic overflow/underflow checks, reducing the need for manual `SafeMath` implementations or extensive manual checks. A thorough review and testing process would be required to ensure compatibility and address any breaking changes introduced by the newer compiler version.

StatusUnresolved

Medium

`oracleSetHash` Parameter Unused in `updateOracleSet`

M-02The `voteForNewOracleSet` function takes an `int oracleSetHash` parameter, which is used to generate the digest for the vote. However, the `updateOracleSet` function, which is called after a successful vote, receives this `oracleSetHash` but does not use it to verify the `newSet` array. While the `newSet` itself is part of the digest and directly applied, the `oracleSetHash` parameter could be misleading if it implies a verification that does not occur within the `updateOracleSet` function.

IssueThe `voteForNewOracleSet` function takes an `int oracleSetHash` parameter, which is used to generate the digest for the vote. However, the `updateOracleSet` function, which is called after a successful vote, receives this `oracleSetHash` but does not use it to verify the `newSet` array. While the `newSet` itself is part of the digest and directly applied, the `oracleSetHash` parameter could be misleading if it implies a verification that does not occur within the `updateOracleSet` function.

FixClarify the purpose of `oracleSetHash`. If it's purely an identifier for the vote, consider renaming it to avoid confusion. If it's intended to be a hash of the `newSet` for verification, implement the corresponding check within `updateOracleSet`. Ensure documentation clearly explains its role.

StatusUnresolved

Low

Initial Oracle Set Not Subject to Vote

L-01The `constructor` of the Bridge contract directly calls `updateOracleSet` with the `initialSet` provided during deployment. This means the initial set of oracles is established without any multi-signature vote. While this is a standard practice for contract initialization, it places full trust in the deployer to correctly and securely configure the initial oracle set.

IssueThe `constructor` of the Bridge contract directly calls `updateOracleSet` with the `initialSet` provided during deployment. This means the initial set of oracles is established without any multi-signature vote. While this is a standard practice for contract initialization, it places full trust in the deployer to correctly and securely configure the initial oracle set.

FixEnsure that the deployment process is highly secure and that the `initialSet` of oracles is carefully chosen and verified. Document this trust assumption clearly for users and stakeholders. This is generally acceptable for bootstrapping a system.

StatusUnresolved

Info

`experimental ABIEncoderV2` Pragma Used

I-01The contract uses `pragma experimental ABIEncoderV2;`. While ABIEncoderV2 has been widely adopted and is considered stable in practice, it was an experimental feature in Solidity 0.7.x. In Solidity 0.8.0 and later, it is enabled by default and the pragma is no longer necessary.

IssueThe contract uses `pragma experimental ABIEncoderV2;`. While ABIEncoderV2 has been widely adopted and is considered stable in practice, it was an experimental feature in Solidity 0.7.x. In Solidity 0.8.0 and later, it is enabled by default and the pragma is no longer necessary.

FixThis is an informational note. If upgrading to Solidity 0.8.x, this pragma can be removed. No immediate action is required for functionality or security in 0.7.x, but it's a reminder of the compiler version's experimental features.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates a clear architecture for a multi-signature bridge, leveraging inherited ERC20 and signature verification functionalities (7.1). However, a critical flaw exists in the quorum calculation within the `generalVote` function, requiring fewer signatures than intended for a 2/3 majority (7.2). Additionally, the `finishedVotings` flag is set before action execution, potentially leaving valid votes in a stuck state if the subsequent action reverts (7.2, 7.8). The use of Solidity 0.7.x also means a lack of automatic overflow/underflow checks (7.2). Access control is robustly enforced via the oracle majority mechanism (7.3), and external interactions are limited to internal calls (7.6).

GovernanceHigh1/10

The economic model centers around the minting and burning of a wrapped token, controlled by a set of oracles. The primary economic risk stems from the centralization inherent in the oracle system; a compromise or collusion of 1/3 + 1 oracles could lead to arbitrary token minting or disabling of burning, directly impacting the token's value (7.4, 7.5). The governance mechanism, based on a 2/3 oracle vote, is intended to secure these operations, but the identified quorum calculation bug severely undermines this security (7.5). The initial oracle set is established by the deployer without a vote, which is a standard trust assumption for bootstrapping (7.5).

UpgradesMedium5/10

The contract is not designed as an upgradeable proxy, therefore, no upgrade-specific risks or safety issues are present (7.7).

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

30.1% in top 10

26.7% in wallets3.4% in contracts

Effective Concentration28.1%

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

$985.8K across 6 pairs

Uniswap v3WETHanalysed$793.2K Uniswap v4ETH$173.5K Uniswap v4ETH$7.9K Uniswap v2WETH$4.4K Uniswap v4ZIK$4.2K Uniswap v3USDC$2.6K

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.

LP Distribution

Top-1 Unlocked Holder72.0%

Top-3 Unlocked91.1%

Key Addresses

11 addresses

Deployer

0x0ade…00e2

Unlocked LP Held By

0x5a8c…2cc70x483f…e9f10xb156…dc9d0xe890…78320x3cd5…788e0xc325…bc1d0x91d4…e21a0x18c8…42250xae22…0c450x5bf9…79af

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

9 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 20% (30.1% total → 28.1% effective; 26.7% in EOAs, 3.4% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 72.0% (independent LP — depth risk, pool = 80% of DEX liquidity)
LP top3 unlocked holders = 91.1% (independent LP — depth risk, pool = 80% of DEX liquidity)
1 Critical finding(s) from audit
2 High finding(s) from audit
2 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

Not Signed In

Is Gram (prev. Toncoin) Safe?

Security Findings

Incorrect Quorum Calculation for 2/3 Majority

Centralization Risk and Oracle Compromise

Vote Finalization Before Action Execution

Outdated Solidity Compiler Version

`oracleSetHash` Parameter Unused in `updateOracleSet`

Initial Oracle Set Not Subject to Vote

`experimental ABIEncoderV2` Pragma Used

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Gram (prev. Toncoin)?