Payy is a platform designed to facilitate self-sovereign banking through cryptocurrency, offering a simplified and secure approach to the financial services traditionally managed by banks. Payy facilitates the sending of stablecoins, earning yield, and simplifies the usse of decentralized finance (DeFi). Integrating zk-rollup tailored for applications requiring privacy and scalability in payments and DeFi.

The Payy ecosystem comprises three parts. First is the Payy Network, a zk-rollup app enhancing payment and DeFi privacy and scalability. Second, the Payy Wallet is a non-custodial mobile wallet featuring a novel UX and stablecoin. Lastly, Payy Intents is a non-custodial proxy for lending, market making, and (re)staking across any protocol and chain. 

Payy outperforms centralized exchanges because it is non-custodial, and users can access high DeFi yield protocols, staking, and lending. Payy goal is to reimagine wallets from the ground up to feel like a banking app. 

‍

AuditOnes audit focuses on the updated version of the Roullup contract.

Challenges Faced

‍

AuditOne's audit team identified a few issues in the RollupV6.sol smart contract that were all resolved, and the full report can be found here. 

‍

‍

Identified Vulnerability: Blacklist User Can Revert Block Verification Process

A major issue discovered by AuditOne smart contract auditing team was that USDC Blacklist User Can Revert Block Verification Process. Blacklisted USDC wallet addresses can disrupt the blocked verification process in the RollupV6.sol smart contract. It's a serious concern as it can block verification, affecting the rollup system. A rollup is a mechanism for scaling Ethereum by bundling multiple transactions together for efficiency. 

The blacklisted wallet address can get in the way of verifying blocks in the rollup system. This could lead to a Denial of Service (DoS) situation, blocking the entire system from proceeding forward. 

The function responsible for this is the executeBurnToRouter, responsible for burning USDC tokens, effectively destroying them. When interacting with an external route, the route call fails, and the tokens are transferred to a backup address returnAddress. The main problem here is if the returnAddress is blacklisted by the USDC token contract. Any tokens transferred to a blacklisted address would fail and cause the transaction to revert, essentially canceling the transaction. 

This function is executed by a prover to verify a block in a rollup. If the transfer fails due to a blacklisted address, the block verification process will fail entirely. This can limit any new transactions being added, shutting down the rollup system. Attackers could intentionally set a blacklisted returnAddres to exploit this and deliberately stop the system from working.  

Recommended Solution: Implement Blacklist Verification

The smart contract does not check if the returnAddress is blacklisted before typing to transfer USDC tokens to it. Without the check, the contracts would execute the transfer and fail if the address is blacklisted.

A possible solution would be to use a function requireNotUSDCBlacklisted to verify the status of the address before transferring and prevent failing unexpectidely. By addressing this problem, the rollup system can avoid being disrupted by blacklisted addresses, ensuring the stability and reliability of block verification processes.

‍
Security doesn’t just protect code; it protects your clients, reputation, and future. Whether you’re building a game, a DEX, or a DeFi app, AuditOne is here to ensure your smart contracts are rock-solid.

Let’s secure your Web3 project—so you can focus on creating the magic.