Skip to content

Security Finding: Potential Architecture Gap in OpenHack Challenge #4

Description

@orizta

Hi GitBank team,

I'm writing following a review of the OpenHack challenge you published at gitbank.io/openhack.


Summary

Based on on-chain analysis of the published addresses, I identified a potential discrepancy between the described architecture and the actual Base Mainnet deployment.


Technical Details

  1. Funds do not appear to be held inside a vault contract

    • The owner address (0x639df7b02daf540f145b4a9aab76e9896af7dd0c) is a standard EOA, not a vault proxy.
    • The gitUSDC token (0xCFD8296ECc8541B2174f6e25cf6f69f5DC85E98A) is held directly at that EOA, according to Basescan data.
    • If accurate, this means the dual-sig protection of the GitVault contract is not actively guarding these funds.
  2. No mainnet vault contract address is documented

    • The README at github.com/gitbankio/contracts lists only Base Sepolia deployment addresses — no mainnet equivalent.
    • No verified vault contract on Basescan appears to be linked to the challenge address.
  3. Token contract source code is not verified

    • The source code of 0xCFD829... has not been verified on Basescan; only bytecode is available.
    • This makes the public audit you invited through the challenge significantly harder to perform.

Potential Risk

If funds are held in a plain EOA rather than a vault, anyone in possession of the published private key could transfer tokens directly — without needing to bypass the dual-sig mechanism at all. This would not be a smart contract vulnerability, but a potential misconfiguration in the challenge setup.


Recommendations

  • Confirm that funds have actually been deposited into a deployed vault contract before the challenge is considered live.
  • Publish the mainnet vault address in the README and verify its source code on Basescan.
  • Clarify whether gitUSDC represents an internal soul-bound claim certificate or is backed 1:1 by real USDC held in the vault.

I'm sharing these findings in good faith, in the spirit of the public challenge you opened. I hope this is useful feedback for strengthening both the architecture and the transparency of the system.

Best regards,
[Orizta]

My addy : 0xCb433105E076CF42FFAAb1e37e03755287f42DD5

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions