This simple guide is intended for companies just bootstrapping their blockchain presence. If your business needs a workflow for minting tokens or operating smart contracts as a corporate entity using multisigs and you just purchased a few Ledgers for that, this guide shines some light on how to use hardware wallets in a safe way.

Core concepts

To sign transactions on most blockchain networks you need a private key. You can think of it as a file with secret data. If your private key is stolen, your identity is compromised and there is no way to recover from it: an attacker can impersonate you and sign transactions as if they were you.

A seed phrase is a sequence of words which are used to derive a private key. Stealing a seed phrase is the same as stealing a private key.

Hardware wallets are designed to make your private keys and seed phrases hard to steal by storing them on a separate device (instead of your laptop/pc which could be easily hacked).

Rule #1: Don't enter your seed phrase anywhere

During onboarding, your hardware wallet will generate a random sequence of 24 words, displaying one at a time on the device's screen — this is what is called a seed phrase. Write those words down on paper and put it in a deposit box in your bank.

Under no circumstances should you share the seed phrase with anybody. That includes typing these words anywhere, including your own laptop or your phone.

Rule #2: Use your wallet only for multisigs

Your wallet will be used for signing multisig transactions only. Do not store any funds on your wallet and do not use it for any personal activities.

Attackers will try to trick you into signing malicious transactions and it will not be possible to distinguish when it happens. To use most multisigs you will have to enable Blind signing so it will be impossible to validate what you are signing on the display of your wallet.

Connect your wallet only to the multisig website and nothing else.

Rule #3: Keep identities private

The address of your wallet is usually not considered to be private but it is important that your identity and the identities of other participants of multisigs are not disclosed.

If attackers know who the addresses belong to it makes it much easier to target these individuals with spear phishing. Protecting your identities will also minimise risks of targeted physical attacks and many other risks.

This is far from the exhaustive list of best practices but it is a good foundation keep you going. Read more about protecting yourself on-chain and keep an eye out for more posts!

Even if you are not doing anything out of the ordinary, even your priceless meme coins could still be drained, like in the recent ~500m ledger attack.

Here are a couple of quick tips on how to reduce such risks.

Separate your accounts

Most of your funds must be stored on a separate, dedicated address in a hardware wallet that is not used for your daily activities. Your hardware wallet can derive multiple accounts from a single seed phrase and splitting your daily account from your savings account this way will limit the impact of a compromise.

If you want to go further, set up an additional account derived from 13th or 25th word pass phrase, hidden behind a separate pin code.

Assume malicious destination

Always add the recipient addresses to your address book first and never copy or type these addresses again.

Attackers will try to fool you by generating malicious addresses matching most of the letters in the expected address so you must compare every single letter when adding new addresses to your address book.

You will see malicious addresses in the list of your past transactions, in your emails, messengers and your social media – don't trust anything not in your address book.

Always check the display of your hardware wallet when signing transactions – read and compare the destination address diligently.

Stay safe out there!

The largest bug bounty reward paid by Aurora last year was $800k, which is a big step down from $6m the year before. This post is a public retrospective and my thoughts on how to prevent similar bugs in the future.

What was the bug about

Rainbow Bridge allows sending tokens across blockchain networks by locking assets in a custodian contract on one chain, and minting new tokens on another.

The bug was in a component that is responsible for minting on the NEAR side. It allowed an attacker to drain all tokens from the custodian contract – one of the most critical bugs that could have devastated the entire NEAR ecosystem.

The core of the issue was in the log_index sent with the bridging “proof”:

#[serializer(borsh)] log_index: u64;

That value was converted to usize by the recipient contract, which is normally not a problem as it matches u64:

assert_eq!(receipt.logs[log_index as usize], log_entry);

However, on NEAR, the Rust code is compiled to wasm32 and as result the log_index is truncated.  By re-using the "proof" with a modified log_index value an attacker could mint tokens 2**32 times and drain all the assets in the custodian contract.

As simple as that!

Why it happened

We were well aware about wasm32 but the as_conversions Clippy check was not enabled for the affected component in the repository – our linter setup failed us. Our defensive programming practices were not good enough. The problem also wasn’t caught by internal reviews nor by multiple big-name auditors. 

Security is a cake and it’s absolutely required to have many layers! Stay humble and expect that any single measure could fail.

I promise to talk more about cakes later, but today I would like to say a couple of words about Clippy. 

Rust linting tips

Here is the bare minimum you have to do for setting up Clippy for security-sensitive applications:

• Explicitly enable all Clippy lints. Yes, you must enable all of them: for example, as_conversions are not included even in the pedantic group.
• Keep track of every single Rust component in your monorepos and make sure that Clippy configuration is consistent everywhere and that linter checks are actually executed in the CI.
• Make sure that Clippy config in the local development environments matches security CI workflows

While it may sound like a lot of work to address every single Clippy warning, it’s fast and simple compared to the rest of the security measures typically required – just don’t overlook the basics.

Hope these simple tips could prevent a hack of a decentralized bridge or two.

Kudos to Goohong Jung (cybermong) for responsibly disclosing the vulnerability and taking a well deserved place in our hall of fame.

The burden of on-chain change tracking is a main contributor to why bug bounty effectiveness declines over time. Below I explain why that is and my thoughts on how we can solve this.

False sense of security

The first months after launching bounties are the most impactful (and stressful!) We've paid most of the rewards within 3 months after including new contracts in scope of our bug bounty programs.

The initial smart contract launch often comes with a press release so bounty hunters rush to find low-hanging fruit missed by auditors. After some time the likelihood that "many eyes" have missed something declines, the whitehats switch to easier targets and, naturally, the quantity of bug reports decreases.

Unfortunately, there is no proportional influx of bug reports when major new features are released.

The bounty scope does not explicitly change and whitehats need to continuously keep track of significant changes in the smart contracts to assess the likelihood of new bugs being introduced – a much harder task to do.

In search of a solution

There must be no ambiguity when new risky features get shipped to the contracts that are already covered by the bounty program so that bug hunters can focus on what they do best – finding bugs, not keeping up with release schedules.

To do that we must reduce information asymmetry between the protocol developers and the whitehats as much as possible and introduce new incentives to bring bug bounty effectiveness back to the initial level:

• Announce significant changes for the contracts that are already in-scope
• Allow whitehats to claim rewards before these features hit the mainnet
• Provide an additional incentive for whitehats to audit such changes in a timely manner

Ideally, bug bounty platforms could have a feed of upcoming changes to the contracts that are already in scope, describing what has changed and incentivising researchers to audit them before a certain deadline. Unfortunately, most of the platforms do not provide these capabilities yet.

When it comes to Aurora, we are working with our partners on integrating the practice of audit contests directly into the bug bounty programs to address exactly this problem. The main difference from continuously running bounty programs is that such contests will be relatively short to provide time-sensitive feedback and will cover bugs that are normally out-of-scope e.g. non-production code that is behind feature flags, best practices and performance issues that could hint at security problems.

In conclusion, I firmly believe that alleviating the burden of change tracking from whitehats will significantly enhance the effectiveness of bug bounty programs, contributing to a more secure ecosystem. Stay tuned for insights and lessons learned as we roll out upcoming contests!

Why is there a problem?

The ERC20 standard does not inherently specify a token burning mechanism.

The most common implementation of ERC20, provides ERC20Burnable to solve that, but not all deployed OpenZepellin contracts include ERC20Burnable. Many ERC20 contracts are locked and not upgradeable.

Due to these constraints, projects seek alternative ways to approach token burns.

Do not use contract burns

One often recommended way to burn tokens involves creating a contract which immediately self destructs and sends tokens to its own address. However, this method comes with its set of challenges:

• Overhead of creating, deploying and testing such contract, especially if the burn needs to happen periodically
• Even if the contract uses SELFDESTRUCT it does not preclude the possibility of redeploying another contract at the same address. This has been successfully exploited in the infamous Tornado Cash attack by using a metamorphic contract factory.
• There is a negative sentiment against SELFDESTRUCT opcode and (although stagnant) EIP-4758 that highlights some security concerns.
• Token burns via this method aren't recognised on most analytics platforms.

Given the listed concerns, I advise against this approach and encourage the use of burn addresses.

Use well-known burn addresses

A burn address is a recognized externally owned account (EOA) where tokens can be sent to symbolize their destruction. While the token count remains unchanged, these tokens are effectively removed from circulation since no private key can control the burn address.

One of the common questions is "what if somebody knows or brute forces the private keys for such EOA addresses?"

Ethereum security model rests on the practical impossibility of brute forcing EOA accounts, so it does not make sense to take the risk of such attack into account when planning the burns. And to mitigate the risk of malicious burn addresses, use only the well-known ones.

You can find the list of burn addresses on Etherscan but I recommend limiting it to the top two that stand out by the TVL and number of transactions: 0x0000000000000000000000000000000000000000 (null) and 0x000000000000000000000000000000000000dEaD (dead).

Interestingly, OpenZeppelin's ERC20 implementation restricts transfers to null which could leave you with the second best choice: dead.

The benefit of using well-known burn addresses over "contract burns" is that burn addresses are accounted for and integrated into numerous analytics tools, ensuring accurate token burn data representation.

Bonus tips

• Ensure that your ERC20 contract is locked and immutable before initiating burns.
• For ERC20 tokens on multiple networks, execute burns on your primary network only, for unified tracking and analytics.
• For the first burn, refrain from using decentralised or ZK-bridges. If your contract unexpectedly rejects the transaction (like disallowing transfers to null) – it might muddle your analytics even though the tokens are technically burned.

Big thanks to Lance Henderson for technical insights and for reviewing this post!

Assuming that you know what Nix is and what problems it solves, I will skip the what and why parts – plenty of posts written on it already.

Nix is complex and once in a while people ask me if they should start using it for their personal environments and how much effort it would require.

The Nix learning curve varies from person to person and potential productivity gains depend on many factors. This post is my take on how you should approach this decision.

Just because you can...

Does it mean you should just migrate your workstation to NixOS / nix-darwin?

Not right away. If you are a programmer, try adopting devshell and flakes for a project you are working on. You won't need to learn the Nix language in the beginning to rip the benefits and progressively expand your knowledge. This low-barrier experiment would allow you to form an opinion and would be a good signal to invest more time into it or not.

If you have worked with any functional language before and if you have a reasonable knowledge of Linux the odds are high that Nix would be a very good fit for you. Regardless, my advice does not change – experiment with an isolated project first to learn and get familiar with Nix.

If you want to go an extra mile with this experiment, you can try packaging your software using Nix as well and even possibly integrating it into a CI/CD pipeline. If it was too easy, you can also try using dockerTools to build container images.

Avoid packaging TS/Javascript projects unless everything feels easy and straightforward already.

If you decide to continue

Then you can create a Nix repository for declarative configuration of your workstation(s).

If you are using macOS, you can start progressively replacing most of the Homebrew dependencies and OS settings with a combination of nix-darwin and project-local flakes.

If you are using Linux, you might consider switching to NixOS as well, but you'd need more time on the reinstall. NixOS these days has a graphical installer based on https://calamares.io which supports disk encryption out of the box. I personally use nix-anywhere + disko with LUKS to install things remotely though.

At this point you might discover that Nixpkgs provides by far the largest and the most up-to-date collection of packages in the world. Most likely you won't have problems matching your previous OS configuration. You might want to wait with re-packaging anything bespoke using Nix depending on how familiar you are with Nix language and packaging process already.

Dotfiles migration

Depending on the complexity & sophistication of your workstation config, at this point you might be using Home Manager and moving your existing app configs to your Nix repo. This could take a while and here are some tips on how to make it easier:

• Decide on the secrets management solution early on. I recommend sops-nix.
• Remove all your custom styling. You can progressively replace it with stylix.
• Don't try to migrate everything at once – could be a lot of work

I recommend taking a look at public dotfiles repositories on Github for inspiration.

Scaling

At some point you might notice that working with anything less than Nix brings pain and frustration. So you might consider using Nix for pretty much everything you can. I won't be the one to talk you out of it. Here are some tips:

• Use a monorepo for all configs. Structure it with flake-parts.
• nix-anywhere + disko to provisioning. deploy-rs for remote deployments
• Terranix + thoenix for nixifying Terraform configs
• Arion for nixifying docker-compose'd services

Be prepared that the last steps will require effort even if you are a pretty good generalist programmer and the whole process take up to a year to get comfortable with everything.

My story

I was skeptical about Nix for a long time before switching to it and I never looked back. It's been a few years since that and my overall experience has been fun and gratifying.

The Nix ecosystem is evolving extremely fast and there is still a lot of room for improvement all around. I've definitely struggled with a number of things but never actually encountered a problem I could not solve and now life became even easier with ChatGPT.

I'd like to thank Adam Höse (Adisbladis) for spending his time with me at one of the CCC events and convincing me to try Nix out.