Inspiration
A single disputed deduction can delay the return of an entire rental deposit. This creates an unnecessary all-or-nothing outcome: even when most of the money is undisputed, both parties may have to wait until the entire dispute is resolved.
I created BondLens around a simpler payment principle: one disputed item should not freeze the entire deposit.
What it does
BondLens is a tenant-controlled partial-settlement system for rental deposits. It separates the deposit into three transparent outcomes:
- the undisputed amount returned to the tenant;
- the amount explicitly accepted by the tenant and paid to the landlord; and
- only the unresolved balance that remains protected for later resolution.
The landlord can prepare a deduction request, attach evidence, record the documented cost, and submit the claim. The tenant reviews the same case file and independently chooses how much, if any, to accept.
Before settlement, BondLens previews every resulting amount. After explicit tenant confirmation, the contract executes the partial settlement and produces a shared verification record.
Neither the landlord nor the evidence helper can choose the accepted amount. The system always preserves the accounting rule:
Returned + Paid + Protected = Original Deposit
How I built it
I built two independent Next.js applications: a landlord workspace and a tenant workspace. Both communicate through a separate backend API.
The backend validates case inputs and uploaded image content, stores evidence and personal information off-chain, computes SHA-256 content hashes and evidence commitments, and performs role-specific smart-contract calls.
I developed a Solidity escrow contract to manage the financial state. It enforces tenant, landlord, and reviewer roles; limits the accepted amount to the submitted claim; prevents duplicate settlement; preserves the remaining protected balance; and supports later mutual or reviewer-assisted resolution.
The blockchain stores only the information required for verification: roles, lifecycle states, integer settlement amounts, and evidence commitments. Images, documents, names, and property details remain off-chain.
I used Playwright to test the complete workflow across both applications, including claim creation, evidence upload, tenant review, custom settlement amounts, confirmation, and synchronized receipts.
Responsible evidence intelligence
The current evidence adapter performs deterministic storage, format, integrity, and hashing checks. It does not claim to recognise physical damage or determine responsibility.
I designed the provider boundary to be replaceable, allowing a production vision API to be added later without giving the model financial authority.
Even after that integration, computer vision will assist evidence review. It will not determine legal liability, choose a settlement amount, or autonomously transfer funds.
Challenges I ran into
The largest challenge was keeping evidence assistance separate from financial authority. I created different landlord and tenant permission surfaces, required explicit human confirmation before every contract write, and prevented the evidence provider from accessing settlement or transfer methods.
Another challenge was representing partial settlement without losing accounting clarity. I therefore made the user interface and smart contract expose the same three-bucket conservation rule at every stage.
I also had to keep two separate applications synchronized through a shared backend and blockchain state while ensuring that each party could access only the actions appropriate to its role.
Accomplishments that I am proud of
- Separate landlord, tenant, and backend applications
- Dynamic deduction creation and role-specific visibility
- Evidence upload validation, persistence, hashing, and commitments
- Tenant-controlled custom settlement amounts
- Explicit confirmation before every financial action
- Solidity role, state, amount, and duplicate-execution protections
- Synchronized tenant and landlord settlement receipts
- Unit, contract, build, and cross-frontend browser tests
- A replaceable evidence-provider boundary with no payment authority
What I learned
I learned that blockchain is most useful here as a narrow verification and execution layer, not as a place to store private evidence.
I also learned that responsible AI integration depends on authority boundaries. An evidence model can organize or describe information while the human decision and financial authorization remain explicit.
Finally, I found that the conservation rule is not only a contract invariant but also an important user-experience tool. Showing where every cent goes makes partial settlement easier to understand and verify.
What's next
My next step is to turn the workflows into mobile-first applications, connect a production vision API for structured damage and invoice extraction, and deploy the escrow contract to a public EVM test network.
I also plan to add wallet-backed identities, encrypted object storage, evidence provenance records, reviewer-assisted resolution, monitoring, privacy controls, and independent smart-contract security review.
BondLens is not designed to let AI decide a dispute. It is designed to make every input inspectable, every approval explicit, and every cent accountable.
Built With
- blockchain
- contracts
- css
- evm
- hardhat
- next.js
- node.js
- playwright
- react
- smart
- solidity
- tailwind
- typescript
- viem
- vitest
- web3
Log in or sign up for Devpost to join the conversation.