DEV Community: Ihor Olkhovatyi

Your budgeting app is lying to you about last month

Ihor Olkhovatyi — Wed, 22 Jul 2026 23:48:26 +0000

I build a multi-currency personal-finance app. This is one of the
first bugs I had to design my way out of — and it's one almost every
multi-currency app I've tried still has.

The symptom

You spent 200 zł on groceries in March. Your base currency is euros.
In March the app showed that as, say, €46. You open the app in July and
that same March transaction now reads €43 — even though nothing about
March changed. Multiply that across every foreign transaction and your
"total spent in March" quietly drifts every single day.

That's not a rounding quirk. It means your financial history is being
rewritten with today's exchange rate, and you can't trust any
number older than right now.

Why it happens

The naive multi-currency data model looks reasonable:

transaction {
  amount:   200
  currency: "PLN"
  date:     "2026-03-14"
}

Then, to show a total in the user's base currency, you convert on read:

const eur = amount * liveRate(currency, "EUR");

liveRate returns today's rate. So the March transaction is re-priced
with the July rate every time it's rendered. Balances update live —
which is correct for what you hold right now — but the same logic
leaks onto historical transactions, where it's just wrong. A cost
you actually incurred at March's rate should read at March's rate
forever.

The principle

Convert live for balances. Snapshot for history.

A transaction is an event that happened at a moment in time. The
exchange rate that applied is a fact about that moment, not a live
value. So capture it once, at ingest, and never recompute it:

transaction {
  amount:        200
  currency:      "PLN"
  date:          "2026-03-14"
  rate_to_base:  0.2312     // EUR per PLN on the value date, frozen
  amount_base:   46.24      // optional: precomputed, for fast sums
}

Now historical totals are a plain SUM(amount_base) — deterministic,
and March stays €46.24 in July, next year, forever. Only current
account balances get the live rate, because those really are
"what is this worth right now."

The details that bite

Which date's rate? Use the transaction's value date (when the
money actually moved), not the booking/import date. Banks can book days
later; pricing at import time reintroduces drift.

Rates aren't published every day. The ECB (I use their Frankfurter
feed) publishes on TARGET business days — no weekends, no holidays. A
Saturday transaction has no same-day rate. Carry forward the last
published rate rather than skipping or interpolating; that's what the
banks do too.

Some currencies aren't in the feed. The ECB doesn't publish UAH,
for example. You need a secondary source for the long tail, normalized
into the same base so your snapshot is consistent regardless of which
feed a given currency came from.

Store the rate, not just the converted amount. If you only store
amount_base, you can never let the user change their base currency
without lying again. Keep the original amount + currency + date,
and the snapshotted rate. To switch base currency you re-derive from
the original at each transaction's historical rate — which means you
also need historical rates on hand, not just today's. (Storing the
rate against a single pivot currency like EUR and deriving cross-rates
keeps this cheap.)

Idempotency. Banks re-send transactions. Snapshot the rate keyed to
the transaction's identity + value date so a re-sync never re-prices an
existing row.

The takeaway

If you're building anything that sums money across currencies over
time — budgeting, accounting, portfolio, expenses — decide explicitly,
per number, whether it's a live value or a historical one.
Balances are live. Everything that already happened is history, and
history needs its rate frozen at the moment it occurred. Get this wrong
and every chart you draw is quietly fiction.

I'm building EveryPenny, a calm
multi-currency money tracker for people whose money lives across more
than one country — it connects EEA banks and Monobank in Ukraine and
shows one honest total. It's what pushed me to get this right. Happy to
go deeper on the rate-sourcing side in the comments.

My app's anti-theft feature locked every user out

Ihor Olkhovatyi — Wed, 22 Jul 2026 23:48:16 +0000

A real incident from the finance app I build solo. The security design
was textbook. That's exactly why it bit me.

The textbook setup

Short-lived access token, long-lived rotating refresh token. Every
time the client refreshes:

It presents its refresh token.
The server verifies it, revokes it, and issues a brand-new access + refresh pair.
The old refresh token is now dead — single use.

And the part everyone recommends (OWASP calls it refresh-token reuse
detection): if a client ever presents a refresh token that's already
been revoked, treat it as theft. An attacker who stole a token and
replayed it would trip this. The safe response is scorched earth —
revoke every session for that user so both the attacker and the
victim get kicked and must sign in fresh.

This is correct. It catches a real attack. Ship it.

The incident

One evening my own app showed me a auth error over a €0.00 balance and
an "add your first account" screen — as if I'd never signed in. The
data was all there on the backend. Only the login was dead.

The audit log told the story. All day: healthy refreshes every ~15
minutes. Then, one refresh, the server saw an already-revoked token,
declared theft, and revoked all sessions. The "attacker"?

Every session in the chain carried the same device id. It was my
phone. My phone was the thief.

How a device robs itself

A same-device replay of its own just-rotated token has completely
benign causes, and they're all common:

Lost response. The server rotated the token and committed, but the HTTP response never made it back (dropped connection, backgrounded app, dead tunnel). The client still holds the old token and retries it. To the server: a revoked token, replayed.
A failed local write. The new token pair came back, but writing it to the keychain failed (or raced with app suspension). Next launch, the client presents the previous token.
Two processes racing. My app and its widget extension both hit a 401 and both refresh with the same token. One wins and rotates it; the other arrives a beat later with what is now a revoked token.

None of these are theft. But "revoked token replayed" looked identical
to theft, so the nuke fired and I logged myself out everywhere.

The insight

Here's the thing I missed: for a same-device replay, the revoke-all
adds almost no security.

Reuse-detection defends against an attacker who exfiltrated a refresh
token and replays it from somewhere else. That "somewhere else" is
the signal. An attacker replaying from the same device, with the same
bound device id, already had full access to the device's storage — the
nuke doesn't save you there; they could just present the live token.

So the theft signal isn't "a revoked token was replayed." It's "a
revoked token was replayed from a different device than the one the
session is bound to."

The fix

Bind sessions to a device id, then scope the scorched-earth response to
the cases that are actually suspicious:

if (session.revokedAt) {
  const sameDeviceBenignReplay =
    session.deviceId !== UNBOUND &&
    session.deviceId === presentedDeviceId &&
    session.revokedReason === "rotated";

  if (!sameDeviceBenignReplay) {
    await revokeAllSessions(session.userId, "theft_detected");
  }
  throw new RefreshError("token_replayed"); // 401 either way
}

Same device, replaying its own rotated token → plain 401. The client just re-authenticates its refresh normally or picks up the winner's new token. No nuke.
Different device, or a non-rotation revocation (sign-out), or an unbound session we can't attribute → keep the full revoke-all. Real theft signals still get scorched earth.

Three supporting fixes made it robust:

A cross-process refresh coordinator. The app and widget now go through a single-flight mutex (a file lock in a shared container + a notification), so only one refresh is ever in flight per device. The loser waits for the winner's token instead of racing it.
Harden the token write. Check the keychain write status, retry once, and log loudly on failure — a silently failed write was one of the replay causes.
Never turn a transient failure into a logout. A dropped network or a 5xx on the refresh endpoint must be retryable, not "your session is dead." Only a genuine 401/403 from the auth server means sign out.

Takeaways

Rotating refresh tokens + reuse detection is still the right design. Keep it.
But "reused token" is not the same as "stolen token." The stolen signal is reuse from an unexpected device. Bind sessions to a device and let that distinction gate your most destructive response.
Make client refresh single-flight across every process that shares the credentials, or your own app becomes the attacker.
Distinguish transient failures from auth rejections everywhere in the refresh path. Logging users out on a network blip is its own outage.

The uncomfortable lesson: a security control that's too eager is
indistinguishable from a bug to the person it locks out. Scope the
blast radius to the actual threat.

I'm building EveryPenny, a private,
multi-currency money tracker for iPhone. This one shipped a fix the
same day — solo means the postmortem and the patch are the same
afternoon. Ask me anything about the auth model in the comments.