BattleChain Confidence Pools

Description

The protocol models a corrupted agreement as a single security incident. Once an agreement is resolved as CORRUPTED, BattleChain designates a single attacker address, allowing only that address to claim the entire bounty. This design is reasonable for handling one exploit per agreement, after which the project can patch the issue, register a new agreement, and continue operating under a new confidence pool.

However, the implementation does not account for the case where multiple independent critical vulnerabilities exist simultaneously before the agreement is resolved.

For example, two or more security researchers may independently discover completely unrelated critical vulnerabilities that are each capable of compromising the protocol. Both reports may be submitted before governance finalizes the corruption event, yet only one researcher can ever be designated as the beneficiary because the protocol stores only a single attacker address.

As a result, one researcher receives the entire bounty while the remaining independently valid critical reports become uncompensated despite being submitted during the same corruption event.

This introduces a new incentive problem distinct from traditional duplicate reports. Researchers are no longer competing only to be the first reporter of the same vulnerability—they may also lose compensation despite discovering entirely different critical vulnerabilities simply because another independent exploit affecting the same agreement was selected as the payout event.

Risk

Likelihood:

• Large and complex protocols can contain multiple unrelated critical vulnerabilities simultaneously before the first vulnerability is exploited or before governance resolves the agreement.

• Multiple security researchers commonly audit the same protocol in parallel. Independent discoveries can therefore be submitted during the same confidence pool period, resulting in multiple valid critical reports competing within a single corruption event.

Impact:

• Only one researcher can receive the on-chain bounty, while other independently valid critical vulnerability discoverers receive no compensation despite submitting before the corruption event is finalized.

• The protocol removes uncertainty around project payout decisions but introduces a new uncertainty around beneficiary selection, partially undermining its goal of providing transparent and deterministic compensation for security researchers.

Proof of Concept

Assume a confidence pool contains:

During the lifetime of the agreement:

Both vulnerabilities:

• are completely unrelated,

• are independently exploitable,

• are reported before governance resolves the agreement,

• satisfy the requirements for a critical report.

The moderator resolves the agreement as:

Researcher A successfully claims the bounty:

Researcher B attempts to claim but execution always reverts:

Although Researcher B discovered an entirely different critical vulnerability during the same corruption event, the current implementation provides no mechanism for recognizing multiple beneficiaries or allocating rewards among multiple independently valid reports.

Recommended Mitigation

Possible approaches include:

• Replacing the single beneficiary model with a list of approved recipients and governance-defined reward percentages.

• Allowing governance to register multiple accepted critical reports before finalizing the corruption event.

• Introducing a reward allocation structure such as:

or

This preserves the protocol's one-corruption-event model while ensuring that multiple independently valid critical discoveries submitted before the agreement is resolved can all be compensated transparently on-chain.