Root + Impact

Description

• The vault is an ERC4626-compliant tokenised vault where users deposit assets to receive shares representing their proportional ownership in the prize pool. These shares are named "BriTechLabs" with the symbol "BTT".

• A separate ERC20 token contract BriTechToken.sol is included in scope with identical name and symbol ("BriTechLabs", "BTT"). This creates critical ambiguity: users and integrators cannot distinguish between vault shares (betting position) and the standalone token (potentially governance or utility). Given the protocol’s stated goal of DeFi integration and future yield strategies, it is highly likely BriTechToken.sol was intended to be the underlying asset of the ERC4626 vault — but was incorrectly deployed as a separate contract instead of being used as asset().

  // BriTechToken.sol

  contract BriTechToken is ERC20, Ownable {

  constructor() ERC20("BriTechLabs", "BTT") Ownable(msg.sender) {}

  // ...

  }

  ​

  // briVault.sol (ERC4626)

  function name() public view virtual override returns (string memory) {

  return "BriTechLabs";

  }

  function symbol() public view virtual override returns (string memory) {

  return "BTT";

  }

Risk

Likelihood: Medium

• Users interact with token metadata via wallets, explorers, and frontends that display name/symbol — duplicate identifiers appear indistinguishable

• DeFi protocols, aggregators, and analytics tools index tokens by name/symbol — collision leads to incorrect data routing and display

Impact: Low

• Users mistakenly treat vault shares as governance/utility tokens or vice versa — leading to failed transactions or unintended exposure

• Frontend integrations display wrong token (e.g. showing governance balance instead of betting position)

• Future integrations assuming BriTechToken is the vault asset will fail or behave unpredictably

Proof of Concept

• First, add this import statement along with others in briVault.t.sol:

  import {BriTechToken} from "../src/briTechToken.sol";
  
  

• Now, add this test_DuplicateTokenMetadata_Confusion test:

  function test_DuplicateTokenMetadata_Confusion() public {

  // Deploy standalone token

  BriTechToken standalone = new BriTechToken();

  ​

  // Log metadata

  console.log("Vault share name: ", briVault.name());

  console.log("Vault share symbol:", briVault.symbol());

  console.log("Standalone token name: ", standalone.name());

  console.log("Standalone token symbol:", standalone.symbol());

  ​

  // Both are identical

  assertEq(briVault.name(), standalone.name());

  assertEq(briVault.symbol(), standalone.symbol());

  }
  
  

• Run it using:

  forge test --mt test_DuplicateTokenMetadata_Confusion -vv
  
  

• Logs:

  Ran 1 test for test/briVault.t.sol:BriVaultTest

  [PASS] test_DuplicateTokenMetadata_Confusion() (gas: 1019985)

  Logs:

  Vault share name: BriTechLabs

  Vault share symbol: BTT

  Standalone token name: BriTechLabs

  Standalone token symbol: BTT

  ​

  Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 12.16ms (2.83ms CPU time)

Recommended Mitigation

• Use a distinct name and symbol to avoid collision with vault shares.

  // BriTechToken.sol

  contract BriTechToken is ERC20, Ownable {

  - constructor() ERC20("BriTechLabs", "BTT") Ownable(msg.sender) {}

  + constructor() ERC20("BriTech Token", "BRITECH") Ownable(msg.sender) {}

  // ...

  }
  
  

• Or, If BriTechToken was meant to be the underlying asset, then:

  • Pass its address to the briVault constructor.

  • Remove hardcoded name/symbol from vault.

  • Inherit metadata from the asset token (standard ERC4626 pattern)