The problem ChainBreaker solves

Debt is an integral part of human endeavors, but the lending and borrowing of money present numerous challenges. It's often difficult to keep track of dynamic transactions, storage is centralized, lacks transparency at every moment, isn't tamper-proof, and borrowers and lenders struggle to synchronize their records.

Our web-mobile application serves two key entities: "Clients" and "Circuit Builders." It provides a solution by allowing "Clients" to securely record and monitor their lending and borrowing transactions in a decentralized, tamper-proof, and transparent manner. All you need to do is select your peer, enter the amount, and initiate a transaction. Your peer will receive a notification, and once confirmed, the debt status updates on the blockchain, visible in the user interface. Subsequent transactions follow the same process. It's important to note that the application solely records transactions; it doesn't facilitate actual token transfers, enabling the migration of real-life records to the blockchain seamlessly.

As more users record their debts, intricate debt circuits begin to emerge. For instance, A owes $100 to B, B owes $100 to C, and C owes $100 to A. If A, B, and C all agree, none of them owes anything to each other. While it's relatively simple to identify such circuits with just three clients, envision a vast network of millions interconnected by lending and borrowing relations of varying amounts. This is where the "Circuit Builders" come into play. These entities are motivated to locate the most efficient and swiftly resolvable circuits among clients, breaking the chain of debt. Clients incentivize them with tips to prioritize their inclusion in the next circuit. Moreover, once a chain is broken, "Circuit Builders" can mint NFTs as rewards for their efforts.

Our application has the potential to significantly reduce debts, is community-driven, promotes decentralized finance, and generates revenue.

Challenges we ran into

The user interface for managing borrowing-lending relations and conducting withdrawal and deposit transactions within the smart contract proved to be quite unintuitive. Borrowing, for example, could be described as sending a negative amount (e.g., -X) or receiving a positive amount (X), and the specific user order added complexity, especially when dealing with it during sleepless nights. Additionally, the frontend team encountered a learning curve while working with Ether.js and MetaMask for the first time, which required some adaptation.

We incorporated a significant amount of business logic into the contract, not only for constructing the contract itself but also for facilitating the circuit builder's operations.

For smart contract development, we opted for conventional tools like Hardhat and Remix. We successfully deployed the contract on both the Polygon zkEvm testnet and the Linea testnet. While I did encounter some challenges in obtaining test tokens, I eventually secured them from faucets with some effort.

A substantial portion of my time was dedicated to designing efficient data structures that seamlessly integrated with the frontend. This was crucial as our application follows a pure web3 architecture, eliminating the need for a backend or database. Given the complex interconnections between various entities within our app, choosing the right data structures was paramount.

To implement our business logic, I had to employ classical algorithms within Solidity. This included tasks such as sorting and detecting duplicate elements, all of which played a critical role in the functionality of our smart contracts.