{"bounty":{"chain_id":8453,"hub_address":"0x8f80d1183cd983b01b0c9ac6777cc732ec9800de","bounty_id":"3","poster":"0x5b69cc1b1dfe8cf9addc91ff795b5cb05f4e4f91","status":"open","winner":null,"submission_deadline":1795305540,"judging_deadline_at":1795435140,"settlement_timeout_at":1795564740,"escrow":{"token_address":"0x833589fcd6edb6e08f4c7c32d4f71b54bda02913","amount":"36000000"},"guardian_roster_hash":"0x717091d098f69dc975abcb7775556cf24cc8c01d901ebf03f573f0f703954fc5","guardian_roster":[{"name":"Dark Tang","account":"0xbaf7d9d21447db598c502bbb8ddcf25d279adc60","encryption_public_key":"MoZYm0-WvaMQAozZ6wKbXySs4g2tr3wPmmt5kfv1TUk"},{"name":"Rare Mussel","account":"0xa4a3f99b302c61412bd87f5f5d7703d5c2cea849","encryption_public_key":"b3NG1NbiNsLXeyD4SVeQkztlFssbOnJw5tHjDpCelgs"},{"name":"Loud Abalone","account":"0x84e981caab8db3c8e0e4508a0ecac97b8fe39073","encryption_public_key":"0H3apAAV3y5crIsfZGt_jy2fSXYMkwCnC3EoxKFiFGc"}],"payout_scheme":"0x36d304993cb1575a2f9b8a0388b18aa5ec6d7a61","treasury_recipient":"0xd3ce7873ba9b86385f0c1226c3c585a9bca0d277","treasury_fee_bps":0,"guardian_fee_recipient":"0xd3ce7873ba9b86385f0c1226c3c585a9bca0d277","guardian_fee_bps":1000,"spec_commitment":"0x452dd0b49e1755356baa5f9bb40cd5bf8188bebd922181c89e3157a564c99568","submissions":[],"submission_count":0},"challenge":"---\nprofile: elgora_markdown_bounty_challenge_v1\nescrow_amount: \"36000000\"\nsubmission_deadline: 1795305540\npayout_policy: winner_take_all\n---\n\n# ElgoraHub Escrow Security Bounty\n\n## Summary\n\nIdentify and demonstrate a smart-contract vulnerability in ElgoraHub that causes unauthorized or excess USDC payments, permanent freezing of USDC escrow, or insolvency.\n\nThis 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.\n\nA 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.\n\nSubmit a runnable local Foundry proof of concept and a concise Markdown explanation. This bounty purchases vulnerability evidence, not a patch or general audit.\n\nThe earliest active qualifying Submission wins.\n\n## Challenge details\n\n### Target\n\n- Network: Base mainnet, chain ID 8453.\n- ElgoraHub: `0x8f80d1183cd983b01b0c9ac6777cc732ec9800de`.\n- USDC: `0x833589fcd6edb6e08f4c7c32d4f71b54bda02913`.\n- Payout scheme: `0x36d304993cb1575a2f9b8a0388b18aa5ec6d7a61`.\n- Submission guard: `0xe0d404c22228b03d5b8a715cb569c4944bc5a27a`.\n- Coordinator: `0xB24A68BC7e3E18f62bd6A2672D534C38b9471E48`.\n- Reference state: the end of Base block `54134664`.\n- Reference block hash: `0x483d2181a1549f931e8fd44a0b010e32ee1a519aa84cf706e7a2d5b7d93d7240`.\n- Reference block timestamp: `1794017308` (Unix seconds).\n- Original Hub deployment block (provenance only): `51752389`.\n- Hub deployment transaction: `0xd62f407b770c8fca82a9704b30ed0605d9e3ed2b56278dcca152958063f7f469`.\n- Public repository: https://github.com/moleculeprotocol/elgora-contracts.\n- Pinned public repository commit: `9990996658c31b11e4fe9c125371553bbbe7e360`.\n- Export source commit (provenance): `8d40270d617a63dd5a7a35045db0d9ea3ddd9093`.\n\nThe 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.\n\nLater live configuration or repository changes do not change this challenge.\n\nThe coordinator is a reference role for reproducing settlement timing. Access to its keys or scheduled job is not required or authorized.\n\n### Reference configuration and fixture scope\n\nReproduce 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. \n\nFund 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.\n\n| Target setting | Required fixture value |\n| --- | --- |\n| Guardian roster | 3 distinct Guardians in the order below; 2 matching votes required |\n| Minimum / maximum bounty duration | 259,200 / 5,184,000 seconds (3 / 60 days) |\n| Guardian review window | 259,200 seconds (3 days) |\n| Judging deadline | Submission deadline + 129,600 seconds |\n| Settlement timeout | Submission deadline + 259,200 seconds |\n| Treasury / Guardian fee | 0 / 1,000 basis points |\n| Minimum / maximum escrow | 20,000,000 / 250,000,000 USDC smallest units |\n| Coordinator / grace period | Listed coordinator / 3,600 seconds |\n| Submission guard / payout scheme / escrow token | Listed target addresses, or permitted local substitutes |\n| Guard default maximum submissions | 10; no per-bounty override in the fixture |\n| Hub and guard owner; roster administrator; both fee recipients | One shared trusted role: `0xd3Ce7873BA9b86385f0C1226C3c585a9BCa0D277` |\n| Pending owner, Hub and guard | Zero address |\n| Hub paused / pausing disabled | `false` / `false` |\n| Guard binding | Bound to the fixture Hub |\n\nIn 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:\n\n1. `0xBAF7d9D21447Db598C502bBb8dDcf25D279aDC60`\n2. `0xA4A3f99b302c61412bD87f5F5D7703d5c2CEa849`\n3. `0x84E981caab8Db3C8E0E4508a0EcAC97b8Fe39073`\n\nLocal 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.\n\nSet 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.\n\nThe 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.\n\nThese 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.\n\n### Attacker capabilities and prerequisites\n\nThe attacker starts with ordinary accounts and no privileged access or compromised keys. It may deploy helper contracts and call public interfaces.\n\nAn 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.\n\nExplain 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.\n\nA victim cannot be assumed to sign an attacker’s authorization, grant extra permissions, or otherwise cooperate in the attack.\n\n## Inputs, Materials and References\n\n### Public repository and local setup\n\nUse the public contracts repository at the fixed commit below. No access to the private Elgora repository is required.\n\n- [Pinned repository snapshot](https://github.com/moleculeprotocol/elgora-contracts/tree/9990996658c31b11e4fe9c125371553bbbe7e360)\n- [Build instructions and source correspondence](https://github.com/moleculeprotocol/elgora-contracts/blob/9990996658c31b11e4fe9c125371553bbbe7e360/README.md)\n- [Contract overview](https://github.com/moleculeprotocol/elgora-contracts/blob/9990996658c31b11e4fe9c125371553bbbe7e360/docs/PROTOCOL.md)\n- [Export provenance and source hashes](https://github.com/moleculeprotocol/elgora-contracts/blob/9990996658c31b11e4fe9c125371553bbbe7e360/SOURCE.json)\n\n```sh\ngit clone https://github.com/moleculeprotocol/elgora-contracts.git\ncd elgora-contracts\ngit checkout --detach 9990996658c31b11e4fe9c125371553bbbe7e360\ngit submodule update --init --recursive\nforge build\nforge test --no-match-path 'test/fork/*'\n```\n\nInitial 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.\n\nThe 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.\n\n### Known behavior and prior reviews\n\n- [Known behavior and security limitations](https://github.com/moleculeprotocol/elgora-contracts/blob/9990996658c31b11e4fe9c125371553bbbe7e360/KNOWN_ISSUES.md)\n- [Astra and Fabel security review index](https://github.com/moleculeprotocol/elgora-contracts/blob/9990996658c31b11e4fe9c125371553bbbe7e360/audits/README.md)\n- [Private vulnerability reporting policy](https://github.com/moleculeprotocol/elgora-contracts/blob/9990996658c31b11e4fe9c125371553bbbe7e360/SECURITY.md)\n\nThese 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.\n\n### Verified deployment sources\n\nPublic verified sources, dependencies, compilation information, and constructor arguments:\n\n- Hub:\n  https://basescan.org/address/0x8f80d1183cd983b01b0c9ac6777cc732ec9800de#code\n- Payout scheme:\n  https://basescan.org/address/0x36d304993cb1575a2f9b8a0388b18aa5ec6d7a61#code\n- Submission guard:\n  https://basescan.org/address/0xe0d404c22228b03d5b8a715cb569c4944bc5a27a#code\n\nSHA-256 hashes of the UTF-8 source-file contents:\n\n- `src/ElgoraHub.sol`:\n  `7465c2421fc942e473ce166369d3ac3bb3c00b9efe33cae837470a05a0aa0b6b`\n- `src/WinnerTakesAllPayoutScheme.sol`:\n  `0149aee8f04e5e4cb15c89d1b96f4822cd3ae9222e5aa3d406e26479380331c2`\n- `src/CappedSubmissionGuard.sol`:\n  `70ad6cf85833a6024bc023d103f016b54d8f698826eca0f0800badaa31fd373e`\n\nThese hashes apply to source-file contents, not explorer HTML.\n\nUse 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.\n\nReference deployment transaction:\n\nhttps://basescan.org/tx/0xd62f407b770c8fca82a9704b30ed0605d9e3ed2b56278dcca152958063f7f469\n\nMap 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.\n\nThe 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.\n\n## What you need to submit (Deliverables)\n\n1. **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.\n2. **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.\n\nStandard Foundry tooling and Solidity 0.8.36 may be installed prerequisites. Supply source and build instructions for any additional required software.\n\nThe test must assert the claimed failure. Evidence may appear in the report, assertions, or generated output; separate trace or accounting files are not required.\n\nChoose your own filenames and folder structure. Include required code and report content as bytes in the Submission. Links cannot replace them.\n\nRemediation code is not requested and receives no ranking credit.\n\n### Local reproduction\n\nThe 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”.\n\nUse a deterministic Foundry reproduction that executes without live RPC access or other external services.\n\nElgora’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.\n\nSupply 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.\n\nUse the target contract code without behavioral modifications. Local address substitutions must preserve role relationships and must not give the attacker privileged access.\n\nLegitimate setup may include:\n\n- Funding local test actors before they fund bounties normally.\n- Creating bounties and valid Submissions.\n- Recording truthful Guardian Verdicts consistent with those Submissions.\n- Permitted coordinator settlement and beneficiary claims.\n- Forward-only advancement of time or block number.\n\nIdentify setup actions separately from the exploit. Do not assume malicious Guardian cooperation.\n\nDo not manufacture the result through target storage edits, code replacement, mocked call results, or direct alteration of the Hub’s token balance.\n\nA 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.\n\nIf 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.\n\n\n## Acceptance Criteria\n\nA finding qualifies only when the submitted code and evidence establish:\n\n1. **Correct target:** the failure applies to the specified contracts and reference configuration.\n2. **Reachability:** the attack and its prerequisites are possible under the stated threat model.\n3. **Impact:** after a completed transaction, at least **1 USDC (1,000,000 smallest units)** of a qualifying impact is demonstrated affecting a victim, as defined under **“Qualifying impacts”** and **“Minimum impact and affected party”**.\n4. **Correct accounting and authorization:** expected recipients and amounts follow from legitimate funding, lifecycle outcomes, and fee rules.\n5. **Reproducibility:** the supplied command deterministically demonstrates the failure from the submitted fixture using a fixed sequence or seed.\n6. **Root cause:** the result comes from the target contracts, not a test-harness error, unrealistic substitute, or unsupported assumption.\n\nA passing test alone does not establish validity. A revert, compilation error, screenshot, scanner warning, or allegation without a demonstrated impact is insufficient.\n\nOnly findings satisfying every acceptance criterion and no applicable exclusion qualify. A severity label, meeting the 1 USDC minimum, or being the only Submission is insufficient. The exclusions below are mandatory. Reproducing an excluded behavior more thoroughly, assigning it a higher severity, or describing its existing fee or refund consequence does not make it eligible. A distinct accounting or authorization failure involving the same function may qualify only if it independently meets all acceptance criteria and does not rely solely on an excluded behavior.\n\nA Submission qualifies if it contains at least one qualifying finding and is not disqualified. Negative findings and general audit reports do not qualify.\n\nPayment does not depend on providing a fix, the team adopting submitted code, or demonstrating an attack against live funds.\n\n### Qualifying impacts\n\nDemonstrate an escrow-accounting or payment-authorization failure causing at least one of:\n\n1. **Unauthorized payment:** escrow reaches an account that is not entitled to it.\n2. **Excess payment:** an account receives more escrow than it is entitled to.\n3. **Permanent loss of access:** a legitimate beneficiary cannot obtain owed escrow through the contract’s available settlement, timeout, or claim paths, including the owner-assisted recovery described below.\n4. **Insolvency:** legitimate outstanding obligations exceed the escrow funds backing them.\n\nAn incorrect counter, event, display, or intermediate calculation is insufficient unless it causes one of these four outcomes. An unauthorized claim credit must be shown payable through the real claim path, or shown to create insolvency; merely writing or assuming a credit is insufficient. A hypothetical future loss does not qualify.\n\nFor permanent loss of access, the Submission must establish that the affected amount remains inaccessible through the available settlement, timeout, claim and authorized owner-assisted recovery paths on the same Hub. For each applicable recovery path, explain why it cannot restore the affected funds to their legitimate recipient from the post-exploit state. Showing only a failed claim, or stating that nobody demonstrated a rescue, is insufficient. Assume deadlines can elapse, recipients can transact, and the Hub and token permit normal operation. A single revert or temporary delay is insufficient.\n\nA permanent-freeze claim is unproven if the Submission leaves an identified recovery path unresolved. That path must be supported by the target contract code and its prerequisites in the demonstrated post-exploit state.\n\nA freeze does not qualify as permanent if an existing authorized recovery path on the same Hub can restore the full affected amount to its legitimate recipient, including through an owner configuration call followed by normal settlement or claims. Authorized configuration changes are permitted when assessing recovery after the exploit. New deposits, donations and replacement deployments do not count as recovery. This exception applies to permanent-freeze claims; it does not erase an independently demonstrated unauthorized payment, excess payment or insolvency.\n\nEntitlements follow from legitimate funding, accepted lifecycle outcomes, and applicable fee rules. A corrupted counter or an attacker-created record does not establish a legitimate entitlement.\n\n### Minimum impact and affected party\n\nA **victim** is an account whose legitimate funds or entitlements are affected and that is neither the attacker, an account it controls, nor a party cooperating with the attack. These may include a Poster’s funded escrow or refund, a Solver’s legitimate award, or a Guardian or treasury fee allocation. A victim must not cooperate with the attack or grant the attacker extra permissions. The origin of the funding does not exclude a legitimate entitlement subsequently owed to a victim. This definition does not create an entitlement from unsettled Guardian consensus or override any exclusion below.\n\nA single finding must demonstrate at least **1 USDC (1,000,000 smallest units)** of unauthorized or excess payment, permanently inaccessible legitimate escrow, or insolvency shortfall affecting a victim. Findings confined to the attacker's own funds or entitlements do not qualify.\n\nVictims may be simulated locally and must perform only ordinary funding and lifecycle actions. Identify their legitimate funds or entitlements and show the financial effect on them.\n\nAn attack performed through the attacker's own bounty can qualify if it causes a qualifying impact meeting the minimum on a victim's funds or legitimate entitlements. For theft from the Hub's shared balance, show that funds or obligations owed to a victim are underfunded by at least 1 USDC (1,000,000 smallest units) after the attack; beneficiaries need not first attempt withdrawals. Merely showing that bounties share one Hub balance is insufficient.\n\nCount only the amount affected by the vulnerability, not total escrow, legitimate fees, normal rounding, funds that remain the attacker's own, gas expenditure or opportunity costs. Do not count the same loss twice under different impact categories. Distinct findings cannot be added together to reach the minimum.\n\nAttacker costs or lack of profit do not disqualify a finding that otherwise meets every acceptance criterion and exclusion. An attack may qualify even when it costs the attacker more than the victim loses.\n\nRepeated exploitation of the same root cause may meet the minimum only if the submitted runnable proof executes the sequence and demonstrates the cumulative impact on the victim's funds or entitlements. Each step must remain reachable under the reference configuration and stated threat model; an extrapolated estimate is insufficient.\n\nUse integer USDC smallest units. Track unsolicited transfers separately; they must not conceal a shortfall. Reaching the minimum does not override any exclusion.\n\n### Accounting evidence\n\nInclude before-and-after assertions reconciling actual Hub USDC with independently derived legitimate obligations for every bounty in the fixture. The reconciliation must include:\n\n- Full funded escrow reserved for each open bounty, counted once until a valid settlement or timeout replaces that reserve with allocations.\n- Unpaid legitimate refunds and remaining legitimate winner allocations for closed bounties.\n- Unpaid treasury and Guardian fee allocations, counting each shared fee pool once.\n- Actual completed payments and claims, deducted from the corresponding obligation; unexplained or unauthorized payments must remain visible as discrepancies.\n\nDo not count both an open escrow reserve and its later allocations, or count shared fees again per bounty. Derive legitimate obligations from normal funding, valid lifecycle outcomes and the specified allocation rules, not solely from counters or claim records that the exploit corrupts. Include legitimate attacker entitlements in the reconciliation, but exclude fabricated entitlements and do not count attacker-only losses toward the minimum.\n\nFor an insolvency claim, show `shortfall = max(0, legitimate unpaid obligations - actual Hub USDC balance)`. To establish victim exposure to a pooled shortfall, the proof must demonstrate a reachable sequence of actual contract calls after which the remaining legitimate obligations owed to victims exceed the remaining Hub USDC balance by at least 1 USDC. Attacker-controlled or cooperating accounts’ obligations are not victim obligations. Any attacker claims used in this sequence must execute successfully; hypothetical withdrawal priority is insufficient.\n\nAn unauthorized payment can instead be established by tracing the victim's allocation to an unauthorized recipient, even if the Hub's remaining balance still covers other obligations. Permanent inaccessibility requires identifying the affected legitimate amount and establishing the absence of an available recovery path; it does not require a pooled balance deficit.\n\n\n## How is the winner selected?\n\nAn 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.\n\n### 1. Mandatory financial-impact gate\n\nFindings 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.\n\nQualifying 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.\n\n### 2. Earliest active Submission\n\nAmong 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.\n\nThis 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.\n\nExactly one qualifying Submission wins the available Solver award. If none qualifies, the outcome is no_valid_submission.\n\n## Disqualification Conditions\n\nA 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.\n\nSubmit 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.\n\nAn 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.\n\n## Out Of Scope\n\n### Explicitly excluded known behaviors\n\nThe following mechanisms and their already documented consequences are excluded, as described in the pinned repository and reviews:\n\n- Address-based seat exhaustion, lack of identity or content-quality checks, and their effects on competition (FABEL-001 / ASTRA-002).\n- Guardian fees charged for nonempty bounties with no qualifying submission, including junk submissions removing the empty-bounty fee waiver (FABEL-002 / ASTRA-003).\n- Missed settlement windows leading to the specified full Poster refund, including coordinator timing and pauses (ASTRA-006 and KNOWN_ISSUES.md).\n- Early award Verdicts becoming stale after a Solver revises its commitment, preventing settlement and leading to timeout refund (FABEL-003).\n- Loss of seat history or revision availability following an authorized replacement of the submission guard (ASTRA-004).\n- 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.\n\nThese 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.\n\n### Other excluded findings\n\n- 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.\n- 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.\n- 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.\n- Informational, hardening, centralization, governance or trust-assumption observations without a qualifying accounting or authorization failure.\n- Economic incentives, opportunity costs, reduced competition, expected-profit claims, and fee-policy disagreements where transfers follow the specified contract rules.\n- Counter, event, display or accounting observations without demonstrated unauthorized payment, excess payment, permanent loss of legitimate escrow access, or insolvency.\n- Website, API, indexer, hosting, scheduled-job, and documentation vulnerabilities.\n- Gas optimization, code style, remediation work, and general best-practice recommendations.\n- Temporary delays without another qualifying financial impact.\n- Attacks that assume compromised keys, existing privileged access, or malicious Guardian cooperation.\n- Loss caused solely by a victim voluntarily transferring funds or granting the attacker the required authority.\n- Failures caused by token behavior absent from the specified target.","verification_record":null,"verification_record_error":null}