
Attackathon | VeChain Hayabusa Upgrade
The VeChain Hayabusa upgrade is the second phase of the VeChain Renaissance. The Hayabusa upgrade will upgrade VeChainThor’s consensus mechanism, tokenomics and degree of decentralization. Key Highlights:
- Upgrade to Delegated Proof of Stake (DPoS): VeChainThor will migrate from PoA to DPoS, a more decentralized consensus mechanism, while maintaining strong security and performance.
- Enhanced VTHO Tokenomics: A dynamic VTHO generation rate will be distributed as a block reward to validators and delegators that contribute to securing the VeChainThor network.
Live
Triaged by Immunefi
Step-by-step PoC Required
KYC required
Build Commands, Test Commands, and How to Run Them
https://github.com/vechain/thor-hayabusa provides some information in operating a public or validator node in the Hayabusa network and provides access to additional tools, faucet for funds, an explorer and inspector a tool that allows for easy interaction with deployed smart contracts.
Where might Security Researchers confuse out-of-scope code to be in-scope?
The scope is limited to a particular release branch of code so the scope is very clear, see scope above.
Is this an upgrade of an existing system? If so, which? And what are the main differences?
Yes, upgrading the consensus mechanism of VeChainThor from Proof of Authority (PoA) to Delegated Proof of Stake (DPoS). See the provided VIPs for details of the changes.
Where do you suspect there may be bugs and/or what attack vectors are you most concerned about?
The change in the consensus mechanism and the distribution of rewards
What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported?
All of the above listed standards are implemented on chain but do not form part of the upgrade.
What emergency actions may you want to use as a reason to downgrade an otherwise valid bug report?
The fact that two traditional audits are taking place in parallel with this Attackathon.
What addresses would you consider any bug report requiring their involvement to be out of scope, as long as they operate within the privileges attributed to them?
There is the executor address and stargate address which have privileged roles in the network and their actions so long as they operate within the privileges attributed to them are expected.
What addresses would you consider any bug report requiring their involvement be out of scope, even if they exceed the privileges attributed to them?
Both the executor and stargate address are essentially out of scope as they are known addresses and operated by trusted third parties.
Which chains and/or networks is and will the code in scope be deployed to?
VeChainThor
What external dependencies are there?
There are no new dependencies. All of the old dependencies are out of scope.
What are the most valuable educational resources already available? (Ie. Documentation, Explainer videos or articles, etc)
For more information about the VeChain Hayabusa upgrade refer to, please visit the following resources:
- https://docs.vechain.org/
- VeChainThor Hayabusa Upgrade Release Branch
- VeChain Hayabusa E2E Tests Repo
- VeChain Hayabusa Upgrade VIPs