Loan State Ledger

Inspiration

I've been developing PropTech and FinTech solutions for many years. No one has solved the problem of automating and presenting the status and timeline of these types of loans. From my own experience in working on supporting title, escrow, and property developers, this is a significant problem that compounds across the different stakeholders' workflows and processes that has not been adequately addressed. My work on Pakana.NET and the lockb0x protocol dovetails into this solution perfectly. I would love to build it.

What it does

Loan State Ledger (LSL) is a desktop-first web prototype that demonstrates a new way to manage and reason about the current effective state of syndicated and agented loans.

Rather than relying on email threads, spreadsheets, and fragmented internal systems, LSL models loans as deterministic state machines. Each amendment, waiver, or notice is represented as an explicit event with required acknowledgements, effective timestamps, and a clearly derived state.

The result is a single, authoritative view that answers—at any moment:

What is the current effective state of this loan, and why?

If ambiguity exists, LSL makes it visible, attributable, and explainable.

How we built it

LSL is implemented as a frontend-only concept prototype focused on clarity of state logic rather than infrastructure complexity.

Architecture highlights:

• Loans are represented as an append-only event ledger
• Event state is derived using pure, deterministic functions
• The UI consistently reflects derived state rather than stored status

Tech stack:

• Framework: Next.js (App Router)
• Language: TypeScript
• Styling: Tailwind CSS
• Data: Static JSON / in-memory mock data
• Backend: None (intentionally omitted to emphasize logic and UX)

Core state resolution logic lives in a shared module and is reused across all views to ensure consistency and explainability.

Challenges we ran into

• Translating legal and operational loan concepts into explicit state transitions
• Avoiding implicit assumptions common in existing loan workflows
• Designing a UI that surfaces ambiguity without overwhelming the user
• Balancing realism with the constraints of a hackathon-scale prototype

The hardest problem was not technical—it was deciding what not to abstract away.

Accomplishments that we're proud of

• A clear, explainable ASSERTED → PENDING → EFFECTIVE state model
• A shared timeline that multiple parties can reason about consistently
• Making unresolved acknowledgements and missing conditions immediately visible
• Demonstrating a coordination layer that works above existing systems
• Delivering a cohesive, reviewable prototype without backend complexity

What we learned

• Syndicated loans behave like distributed systems
• Most operational risk comes from state ambiguity, not bad intent
• Deterministic state logic dramatically improves trust and comprehension
• Making ambiguity explicit is more valuable than trying to hide it
• You don’t need blockchain or system replacement to improve coordination

What's next for Loan State Ledger

Future iterations could explore:

• Real-time acknowledgements and permissions
• Integration with agent platforms and document management systems
• Event ingestion from email, filings, and notices
• Role-specific views for agents, lenders, borrowers, and counsel
• Formal audit and compliance reporting
• Implementation of Microsoft Ledger Database for an enterprise-grade production platform

The long-term vision is a lightweight state coordination layer that complements—not replaces—existing legal and operational infrastructure.

Built With

• antigravity
• chatgpt
• copilot
• gemin3
• google
• next.js
• postgresql
• react
• react-19-language:-typescript-styling:-tailwind-css-v4
• typescript