<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

transfer

transferFrom

totalSupply

balanceOf

allowance

approve

BEP20

OscarToken

In the contract `BEP20` the role `_owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/0a9467e4887e4798a9111a30c0611d58/diagrams/centralization_OscarToken-BEP20-_owner.svg)

- `mint(uint256 amount)`: Mints a specified amount of tokens for the caller (message sender) and returns true upon successful execution. This function can only be called by the contract owner.


In the contract `OscarToken` the role `_owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/0a9467e4887e4798a9111a30c0611d58/diagrams/centralization_OscarToken-OscarToken-_owner.svg)


- `mintFor(address _to, uint256 _amount)`: Mints a specified amount of tokens for a given address, and updates the delegate votes accordingly. This function can only be called by the contract owner.

Any compromise to the `_owner` account may allow the hacker to take advantage of this `authority` to manipulate the token supply. 

Centralization Risks in OscarToken.sol

In the Compound Finance protocol, votes are transferred in a 1:1 ratio with every transfer of tokens. For simplicity, if user A transfers 10 tokens to user B, then 10 of user A votes are transferred to user B as well. This implementation allows users to have freedom in who they would like to delegate their votes to. In this contract, `OscarToken`, the `moveDelegates()` function is not called after the `transfer()` function, `transferFrom()`, `burn()`, and `mint()` function. Therefore, users cannot delegate some of their votes to users or burn the delegation powers.

Users do have the ability to delegate all of their votes to one person. This is much more limiting than the protocol implemented in the Compound Finance protocol. 


A Proof of Concept is shown below to demonstrate this issue:
- The owner delegates to Alice;
- Alice gains all the voting power of the owner;
- The owner transferred 1 token to bob;
- But, Bob still has no voting power after receiving token from the owner;

```js
    //OscarToken.js
    it("lack of calling of _moveDelegates()", async function(){
        const [owner,alice, bob] = await ethers.getSigners();
        const TokenFactory = await ethers.getContractFactory("OscarToken");
        const token = await TokenFactory.deploy();
        
        //The owner delegates to alice
        await token.delegate(alice.address);
        //Query the first checkpoint
        const [, votesAlice] = await token.checkpoints(alice.address, 0);
        
        //Alice gains all the voting power of the owner
        expect(votesAlice).to.equal(ethers.BigNumber.from("100000000000000000000000000"));

        //The owner transfer 1 token to bob
        token.transfer(bob.address, 1);
        //Bob received 1 from the owner
        expect(await token.balanceOf(bob.address)).to.equal(1);
        
        //Query the first checkpoint
        const [, votesBob] = await token.checkpoints(bob.address, 0);
        //Bob still has no voting power afterreceivingd token from the owner
        expect(votesBob).to.equal(ethers.BigNumber.from("0"));
    })
```

```result
  //result
  OscarToken test
    ✔ lack of calling of _moveDelegates() (2214ms)
```

Similarly, in the `burn()` and `mint()` functions, the voting power should be moved from the user who burn the tokens to address(0) in `burn()` function, and be moved from the address(0) to the user who mint the tokens to in `mint()` function.

Reference: [Comp.sol](https://github.com/compound-finance/compound-protocol/blob/a3214f67b73310d547e00fc578e8355911c9d376/contracts/Governance/Comp.sol#L241)

Voting Power Not Moved Along With `transfer(), `transferFrom()`, `burn()` and `mint()`

ESDSA is susceptible to signature malleability. This is due to the fact that an Elliptic Curve is symmetric on the X-axis, meaning two points can exist with the same `X` value. In the `r`, `s` and `v` representation this permits us to carefully adjust `s` to produce a second valid signature for the same `r`, thus breaking the assumption that a signature cannot be replayed in what is known as a replay-attack.

### Proof of Concept

Using the signature obtained from https://solidity-by-example.org/signature/, the below unit test in `forge` shows that two different `s` and `v` values can produce the same address for one `r` value.

```solidity
pragma solidity 0.6.12;
pragma experimental ABIEncoderV2;

import "forge-std/Test.sol";

contract ECRecoverTest is Test {
    function setUp() public {
    }

    function getMessageHash(
        address _to,
        uint _amount,
        string memory _message,
        uint _nonce
    ) public pure returns (bytes32) {
        return keccak256(abi.encodePacked(_to, _amount, _message, _nonce));
    }

    function getEthSignedMessageHash(bytes32 _messageHash)
        public
        pure
        returns (bytes32)
    {
        return
            keccak256(
                abi.encodePacked("\x19Ethereum Signed Message:\n32", _messageHash)
            );
    }

    function testVerifySignature() public {
        bytes32 r = 0x993DAB3DD91F5C6DC28E17439BE475478F5635C92A56E17E82349D3FB2F16619;
        bytes32 s_a = 0x6F466C0B4E0C146F285204F0DCB13E5AE67BC33F4B888EC32DFE0A063E8F3F78;
        bytes32 s_b = 0x90B993F4B1F3EB90D7ADFB0F234EC1A3D43319A763C0117891D4548691A701C9;
        uint8 v_a = 0x1B; // 27
        uint8 v_b = 0x1C; // 28
        
        bytes32 messageHash = getMessageHash(0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C, 123, "coffee and donuts", 1);
        bytes32 ethSignedMessageHash = getEthSignedMessageHash(messageHash);

        address owner_a = ecrecover(ethSignedMessageHash, v_a, r, s_a);
        address owner_b = ecrecover(ethSignedMessageHash, v_b, r, s_b);
        assertEq(owner_a, owner_b);
    }
```

Susceptible to Signature Malleability

OpenZeppelin's `SafeMath` library is not used in the following functions, making it possible for overflow/underflow to occur and lead to inaccurate calculations.


- `getPriorVotes()`
- `delegateBySig()`
- `_writeCheckpoint()`


SafeMath Not Used

The `_decimals` variable assigned in the constructor can be declared as `immutable`. Immutable state variable can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variable is that reading them is significantly cheaper than reading from regular state variable since they will not be stored in storage.

Variables That Could Be Declared as Immutable

Oscarswap

OscarToken.sol

Formal Verification

Oscarswap is a decentralized exchange (DEX) that operates on the Arbitrum network, utilizing automated market-maker (AMM) technology. Its cutting-edge technology is designed to offer the lowest fees for swapping cryptocurrencies, coupled with highly profitable yield farming rewards, making it an ideal choice for passive income seekers.

Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program