17 of 30 written in full so far
30 of 30 posts
Migrant workers sent $905 billion home in 2024, and almost none of it was spare cash: it is rent, food, school fees and medicine, often a household's only income. Seen that way, a fee and a three-day delay stop being administrative details.
· 8 min read
Two paths a $200 transfer can take, and what each one takes out of it: correspondent banks on one, pre-funded currency pools on the other. Then we price a real US to Mexico transfer at two providers, where the bank turns out to be both cheaper and faster than the money transfer operator.
· 10 min read
Writing out the full cost as an equation. Fixed fee, percentage fee, the exchange rate markup, and the cash-out charge on the other end. The advertised number usually covers the first one and stops there.
· 8 min read
Why the same $200 costs different amounts depending on where it is going. Competition, which banks talk to each other, how much of the currency is floating around, local rules, distance, and how many cash pickup points exist nearby.
· 9 min read
Sending $40 every week instead of $300 once is about managing cash week to week and being able to react to an emergency. Fixed fees punish this pattern, since a flat $5 costs a lot more proportionally on $30 than it does on $300.
· 6 min read
When there is a medical emergency, a job loss, a bad harvest, a storm, or political trouble, transfers from abroad tend to go up. This paper tries to put actual numbers on that pattern.
· 7 min read
Three systems do three different jobs on every cross-border payment: SWIFT carries the instruction, correspondent banks move the value, and RTGS makes it final. No money ever touches SWIFT itself. Knowing which layer you are looking at is what explains a bank saying "sent" three days before anyone can spend it.
· 8 min read
The banks sitting between a sender and a recipient, what Nostro and Vostro accounts are, and what each intermediary does. A longer chain means more time, more cost, and less ability to see where the money currently is.
· 10 min read
What each of those words means, and why an app can say "sent" while the receiving bank still does not have money anyone can actually spend. The gap between those two moments is where most of the confusion lives.
· 7 min read
Time zones, banking hours, batch schedules, compliance checks, currency conversion, and the last step of getting cash out to a local branch. Each one adds a bit, and they stack.
· 9 min read
Different countries and banks use different message formats, so information gets dropped or retyped at every handoff. We look at the mess, and at ISO 20022, which is the current attempt to standardise it.
· 8 min read
Ripping out the banking infrastructure that already exists is not realistic: licensing, compliance and final settlement all sit inside it. The useful work is in building bridges that are secure and legal, which is what the stablecoin sandwich and M-Pesa both turn out to be.
· 8 min read
Throughput limits, block capacity, congestion, fees that jump around, and confirmation times. Many small frequent transfers turn out to be a hard traffic pattern for a base layer to handle.
· 9 min read
Doubling the shards roughly doubles the capacity, but only for transfers that stay inside one shard. A remittance has three parties by default, so it is cross-shard from the start, and adding shards makes that more likely rather than less.
· 9 min read
A sidechain is fast because it runs on its own small validator set, and that is the same reason Ronin lost $625 million. Whether one could carry remittances comes down to whether its validators, its bridge and its settlement are chosen on purpose rather than inherited.
· 9 min read
Channels are the quickest option on paper. But they only work when somebody has funds parked on the receiving side, so this paper is mostly about that: capacity lockup, rebalancing, routing, and what happens when liquidity runs out mid-route.
11 min read · summary only
The impressive benchmark numbers for these three architectures were not measured the same way, under the same conditions, or against the same definition of a transaction. Setting them side by side compares a top speed on a closed track to an average speed in traffic, which is why published figures cannot settle which one suits a remittance workload.
· 8 min read
Speed, decentralisation, security, cost, privacy, following the rules, and being usable by someone who is not technical. You cannot max out all of them at once, and this paper is about which trade-offs matter here.
8 min read · summary only
The $200 everyone divides by is a fixed benchmark, not a measured average: the real US to Mexico average is $488. Working the throughput question properly, across four demand levels and an honest market share, lands nearer 14 to 33 transactions per second than the headline 143.
· 9 min read
An argument for measuring the slowest 1% (P99) instead of the average. A recipient who has been waiting three days does not care what the average was that week, and averages make a system look better than it feels.
7 min read · summary only
Adding up every cost layer: gas, bridge fees, the cost of locking up liquidity in a channel, currency conversion, and the fee to turn it into cash locally. The last one gets left out of most comparisons.
9 min read · summary only
We design failure experiments for each setup, taking nodes offline and slowing bridges down on purpose, then look at whether transfers roll back or funds get stuck somewhere in the middle.
10 min read · summary only
Rules meant to stop financial crime require collecting data, and collecting data creates risk for exactly the people who already have the least protection. This paper sits with that tension instead of pretending it resolves.
11 min read · summary only
A layered design: API gateways, translating messages into ISO 20022, regulated intermediaries handling settlement, and liquidity pools that work in real time rather than overnight.
12 min read · summary only
Which variables we change, what we assume going in, how the synthetic data gets generated, how the code is organised, and the log of every change we made along the way.
10 min read · summary only
How we generate realistic transfer traffic, how we check that it behaves like the real thing, and why a student project has no business collecting families' financial records in the first place.
8 min read · summary only
An energy-per-transaction accounting method, used to compare setups at the same transaction volume. Comparing them at different volumes proves nothing, which happens more often than it should.
8 min read · summary only
The barriers that have nothing to do with the technology: language, whether someone owns a smartphone, the documents a bank asks for, rural internet, and knowing how any of this works to begin with.
9 min read · summary only
A public guide to the patterns that keep showing up: rates that are too good, pressure to decide quickly, and cryptocurrency claims that fall apart under a look. We describe patterns and do not name or recommend any company.
9 min read · summary only
What came out of the first workshops in King County. What people understood better afterward, the questions that kept coming up, where our evaluation method fell short, and what we are changing because of it.
10 min read · summary only
