Find a bug in the contract

[0xf965]

The contracts/bene_contract/contract_v2.es contract is the most delicate part of the application. Finding a bug in it will be considered as completing this task (difficulty: Hard) and will also grant 200 Bene. If you additionally propose a valid solution for the bug found, you will receive 800 extra Bene.

A bug in a smart contract is a failure in the logic or implementation that causes the contract to behave differently from what its KyA specifies — or, in some cases, due to an inaccuracy in the KyA itself. These issues can lead to loss of funds, unauthorized access, or blocked functionality, and they are especially critical because smart contracts are immutable once deployed.

It is possible that, after a thorough review, no bug is found.

To demonstrate a bug you have identified, you must:

• Create a PR that adds a new failing test (a reproducible test) along with a clear comment explaining the problem and its impact.
• Create a separate PR proposing the solution (including changes to the contract and/or tests that verify the fix).

This task is not exclusive: multiple teams can work on it simultaneously.

[skools-here]

I have identified a critical Asset Bleeding vulnerability at first glance.

The mantainValue check is commented out in the isBuyTokens, isRefundTokens, and isWithdrawFunds branches. This allows an attacker to drain the contract's accumulated ERG balance (setting the output value to minBox) while interacting with it in "Token Mode" (when !isERGBase), as the contract currently ignores ERG value preservation in this state.

I can resolve this , and I will submit the PRs for the failing test and the fix.

[0xf965]

@skools-here

Thanks for reviewing the contract.

The behavior you mentioned is not a bug. When we are in “token mode,” the ERG value of the contract can remain at the minimum (the minimum required to cover all bytes), and it must stay that way for anyone interacting with it if they want the nodes to accept their transaction.

There is no benefit to having more ERG than necessary when we are in “token mode,” so adding a condition to control this is unnecessary.

Remember that adding conditions brings two downsides:

1. More complexity in the spending script.
2. Larger script size.

So we should always try to keep the number of conditions to a minimum.

[skools-here]

@0xf965

Thanks for the feedback. I understand the goal of minimizing script size, but I believe this creates a security vulnerability regarding Storage Rent and accidental overfunding.

While the contract should ideally hold minimum ERG, the current logic permits permissionless theft if it ever holds more (e.g., a project owner funding the box with 5 ERG to prepay storage rent for long-term longevity, or a user accidentally attaching extra ERG).

The Exploit: Because mantainValue is disabled in Token Mode, if the contract holds 5.0 ERG (for rent), the next user can perform a valid Buy action, recreate the box with 0.001 ERG, and pocket the 4.999 ERG difference.

This bug effectively makes it impossible to prepay storage rent and incentivizes bots to drain any user errors. The proposed fix (valuePreservedIfTokenMode) adds negligible weight but closes this theft vector.

[0xf965]

@skools-here

The contract is intentionally designed to preserve tokens only in TokenMode, not ERG. The extra ERG isn’t meant to be stored long-term, and this contract isn’t a vault or expected to sit untouched for years. Only the minimum ERG is required, and users should never overfund the box. So the behavior you describe isn’t a bug for this contract’s intended use case.

[Shwetraj1]

The project owner address is provided as raw ErgoTree bytes (R8[0]) and may represent
either a simple P2PK (pay-to-public-key) contract or a more complex P2S (pay-to-script) contract.

In this contract we conservatively detect P2PK by checking:

1. A known ErgoTree header prefix used by P2PK scripts in this codebase, and
2. An exact expected length corresponding to a compressed EC public key (33 bytes).

This stricter check avoids calling decodePoint on malformed or non-P2PK scripts,
which could otherwise lead to unexpected failures or false positives.

For non-P2PK scripts (P2S and others), we intentionally do not attempt to parse
the ErgoTree structure here. Instead, ownership is validated by requiring that
an input box with matching propositionBytes is present in the transaction.

[algsoch]

Hey!

We're working on this for the Unstoppable Hackathon at LNMIIT Jaipur(team algsoch).

Our Plan

We'll do a thorough security audit of contract_v2.es, looking at:

• Integer overflow/underflow in counters and token math
• Access control issues (P2PK vs P2S authentication)
• State machine bugs in action validation
• Token calculation errors, especially in the exchange flow
• Deadline and threshold logic

How We'll Work

1. First, we're writing tests for potential vulnerabilities we've spotted
2. If we find a real bug, we'll submit a PR with a failing test and clear explanation
3. Then we'll submit a fix PR with the test passing

We've already gone through the full contract (all 583 lines) and have some ideas to test out. Should have something to show in the next 8-10 hours.

We noticed the earlier discussion about the "Asset Bleeding" issue - we'll make sure whatever we find is backed up with actual test cases that demonstrate the problem.

Thanks!

[algsoch]

Hey!

We're working on this for the Unstoppable Hackathon at LNMIIT Jaipur (team algsoch).

Update: We found a bug!

🔗 PR #95: #95

Bug Summary:

• Location: Line 100 in temporaryFundingTokenAmountOnContract
• Issue: Formula adds +exchanged instead of -exchanged
• Impact: After exchanges, contract thinks more tokens available than actually exist
• Proof: Mathematical test with step-by-step calculations included in PR

Our Approach

We did a systematic security audit of contract_v2.es (all 583 lines), focusing on:

• Integer overflow/underflow in counters
• Access control issues (P2PK vs P2S)
• State machine bugs
• Token calculation errors (found the bug here!)
• Deadline and threshold logic

We created a comprehensive test that mathematically proves the bug exists. See the PR for full details, visual proof, and proposed fix.

Thanks!

[Hammaduddin561]

From Team Elites at Unstoppable Hackathon,

We have identified a critical Liveness / Denial of Service bug in the contract logic.

The APTokenRemainsConstant check is strictly enforced in the isAddTokens branch. This makes it mathematically impossible for a Project Owner to replenish their stock, as adding PFTs (Proof-of-Funding Tokens) necessitates adding corresponding APTs (Auxiliary Tokens) for tracking, which this check forbids.

This effectively deadlocks the entire project after the initial supply is sold, preventing any further fundraising.

We can resolve this by allowing proportional APT addition.

[khush196]

BUG: Exchange Blocked After Refund Despite Campaign Success

Issue

The minimumReached check uses sold - refunded which allows refunds to
retroactively block token exchanges even after a successful campaign where
the owner already withdrew funds.

Severity

CRITICAL - Permanent loss of contributor tokens

Scenario

1. Campaign sells 50,000 tokens (minimum reached)
2. Owner withdraws funds successfully
3. One contributor refunds 1 token (net = 49,999)
4. All other contributors cannot exchange APT → PFT

Root Cause

Contract conflates "was minimum ever reached?" with "is net currently above
minimum?". The first should be immutable after withdrawals.

Evidence

Test "Minimum was raised, but actually not" (exchange.test.ts:660) demonstrates
this exact bug but treats it as expected behavior.

Impact

• Contributors lose tokens permanently
• Violates KyA guarantee
• Enables griefing attacks (cost: 1 token refund)

Files Affected

• contracts/bene_contract/contract_v2.es (line 229-234, 571)
• tests/contracts/exchange.test.ts (line 660-752)

Proposed Fix

Prevent refunds after any fund withdrawal, making campaign success irreversible.

I create an issue of bug in a contract:
#108