How to test the Zircon Beta

Learn what you can do on the Zircon Beta to maximize rewards.

After the release of the Zircon Beta last week we’ve collected more than 50,000 interactions between our two Routers. Thank you so much to anyone who tested our system and hunted for bugs!

Some people in our community asked for a few recommendations on how to better stress test the system, so here we’re going to explain a few things that you can do.

What we’re looking for

The highest priority for the beta test is ensuring the smart contracts work flawlessly.

This means that no combination of flash loan attacks, weird tokens or bugs in the code can extract money from the system.

Finding bugs is all about being creative with how you attack the system. Try to combine multiple different things into one unified attack. Use very large numbers, use flash loans, use custom tokens.

For most of these things you’d probably need to be a developer to work with all the available tools. We’re very open to experts poking in our system, and you can check out all our code on Github for some whitebox references and confirmation.

What if you’re not a developer?

You can still definitely pick the low hanging fruit, if there is any (there probably is).

Here are a few tips to find potential bugs:

• Carefully track the amounts you’re putting in and what you’re getting out.

• Do multiple passes of the same action to amplify any potential value loss.

• Try multiple approaches. Supply liquidity with Sync (default mode), withdraw with Async. Then supply again with Async and withdraw with Sync. Switch between 100% and 50/50, just try it all!

• Create new pools, then drain them completely, then fill them with one token and see what happens. These are the most critical edge cases.

• Try dumping or pumping a token’s price between mint and burn, and see what happens!

• The block explorer is your friend. Use Blockscout to track what happens in each transaction.

You’ll know you’ve found a bug when you end with more tokens than you did at the start.

That means you’ve extracted value from the protocol, which endangers everyone else.

Obviously, it’s important that you as an individual user also don’t lose too much, so if you’re suddenly left with zero that’s a critical bug as well. But keep in mind that there are fees and slippage involved with most transactions, so it’s normal that repeating a certain action many times will leave you with less tokens than before.

Here’s a few more intended features:

• If you withdraw Anchor tokens you may suffer slashing up to 100%. In production this would be covered by fees and economic support, but in testnet it’s likely that all Anchor withdrawals will suffer some slashing.

• If you supply with Async 100%, you could potentially get back much fewer tokens than if you used Sync or Async 50/50. This is because the system sells your share against the pool, so the liquidity is corrected by slippage.

• When extracting liquidity in 50/50 mode, you’re limited by how much liquidity is in the underlying pool. If you try to withdraw everything, the transaction will fail.

Reporting a submission

We’ve opened a form to collect all bug reports. This also includes UI bugs and other minor issues, so feel free to report them too!

We aim to treat each valid submission as a bug bounty, which for now offers:

• Guaranteed inclusion in our PoinZ whitelist

• Generous allocation of PoinZ depending on severity

You can read more about what this means here.

As for what counts as a valid submission, it means that you need to be the first to report the bug and write enough details so that we can reproduce it and understand what’s happening.

Good luck with the hunt 🦁