Is Gram (prev. Toncoin) Safe? GRAM

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

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

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

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

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

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

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