ElgoraHub Escrow Security Bounty

Identify and demonstrate a smart-contract vulnerability in ElgoraHub that causes unauthorized or excess USDC payments, permanent freezing of USDC escrow, or insolvency.

This bounty covers only demonstrated financial impact on USDC escrow. Authorization bypasses and privilege escalation qualify only when the proof also demonstrates a qualifying financial consequence; gaining authority alone is insufficient.

A finding must affect at least 1 USDC belonging or owed to a victim, as defined below, and satisfy all acceptance criteria and exclusions. Informational findings, documented economic behavior, gas-cost concerns and speculative losses do not qualify. The best of several nonqualifying findings still receives no award.

Submit a runnable local Foundry proof of concept and a concise Markdown explanation. This bounty purchases vulnerability evidence, not a patch or general audit.

The earliest active qualifying Submission wins.

Target

• Network: Base mainnet, chain ID 8453.
• ElgoraHub: 0x8f80d1183cd983b01b0c9ac6777cc732ec9800de.
• USDC: 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913.
• Payout scheme: 0x36d304993cb1575a2f9b8a0388b18aa5ec6d7a61.
• Submission guard: 0xe0d404c22228b03d5b8a715cb569c4944bc5a27a.
• Coordinator: 0xB24A68BC7e3E18f62bd6A2672D534C38b9471E48.
• Reference state: the end of Base block 54134664.
• Reference block hash: 0x483d2181a1549f931e8fd44a0b010e32ee1a519aa84cf706e7a2d5b7d93d7240.
• Reference block timestamp: 1794017308 (Unix seconds).
• Original Hub deployment block (provenance only): 51752389.
• Hub deployment transaction: 0xd62f407b770c8fca82a9704b30ed0605d9e3ed2b56278dcca152958063f7f469.
• Public repository: https://github.com/moleculeprotocol/elgora-contracts.
• Pinned public repository commit: 9990996658c31b11e4fe9c125371553bbbe7e360.
• Export source commit (provenance): 8d40270d617a63dd5a7a35045db0d9ea3ddd9093.

The target is the specified Hub and its interactions with the listed payout scheme and submission guard, using their code and configuration at the reference block.

Later live configuration or repository changes do not change this challenge.

The coordinator is a reference role for reproducing settlement timing. Access to its keys or scheduled job is not required or authorized.

Reference configuration and fixture scope

Reproduce newly created bounties under the following reference configuration. This challenge does not target historical bounties created under earlier configurations. Start with an empty local Hub, zero claim and fee balances, and no pre-existing bounties.

Fund every test bounty through the local Hub’s normal funding functions from local test accounts, using the escrow token as specified under “Local reproduction”. No real funds, public-testnet tokens or live transactions are required.

In the local Foundry fixture only, register three simulated Guardian accounts mirroring the reference roster's structure. They represent honest Guardians and give the attacker no Guardian privileges; no interaction with the live roster and no real Guardian keys are required. The reference roster, in order, is:

1. 0xBAF7d9D21447Db598C502bBb8dDcf25D279aDC60
2. 0xA4A3f99b302c61412bD87f5F5D7703d5c2CEa849
3. 0x84E981caab8Db3C8E0E4508a0EcAC97b8Fe39073

Local substitutes may replace those accounts and the trusted role addresses, but must preserve the roster size, ordering, role overlaps and separation from the attacker. Register the local roster normally and use its computed roster hash; do not inject the mainnet hash into a differently configured local roster. Names and encryption keys may be local test values.

Set this configuration through constructors and ordinary authorized setup calls before the exploit. Keep privileged actors honest and configuration unchanged during the exploit, unless the proof itself demonstrates an ordinary caller's authorization bypass. All test bounty amounts and deadlines must satisfy the listed bounds.

The owner, roster administrator, fee recipients, Guardians and coordinator are trusted not to cooperate with the attacker. Findings must not assume compromised keys or deliberate privileged misconduct. This does not exclude an authorization bypass demonstrated under the attacker capabilities below.

These values define the audited target fixture only. They do not change this competition's platform fees, admission cap or operations. Reproducing the configuration requires no live RPC access during the test run.

Attacker capabilities and prerequisites

The attacker starts with ordinary accounts and no privileged access or compromised keys. It may deploy helper contracts and call public interfaces.

An authorization-bypass or privilege-escalation vulnerability is eligible if the reproduction shows how an ordinary caller obtains that capability and causes a qualifying impact. Merely assuming privileged access is not eligible.

Explain any required capital, approvals, signatures, transaction ordering, and victim actions. Show how those prerequisites arise under this threat model. If the attack depends on observing pending transactions or obtaining a particular transaction order, provide evidence that those prerequisites are achievable on Base without privileged sequencer access. Arranging calls in a local test alone does not establish this feasibility.

A victim cannot be assumed to sign an attacker’s authorization, grant extra permissions, or otherwise cooperate in the attack.

Public repository and local setup

Use the public contracts repository at the fixed commit below. No access to the private Elgora repository is required.

• Pinned repository snapshot
• Build instructions and source correspondence
• Contract overview
• Export provenance and source hashes

git clone https://github.com/moleculeprotocol/elgora-contracts.git
cd elgora-contracts
git checkout --detach 9990996658c31b11e4fe9c125371553bbbe7e360
git submodule update --init --recursive
forge build
forge test --no-match-path 'test/fork/*'

Initial setup downloads the repository, pinned dependencies and compiler. After setup, the submitted reproduction must run without live RPC access or other external services, as specified under “Local reproduction”. The repository's optional fork test is not required for this challenge.

The repository includes contracts outside this challenge's target, test mocks and deployment scripts. Their presence does not expand the target or authorize live deployment. Existing tests are supporting materials, not proof that a new finding qualifies. Construct the local fixture using the specified reference configuration; do not assume a default test fixture matches mainnet.

Known behavior and prior reviews

• Known behavior and security limitations
• Astra and Fabel security review index
• Private vulnerability reporting policy

These are research references. Their findings, ratings and unresolved questions do not replace this bounty's acceptance criteria or winner-selection rubric. The specific known behaviors listed under Out Of Scope are excluded from this competition, regardless of their review severity. Prior review labels are not evidence that a Submission qualifies. A GitHub vulnerability report does not replace an Elgora Submission or enter this competition.

Verified deployment sources

Public verified sources, dependencies, compilation information, and constructor arguments:

• Hub: https://basescan.org/address/0x8f80d1183cd983b01b0c9ac6777cc732ec9800de#code
• Payout scheme: https://basescan.org/address/0x36d304993cb1575a2f9b8a0388b18aa5ec6d7a61#code
• Submission guard: https://basescan.org/address/0xe0d404c22228b03d5b8a715cb569c4944bc5a27a#code

SHA-256 hashes of the UTF-8 source-file contents:

• src/ElgoraHub.sol: 7465c2421fc942e473ce166369d3ac3bb3c00b9efe33cae837470a05a0aa0b6b
• src/WinnerTakesAllPayoutScheme.sol: 0149aee8f04e5e4cb15c89d1b96f4822cd3ae9222e5aa3d406e26479380331c2
• src/CappedSubmissionGuard.sol: 70ad6cf85833a6024bc023d103f016b54d8f698826eca0f0800badaa31fd373e

These hashes apply to source-file contents, not explorer HTML.

Use the dependency revisions pinned by the public repository submodules: forge-std 77041d2ce690e692d6e03cc812b57d1ddaa4d505 and OpenZeppelin Contracts 5fd1781b1454fd1ef8e722282f86f9293cacf256. The repository documents correspondence with the verified deployment sources, including a comment-only difference in the payout scheme's imported IPayoutScheme.sol. Compile target contracts with Solidity 0.8.36, Cancun EVM target, optimizer enabled with 200 runs, and via-IR disabled.

Reference deployment transaction:

https://basescan.org/tx/0xd62f407b770c8fca82a9704b30ed0605d9e3ed2b56278dcca152958063f7f469

Map the local fixture to the reference configuration above and identify every permitted substitution. Additional chain-state assumptions are not permitted merely because a different current or historical setting can be found.

The pinned repository is the source and build starting point. The specified deployed contracts and reference-block configuration remain the target; later repository documentation or code changes do not change these terms.

1. Smart-contract proof-of-concept source code: a runnable Foundry test demonstrating the vulnerability in the target contracts, together with the local fixture, helper contracts, configuration and required dependency source.
2. A Markdown report: the root cause, affected functions, attacker prerequisites, reproduction command, tool versions (including the exact forge --version output), target correspondence, and demonstrated impact.

Standard Foundry tooling and Solidity 0.8.36 may be installed prerequisites. Supply source and build instructions for any additional required software.

The test must assert the claimed failure. Evidence may appear in the report, assertions, or generated output; separate trace or accounting files are not required.

Choose your own filenames and folder structure. Include required code and report content as bytes in the Submission. Links cannot replace them.

Remediation code is not requested and receives no ranking credit.

Local reproduction

The submitted proof must be a local Foundry reproduction. Exploit transactions against Elgora’s deployed contracts on Base mainnet or Base Sepolia are not authorized and make the Submission ineligible under “Disqualification Conditions”.

Use a deterministic Foundry reproduction that executes without live RPC access or other external services.

Elgora’s off-chain services are not part of the target and need not run. Simulate any required honest Guardian and coordinator actions directly against the local contracts.

Supply one focused command that replays an already identified failure. Open-ended fuzzing, searching for a successful seed, and rerunning the entire repository suite are not required reproduction steps. If discovery used fuzzing, submit the fixed counterexample as a deterministic test.

Use the target contract code without behavioral modifications. Local address substitutions must preserve role relationships and must not give the attacker privileged access.

Legitimate setup may include:

• Funding local test actors before they fund bounties normally.
• Creating bounties and valid Submissions.
• Recording truthful Guardian Verdicts consistent with those Submissions.
• Permitted coordinator settlement and beneficiary claims.
• Forward-only advancement of time or block number.

Identify setup actions separately from the exploit. Do not assume malicious Guardian cooperation.

Do not manufacture the result through target storage edits, code replacement, mocked call results, or direct alteration of the Hub’s token balance.

A local USDC substitute is permitted only when the exploit depends exclusively on ordinary balances, allowances, decimals, and transfers. It must transfer exact amounts, reject insufficient balances or allowances, and introduce no fees, rebasing, callbacks, or administrator intervention.

If other token behavior matters, include the relevant actual implementation and establish its correspondence to the reference state. Bugs in the token itself are outside this bounty.

An active Submission is eligible only if it contains at least one qualifying finding and is not disqualified. Multiple findings do not add together or improve its priority. Eligibility takes precedence over submission order.

1. Mandatory financial-impact gate

Findings that fail the Qualifying impacts section or fall within an exclusion are ineligible. There is no lower-severity accounting-only award and no fallback award for general audit findings.

Qualifying unauthorized payment, excess payment, permanent loss of access, and insolvency share the same eligible impact tier under this bounty's rubric. Insolvency requires evidence that legitimate obligations exceed their backing; beneficiaries need not have attempted every affected withdrawal. Impact on a victim is mandatory, not an optional ranking advantage. All findings that pass this gate are tied on severity for this bounty; submission order below decides. External severity labels do not introduce additional tiers.

2. Earliest active Submission

Among Submissions still tied, the active Submission with the lowest submission_call_count wins. submission_call_count is ElgoraHub's bounty-wide count of accepted submissions at that call; it rises with every call, so no two Submissions share one, and resubmitting replaces the active Submission and gives it a later count.

This rubric defines severity for this bounty. Beyond the mandatory 1 USDC minimum, dollar amounts, repeatability, number of findings, and remediation code are not separate ranking factors. Repeated exploitation may support evidence of impact but earns no independent preference.

Exactly one qualifying Submission wins the available Solver award. If none qualifies, the outcome is no_valid_submission.

A Submission containing only excluded findings or findings that fail any acceptance criterion is ineligible for an award, even if no other Submission qualifies. When no Submission qualifies, the outcome is no_valid_submission; being the earliest, the only, or the highest-rated nonqualifying Submission does not create entitlement to payment.

Submit exploit details and reproduction code privately through Elgora. Private reporting through the repository’s GitHub vulnerability-reporting channel is also permitted. A Solver who publicly releases previously nonpublic exploit details before the submission deadline is ineligible for this bounty. This restriction does not apply to source code or findings already public.

An excluded finding does not invalidate a separate qualifying finding in the same Submission. Fabricated evidence or unauthorized live exploitation performed for this challenge makes the entire Submission ineligible.

Explicitly excluded known behaviors

The following mechanisms and their already documented consequences are excluded, as described in the pinned repository and reviews:

• Address-based seat exhaustion, lack of identity or content-quality checks, and their effects on competition (FABEL-001 / ASTRA-002).
• Guardian fees charged for nonempty bounties with no qualifying submission, including junk submissions removing the empty-bounty fee waiver (FABEL-002 / ASTRA-003).
• Missed settlement windows leading to the specified full Poster refund, including coordinator timing and pauses (ASTRA-006 and KNOWN_ISSUES.md).
• Early award Verdicts becoming stale after a Solver revises its commitment, preventing settlement and leading to timeout refund (FABEL-003).
• Loss of seat history or revision availability following an authorized replacement of the submission guard (ASTRA-004).
• Increased settlement gas cost or a gas-budget-based denial of settlement, including a resulting timeout refund (ASTRA-001). This competition does not reward gas or availability findings alone.

These exclusions define reward eligibility only. They do not declare the behaviors safe, fixed or accepted as product risks. A distinct, demonstrated unauthorized payment or escrow-accounting failure is not excluded merely because it occurs in the same function.

Other excluded findings

• Specified rounding: fees round down and the remainder goes to the winner pool. This is an authorized allocation, not excess payment, regardless of the aggregate amount.
• Any known or new mechanism whose only financial consequence is the specified full Poster timeout refund. An unsettled Guardian consensus alone does not establish a payable award. A distinct unauthorized payment, insolvency or permanent loss of access to legitimately funded escrow must independently satisfy every acceptance criterion.
• Failures of Base, its sequencer, Ethereum L1, the token itself, the compiler or test tooling, rather than an exploitable accounting or authorization failure in the deployed target. A flaw reachable through the target's compiled library dependencies is not automatically excluded; it must meet every other criterion.
• Informational, hardening, centralization, governance or trust-assumption observations without a qualifying accounting or authorization failure.
• Economic incentives, opportunity costs, reduced competition, expected-profit claims, and fee-policy disagreements where transfers follow the specified contract rules.
• Counter, event, display or accounting observations without demonstrated unauthorized payment, excess payment, permanent loss of legitimate escrow access, or insolvency.
• Website, API, indexer, hosting, scheduled-job, and documentation vulnerabilities.
• Gas optimization, code style, remediation work, and general best-practice recommendations.
• Temporary delays without another qualifying financial impact.
• Attacks that assume compromised keys, existing privileged access, or malicious Guardian cooperation.
• Loss caused solely by a victim voluntarily transferring funds or granting the attacker the required authority.
• Failures caused by token behavior absent from the specified target.