Smart Contract Analysis Statement

Program Analysis

The IDareYou program is a multi-funder crowdfunded escrow for "dares" on the Solana blockchain, where a crowd pools SPL tokens toward a creator-set floor, the dared party posts proof of performance within a window, settlement is optimistic, and disputes are resolved by a platform arbiter into one of three outcomes. The overall design follows common Anchor patterns and is unusually well prepared, with a clear state machine, snapshotted per-dare economics, pull-style refunds, and careful pooled-funds accounting. No critical or high severity issue was identified.

This is a re-audit statement following a remediation pass. Every code-level issue from the original review has been verified fixed in source, and no fix introduced a new fund-loss path or weakened the safety posture:

• The pause toggle now rejects a call that does not change the pause state, so the freeze timestamps only move on a real pause or unpause. The indefinite deadline-deferral path is closed.
• The parameter-rotation instruction now bounds the post-unpause grace by the same one-day cap the creation instruction enforces, restoring the intended timing control.
• The final close and dispute resolution now create the fee-recipient token account on demand, so a missing fee account can no longer block rent reclaim or any dispute verdict.
• The funding and performance deadlines now extend for a pause that overlapped them, matching the settlement and dispute deadlines, so a completed freeze no longer forces a premature expiry.
• The admin actions now emit events, and the fee is now charged on the live vault balance so direct vault transfers are fee-charged rather than handed to the receiver untaxed.

The items that remain are operational or accepted by design, plus two minor informational notes opened during the re-audit:

• The program is upgradeable and its upgrade authority is currently a single ordinary wallet rather than a multisig. This remains the single largest risk and must be placed under a multisig, or the program finalized, before mainnet; the team has committed to this as a pre-mainnet step.
• Mints added to the allowed list are still not checked for a freeze authority. This is accepted with rationale because the stated primary settlement token is a regulated stablecoin that carries an issuer freeze authority by design; the residual risk is that such an authority could freeze a vault and lock that dare's pooled funds, and it should be disclosed to users.
• The standalone formal proof of the fee arithmetic and a coverage note still describe the previous fee basis and should be updated to the live-balance basis; the new formula is safe by inspection.
• The funding and performance pause compensation only applies once a freeze has ended, so a window that lapses while the program is still paused can still be expired to the refunding state during the freeze. This is safe-direction, since funds become refundable rather than trapped or paid out.

Authority Privileges

The upgrade authority of the program has been set to a single ordinary wallet on devnet and has not been moved to a multisig or finalized. The authority retains full privileges including:

• Replacing the entire program with new code through an upgrade, which is the highest-impact power and must be placed under a multisig or finalized before mainnet.
• Pausing and unpausing the program, which blocks new funding, creation, claiming, and optimistic settlement while leaving every exit, refund, and cleanup path available.
• Rotating the platform role, the claim authority, and the fee recipient, and re-pricing fees and time windows for future dares only.
• Adding token mints to the allowed list and acting as the sole recovery path for a lost or compromised claim authority.
• The admin cannot change the economics of dares that already exist, because the fee and all time windows are snapshotted onto each dare at creation.
• The admin cannot move funds out of any existing vault, because the vault's authority is the per-dare program-derived account, not the admin.
• The platform role can flag and resolve disputes and can take down a dare before any proof exists, but every outcome only pays the receiver, refunds the funders, or burns the bond to a fixed incinerator address, so it can never route funds to itself.
• The claim authority can bind a wallet as the receiver of a dare, so a compromise there is an impersonation risk rather than a direct theft, and it is intended to be hardened to a signed attestation before mainnet.

Security Features

The program implements several positive security features:

• Strong pooled-funds accounting, where the recorded pledged total stays in lockstep with the actual vault balance on every payout state, the fee split was proven not to overflow or underflow, and each funder can receive only one of a refund or a share of the payout.
• A one-way state machine with write-once fields and hard state checks on every transition, so a claim, a proof, or a dispute record cannot be silently rewritten and there is no dead state from which funds cannot exit.
• Consistent account validation, with framework-checked account ownership and discriminators, program-derived addresses re-derived on-chain with stored canonical bumps, no calls to user-supplied programs, and every fund destination pinned to the expected account or address.
• A circuit breaker that fails safe by blocking new value coming in while keeping every refund and recovery path live, so funds remain recoverable while the program is paused.

Note - This Audit report consists of a security analysis of the IDareYou Solana program. This analysis did not include economic analysis of the project's tokenomics. Moreover, we only audited the main program for the IDareYou team. Other programs and the off-chain services associated with the project, including the components that hold the claim authority and platform keys, were not audited by our team. We recommend investors do their own research before investing.