Skip to content

Security Finding: Potential Architecture Gap in OpenHack Challenge #4

@orizta

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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions