RentLock: Smart Contract Rental Escrow dApp

PII-Safe Publication Note

This page paraphrases the original project report for portfolio use. It omits personal names, academic identifiers, wallet screenshots, private account details, raw submission pages, and any metadata that is not necessary to understand the product and engineering design.

Executive Summary

RentLock explored how a smart-contract escrow workflow could reduce rental deposit disputes. Instead of one party holding the deposit off-chain, funds are locked in a transparent contract with predefined settlement paths. The prototype focused on lease lifecycle design, tokenized deposits, mutual agreement, dispute escalation, and a verifier mechanism for unresolved cases.

The project is strongest as a systems-design artifact. It shows how product incentives, contract state, frontend UX, and abuse prevention need to be designed together. A smart contract alone is not enough; the surrounding workflow determines whether users can safely understand and act on the contract's rules.

Portfolio Signal Snapshot

This project is framed as a full-stack Web3 product design case study: smart-contract state design, frontend-contract integration, evidence handling, and incentive-aware dispute resolution.

Problem Context

Rental deposits create an imbalance when one party controls the funds while the other party has limited visibility into settlement rules. Common pain points include unclear deductions, slow refund timelines, poor evidence handling, and a lack of neutral escalation.

Product Objectives

• Hold rental deposits in a transparent escrow contract instead of relying on unilateral custody.
• Represent the lease lifecycle with explicit states such as creation, funding, active lease, settlement, dispute, and closure.
• Support mutual release when both parties agree on the refund or deduction outcome.
• Provide escalation when the parties cannot agree within the expected settlement window.
• Keep evidence and sensitive user data out of public portfolio materials.

Sanitized Escrow Sequence

The source report described a simple lease sequence involving the tenant, landlord, frontend, and escrow contract. The recreated portfolio diagram keeps the workflow but omits private wallet screenshots, account identifiers, and raw demo artifacts.

Curated Figure Gallery

These selected visuals are more intuitive than a text-only writeup because they show the smart-contract workflow and product surface. The architecture is shown as a light-background recreation, and the AI-evaluation screenshot is cropped to remove the wallet/account header before publishing it.

System Design

1. Tokenized Deposit

The prototype uses a test token to simulate stable-value deposit handling. This allows contract logic to be tested without relying on real funds or exposing private wallet activity in the public writeup.

2. Escrow Manager Contract

The escrow contract manages lease creation, deposit funding, state transitions, refund requests, deductions, settlement, and dispute escalation. The contract state gives both parties a shared view of what actions are currently valid.

3. Role-Based Workflow

The product separates tenant, landlord, and verifier actions. Each role has a different interface and different permissions, which reduces accidental misuse and makes the workflow easier to explain.

4. Evidence Boundary

Evidence such as images or supporting documents should not be stored directly on-chain. A safer pattern is to store evidence off-chain and anchor hashes or references, with encryption and retention policies as future work.

5. Verifier Escalation

If the parties cannot settle, a verifier flow can review the dispute and trigger the appropriate outcome. This mechanism requires careful incentive design so reviewers are compensated without encouraging low-quality participation.

Implementation Lessons

• Single ABI source: Frontend-contract mismatches can break the application even when the smart contract itself compiles. Treat contract interfaces as shared artifacts.
• Events matter: Contract events help the frontend update state without relying only on manual refreshes.
• State design is UX design: Users need to understand which actions are valid in the current lease state and what happens next.
• Escrow needs policy: The contract can enforce rules, but the product still needs evidence standards, dispute timelines, and verifier accountability.

Technical Notes From Source Report

Decision Framework

The design challenge was to decide what belongs on-chain, what should stay off-chain, and where human or verifier judgment is required. The strongest version of the product uses blockchain for settlement integrity, not as a dumping ground for private evidence.

Risk and Abuse Considerations

Limitations

• The prototype should be treated as an academic dApp concept, not a legally ready rental platform.
• Real deployment would require legal review, identity checks, jurisdiction-specific tenancy rules, secure evidence storage, and audited smart contracts.
• The public report intentionally excludes wallet screenshots and private account details.
• Verifier incentives need deeper modelling before they can be considered reliable at scale.

Recommended Next Improvements

• Add a formal state-machine diagram to document every allowed transition and failure state.
• Introduce encrypted off-chain evidence storage with hash anchoring and deletion policies.
• Add automated contract tests for edge cases such as duplicate actions, missed deadlines, partial refunds, and dispute cancellation.
• Prototype a reviewer dashboard that shows evidence packets, deadlines, and final decision status.

Source Trail

The RentLock source report did not include a formal academic bibliography. For the portfolio, the safest presentation is therefore to include technical notes derived from the report and avoid inventing a research-paper citation list that was not actually in the submitted material.

Recruiter Signal

RentLock demonstrates smart-contract product thinking rather than narrow token experimentation. The project covers workflow modelling, escrow states, incentive design, frontend integration, and practical privacy boundaries for public communication.