W Chain security record

The claim function checks that the length of the _v array is greater than two-thirds the signers present. With 4 signers it is expected that _v is ( * 4) which yields 2.667 but Solidity rounds down from 2.667 to 2 thereby reducing the effectiveness of the check for signers by 1 signer.

When claiming, the valid_count variable is incremented if the signer is true in the is_signer mapping. Users can exploit this by providing an array of v, r, and s that is populated with a single signer address vrs. Due to the absence of a check to validate that a signer signature has been checked before, the user can repeatedly use one signer address, populate the array to meet the signers ratio, and then claim their funds without appropriate checks. IfW Chain Bridge - Audit Report ww.quillaudits.com 08 w this happens, valid_count can be incremented any number of times till it exceeds the two- thirds of _signers security limit allowing the msg.sender to receive the amount.

The addSigner function contains a potential Denial of Service (DOS) vulnerability due to an unbounded array of signers. The function performs a linear search through the _signersarray to check for duplicates before adding a new signer. As the number of signers grows, the gas cost of this operation increases linearly, potentially making the function unusable if the array becomes too large.The issue is present in two locations:1. The addSigner function's duplicate check loop 2. The removeSigner function's search loop This could lead to: - Excessive gas consumption for signer management operations - Function calls potentially exceeding the block gas limit- Contract becoming unusable if too many signers are added

The claim function violates the Checks-Effects-Interactions (CEI) pattern by performing an external call (transfer) before updating the contract's state variables. This creates a potential reentrancy vulnerability where an attacker could re-enter the contract before state changes are applied.

Using an immutable chainId in the contract poses a risk during network hard forks. When a network undergoes a hard fork, it can result in two separate chains with different chainIds. If the contract's chainId is immutable (hardcoded), the contract will continue to operate with the original chainId.

The claim function uses the deprecated transfer() method to send ETH to users. Thetransfer() function forwards a fixed gas stipend of 2300 gas, which can cause the transaction to fail if the recipient is a smart contract with complex logic in its receive/fallback functions.

There are a couple of getter functions present in the contract which implies that the bridge relies on constantly querying data from the contract. However, blockchain bridges over time, relies on event emission and has a fast way to query data; it is cheaper and quicker to fetch on the client side. Emitting events for critical state changes is an appropriate way to track important transactions performed from the contract.

Access control is a critical part of smart contract security. Within this contract, access control is handled by the Ownable library which allows the owner to relinquish their rights to a new owner in one function call, transferOwnership(). This is risky if the new owner address passed in is malicious or is a victim of an address poisoning attack where some bytes of the address are changed when copied to the clipboard.

For adding and removing signers in WadzBridge, a for loop is used to add or remove addresses from the array - realistically, the array wouldn’t get large enough to be prohibitively expensive. In the current implementation, an array (_signers) and a mapping (is_signer) are used to determine the validity of addresses but the EnumerableSet provides a more efficient route to manipulate addresses in the same format.

There currently is no check in the bridge and claim function that the chainId passed is not the parent chain. With the contract storing the claim data attached to the various chains, a user could pass in the same chainId for the _from_chain and _to_chain causing accounting errors.