Kaira

Spend with freedom. Stay prepared. Reveal only what matters.

Comment

Inspiration

Kaira started about a week before this hackathon, when I participated in another hackathon and decided to build something in fintech for the first time.

I had never built a fintech product before, so instead of starting from a list of features, I started with a few questions:

What would I want from a finance app? Would I actually use it? Would it help me make better decisions, or would it just become another dashboard I stop opening after a week?

While looking for inspiration, I realized something very simple: I personally do not enjoy most banking or fintech interfaces. (Not because I hate them, but because some of them aren't intuitive and can be confusing to use.)

Some applications help cancel subscriptions. Others show spending history, charts, investments, transfers, or categories. Those things can be useful, but I kept thinking that I wanted something different. I wanted an app that helped me become more conscious of my money without controlling me.

I still want to buy things I like. Sometimes you see a figure, a collectible, Pokémon cards, a limited item, or something on sale, and you know there is a very real chance you will come back later and it will be gone.

The problem is not necessarily spending. The problem is spending without understanding what that purchase means for everything that comes next.

That idea became much more personal when I thought about my time studying abroad. Marketing and consumerism were very powerful enemies of my debit card xD. There were moments when I bought an anime figure or Pokémon cards and later realized that maybe I should have protected a little more money for groceries (ngl, there have been times when I was starving just because I decided to be happy buying unnecessary stuff).

That is where Kaira started making sense to me.

I wanted something that could tell me:

You can buy this and still cover what matters. or: You technically have the money right now, but this purchase could collide with rent, subscriptions, groceries, or other commitments coming soon.

And if I cannot safely afford something yet, I do not want the app to simply say “no.” I want it to help me turn that desire into a goal.

Subscriptions were another part of the inspiration. During my exchange, I would try services or free trials, use them for a while, forget about them, and eventually wonder why my balance was slowly disappearing. ._.

Kaira grew from all of those small experiences. It is not meant to be a financial police officer.

I imagine it more like a loyal financial companion: something that helps you stay conscious, prepared, and free to make your own decisions without accidentally spending the money you still need to live.

I have many more ideas for what Kaira could become, but this hackathon also taught me something important: sometimes the best thing you can do is stop trying to build the final version of your idea and focus on the part that creates the most value now.

What it does

Kaira is a personal finance prototype focused on helping users understand how much of their balance is actually safe to spend, not only how much money is currently visible in their account. $$ \text{Current balance} \neq \text{Money that is actually safe to spend} $$

At the center of the application is this distinction: Kaira considers upcoming commitments, recurring payments, savings goals, and a financial safety buffer before calculating a user's Safe-to-Spend amount.

The product currently revolves around four main experiences.

Financial awareness

Kaira shows the user's current balance, activity, upcoming commitments, recurring expenses, and estimated Safe-to-Spend amount. Instead of only showing what happened in the past, it tries to give the user a clearer picture of what their money may need to cover next.

Purchase simulation and Kaira Guard

Imagine I am walking outside and suddenly find a Pokémon figure I really want. It is discounted. There is only one left. My impulsive brain has already decided that this is an emergency :0

Before buying it, I can simulate the purchase in Kaira. Kaira checks the impact of that purchase against my upcoming commitments, savings, safety buffer, and available balance.

The result can be Safe, Warning, or High Risk.

A safe purchase means Kaira expects the account to remain financially healthy after covering upcoming commitments.

A high-risk purchase means the purchase could collide with money needed soon.

Kaira does not stop the user from spending. It provides context so the user can make the decision consciously. If the purchase is too risky, the user can also convert it into a savings goal instead of abandoning it completely.

Recurring payments and subscriptions

Kaira detects upcoming recurring payments and allows them to be managed with different behaviors such as:

  • Auto-pay
  • Ask me first
  • Watch closely
  • Cancel

This is designed for exactly the kind of situation where I subscribe to a service, forget it exists, and later discover that it has been quietly eating my balance for months. T^T

Savings goals

Users can create goals, allocate money to them, move money between goals, withdraw money back to the available balance, and redirect high-risk purchases into goals. The idea is that saving should not feel completely separated from everyday spending decisions.

Midnight privacy and security

For this hackathon, Kaira was upgraded with Midnight. The first integration is Kaira Private Guard.

Instead of exposing the complete financial state used to evaluate a purchase, Kaira sends private financial values into a Compact circuit.

The circuit evaluates whether: $$ \texttt{currentBalance} \ge \texttt{upcomingCommitments} + \texttt{reservedSavings} + \texttt{safetyBuffer} + \texttt{purchaseAmount} $$

and only discloses the verification result.

Kaira still needs the financial values on its own trusted server to perform the application logic, but those raw values are not published as Midnight public state.

We also added Private Financial Identity. A user can prove that a financial profile satisfies a policy for one of three situations:

  • Own income
  • Financially dependent adult
  • Minor with guardian

The proof can evaluate private information such as age and income while the application stores only proof metadata such as the Midnight transaction, block height, profile type, and verification result. The exact age and income are intentionally not persisted in the identity profile.

The principle became:

Kaira stores the proof result, not the financial secret.

For the Integrate Midnight Track Resources track, this creates another interesting direction: instead of giving an AI workflow every piece of raw financial information, Kaira can provide a verified result that the workflow can act on.

The long-term idea is simple: use AI where it helps, but reveal as little sensitive financial information as possible.

How we built it

Kaira already existed before the Midnight Hackathon, so our goal was not to rebuild the application from scratch.

We deliberately avoided spending most of the hackathon polishing the UI. Some visual improvements were made, the product flow changed, and Kaira even got a new koi mascot, but the main focus was the architecture, financial logic, security boundaries, and Midnight integration.

The application is built with Next.js, React, TypeScript, Tailwind CSS, Supabase, n8n, and ElevenLabs.

Kaira already contained custom financial engines for recurring-payment detection, forecasting, Safe-to-Spend calculations, purchase-risk evaluation, and savings logic.

During the hackathon, one important change was moving the purchase assessment toward a more server-authoritative architecture.

The browser no longer decides important values such as the risk classification or upcoming financial commitments.

Instead:

Browser
   |
   | purchase name + amount
   v
Next.js API
   |
   | loads account data
   | detects recurring payments
   | forecasts commitments
   | calculates savings and Safe-to-Spend
   v
Kaira financial engine
   |
   v
Midnight bridge
   |
   v
Compact contract
   |
   v
ZK verification

For Midnight, we ran a local development environment using Docker with the Midnight node, indexer, and proof server.

This was my first time working with Docker, so getting that stack running was an adventure by itself. We created and compiled a Compact contract for Kaira Private Guard and later expanded the same contract with three Private Financial Identity circuits.

A server-side Midnight bridge connects the Next.js application to the deployed contract and exposes the verification operations required by Kaira.

For high-risk purchases, Kaira stores Guard events with Midnight transaction metadata in Supabase.

For Private Financial Identity, Kaira takes the opposite approach: it persists only the proof metadata and intentionally does not store the raw age or income used during verification.

We also added transactional end-to-end testing that confirms contract connection, public state reads, proof generation, transaction submission, and contract state transitions.

Challenges we ran into

The first challenge was very simple: I did not know how to use Docker. I am also still a beginner with Linux, so suddenly dealing with containers, Midnight services, ports, wallets, proof servers, local network state, and terminal commands was a very different environment from what I normally work with.

There were several technical problems along the way, including dependency/runtime compatibility issues, wallet and local network behavior, generated cache problems in Next.js, and even a WSL clock/time synchronization issue that caused authentication-related errors.

At one point Next.js generated broken development route types inside .next, which looked terrifying until we realized the generated cache was the problem and regenerated the types.

Another challenge was not technical at all.

It was knowing when to stop.

While learning more about Midnight, I also kept realizing how many things I still want Kaira to become. That became an internal fight because I wanted to make the final product immediately instead of accepting that I was building a hackathon version.

That is one of my biggest weaknesses in hackathons: one idea becomes five ideas, then fifteen, and suddenly none of them fit into the time available.

A Midnight hackathon stream about prioritization helped me rethink that.

The phrase that stayed with me was:

Ship value, not excuses.

That pushed me to stop chasing the imaginary perfect version of Kaira and prioritize the flows that mattered for the demo.

Another funny challenge was branding.

The original version of Kaira had a squirrel mascot. While researching other finance apps, I discovered an existing application already using a squirrel as a recognizable mascot.

At first that discouraged me.

Then I realized something useful: many people can arrive at similar ideas. What makes a project yours is how you build it, the decisions you make, and the personality you put into it.

So the squirrel retired and Kaira became a koi.

And yes, there were also moments where I really wanted to give up. I did not.

Another challenge was my pronunciation. While recording the demo, I realized I still need more practice expressing technical ideas clearly in English.

Accomplishments that we're proud of

One of the things I am most proud of is that this hackathon helped me understand what I actually want Kaira to become.

At the beginning, I was not even completely sure whether Midnight made sense for the project.

As I integrated it, the opposite happened.

Thinking about privacy forced me to examine the application more carefully: what should the browser control? What should the server calculate? What information really needs to be stored? What can be verified without revealing everything?

That process gave me a much clearer vision of Kaira.

I am also proud that Midnight is not only decorative in the project.

We implemented real private verification flows, deployed the Compact contract, generated real zero-knowledge proofs, submitted Midnight transactions, persisted proof metadata, and validated the state transition through an end-to-end test.

The purchase flow also became stronger during the process.

Safe simulations produce a real Midnight verification without polluting the Guard event table.

High-risk simulations produce a negative verification, trigger the protection workflow, and persist the Midnight transaction and block metadata.

Private Financial Identity also supports successful and unsuccessful proofs, including own-income, dependent-adult, and minor-with-guardian profiles.

And personally, one accomplishment matters just as much: I finished it.

There were moments where I wanted to stop, change direction, rebuild everything, or add another fifteen features.

This time I kept going and completed the version I committed to building :)

What we learned

I learned a lot technically, but one of the biggest lessons was not technical at all:

Rest is part of building.

I also became much more comfortable with Linux and learned how to work with Docker for the first time, which is something I know will be useful far beyond this hackathon.

I learned more about Midnight, Compact, local blockchain infrastructure, proof servers, wallets, zero-knowledge verification, and the difference between making information private and proving that information came from a trusted real-world source.

That distinction became especially important for Private Financial Identity.

A zero-knowledge proof can prove:

$$ \texttt{income} \ge \texttt{required threshold} $$

without revealing the income.

But that does not automatically prove that a bank or government institution certified that income.

Understanding that boundary changed how I think about security claims.

The workshops also changed how I think about hackathons. I tend to imagine the final version of a product while I am still building version one.

This hackathon reminded me that a smaller feature that works, can be demonstrated, and creates clear value is often more important than ten ambitious features that never become real.

And I also learned that I still have a lot to learn.

Oddly enough, that makes me more excited about the project instead of less.

What's next for Kaira

There is a lot I would still like to build.

The first thing I would probably revisit is Kaira's complete UX and visual identity.

The current interface works, but I want the final experience to feel less like “a fintech dashboard” and more like Kaira, a financial companion with its own personality.

I want opening the app to feel like checking in with a trusted friend who understands your financial situation, gives you context, protects what matters, but never takes away your freedom to choose.

Long-term, I would like Kaira to become an accessible personal finance application that can be useful to many different kinds of people.

I would love for it to remain affordable or free whenever possible, become more accessible, support stronger privacy and security, and eventually integrate legitimately with banks, financial institutions, and appropriate government or compliance systems.

Those integrations would not exist so Kaira could collect more information.

Ideally, they would allow Kaira to verify trustworthy financial facts while collecting less information.

That is one of the reasons Midnight became so interesting to me.

Future versions could include real banking synchronization, better authentication, stronger credential verification, encrypted financial storage, additional zero-knowledge proofs, smarter recurring-payment detection, deeper subscription controls, improved savings automation, longer-term forecasting, better accessibility, localization, and many of the features that are still living rent-free in my head.

Maybe Kaira stays a hackathon prototype.

Maybe I keep building it.

Maybe one day it becomes a real application.

Who knows? :3

Stay tuned. The koi is still swimming.

Extra

Version tags:

  • v0.1-before-midnight — original Kaira prototype before the Midnight integration.
  • v0.2-midnight — Kaira upgraded with Midnight Private Guard and Private Financial Identity.

Built With

Share this project:

Updates

Submission history