Running a Code4rena Audit

Drafted June 2025. Finished and published August 2026 as part of the migration away from WordPress.

On 19 May 2025, we opened two of Upside’s smart contracts to a seven-day Code4rena audit. The audit closed at 20:00 UTC on 26 May. In total, 937 wardens participated.

The final report recorded zero High or Medium findings and 27 reports containing Low or non-critical issues. This is what running the audit looked like from the sponsor side.

Why Code4rena

This was one of several audits of contracts I had written. Previous projects had spent tens of thousands on conventional audits, including reviews which returned no High or Critical findings. Those reviews still provided assurance, but the fee was spent regardless of the result.

Code4rena offered a different model. The total award pool for this competition was $13,000 USDC, but up to $9,600 was reserved for valid High and Medium findings. If none were found, that part of the pool fell to zero. We still paid for QA reports, judging and scouting, but most of the potential cost was tied to someone finding a serious vulnerability.

That alignment was what attracted us to the competition format. A clean result would not make the audit free, but it would not cost the same as an audit which uncovered a High or Medium issue.

Preparing the audit

The public scope was deliberately small: UpsideProtocol.sol and UpsideMetaCoin.sol, which Code4rena counted as 379 lines of Solidity. The staking contracts were excluded so the audit could concentrate on token creation, trading and fee handling.

Code4rena assembled a public competition repository containing the frozen contracts, build instructions, known design decisions and a basic Hardhat proof-of-concept harness. Any High or Medium submission had to include a runnable proof of concept using that test suite.

Three days before the audit opened, I recorded a 24-minute code walkthrough. I went through the system’s architecture, its main transaction paths and the assumptions a reviewer needed before reading individual functions. There was no separate written documentation for the competition, so the walkthrough became an important part of the briefing.

Who was involved

I was the technical point of contact on the sponsor side, answering questions about the contracts and their intended behaviour.

Code4rena’s thebrittfactor and CloudEllie coordinated the competition, kept the repository and instructions clear, and turned recurring questions into public clarifications. The wider review came from the participating wardens.

The audit week

The audit opened at 20:00 UTC on Monday 19 May. Questions started arriving the next morning.

I clarified that the contracts were intended for Base, that USDC was the liquidity token and that the tokenisation fee could be paid with an approved ERC-20 token. I also re-shared the walkthrough so the answers and architectural context were visible in the same public channel.

Code4rena clarified that Hardhat should be used for proof-of-concept tests wherever possible. The repository wording was tightened during the week so that everyone was working from the same submission requirements.

That was roughly the rhythm for the seven days: wardens reviewed the code, questions came through public and private threads, I answered protocol-specific points, and Code4rena handled the competition process. The audit closed on schedule at 20:00 UTC on Monday 26 May.

Judging and the final report

After the submission window closed, I reviewed the findings from the sponsor’s side while Code4rena’s judge assessed their validity and severity. Awards were announced on 4 June, nine days after the audit ended. Brene produced the top QA report, with kjibi778 and hgrano also receiving awards.

The final report followed on 8 June. No High or Medium finding survived judging. The 27 lower-severity reports covered issues including front-running the tokenisation of a desirable URL, ownership transfers not updating the fee recipient, and very small trades rounding their fee down to zero.

Zero High and zero Medium does not prove that a contract is safe. It means that no issue at either severity was confirmed within that scope and audit window.

Why the process ran smoothly

From the sponsor side, the audit was straightforward for a few practical reasons:

• the scope was narrow and frozen;
• the walkthrough gave every warden the same architectural briefing;
• I was available to answer protocol questions;
• recurring questions were answered publicly;
• High and Medium claims had to be backed by runnable tests.

There were still clarifications to make, particularly around deployment assumptions and proof-of-concept requirements, but they were resolved without changing the scope or interrupting the audit.

The useful outcome was not just the severity count. The code, walkthrough, discussion and final report formed a public record of what was reviewed, how it was reviewed and what the competition found.