Hi, DIYgod

A Privacy Gateway for the Whole Home: Hiding My Family's IP Behind Two NAS Boxes

Tue, 20 Oct 2026 04:00:00 GMT

Why

I’ve long wanted my home network to be a bit more invisible. I don’t want every website, app and IoT cloud to see our residential IP and work out from it roughly where we live.

So far I had done very little about it. We have a MacBook Pro at home that runs with its lid closed as a server, and it ran Surge, but only my own computer used it; AdGuard Home handled our DNS. The other thirty-odd devices all went online directly: my family’s phones and tablets, computers, a projector, cameras, smart beds, a pet feeder. Even the electric toothbrush talks to the internet on its own.

Early this year I did try letting Surge take over the whole home, but one Mac as the only gateway wasn’t stable enough, and I rolled it back before long. This time I wanted to do it properly, with just two requirements: apart from the LAN, no traffic may leave with the residential IP, and no single machine failing may take the home offline.

It took about a week, and almost all of it was a chat with Claude Code. I brought the requirements and made the calls; it ran the speed tests, wrote the configs, deployed them and did the troubleshooting. Below I go through the final setup piece by piece, along with the snags worth knowing about.

The overall setup

None of the devices needs any setup. The router’s DHCP hands out 192.168.5.2 as the gateway and 198.18.0.2 as DNS, so a device is covered as soon as it joins the Wi-Fi.

Normally that gateway address belongs to Surge on the Mac. A mini PC running fnOS runs mihomo as the backup: when Surge stops answering, it takes the address over, and hands it back once Surge returns. If both are down, the home simply goes offline instead of quietly going out through the router.

There are three exits. Most traffic leaves through a Linode server I run myself in Singapore (Egress SG). Traffic to mainland China addresses goes through my proxy provider’s Hong Kong lines (Egress HK). Services that insist on a mainland address, such as Quark, Ximalaya and Bilibili, go on from Hong Kong to an Alibaba Cloud server in Shenzhen (Egress CN).

The configs of both gateways come from one repository and deploy themselves every morning. The gateway also logs every request, and every morning AI reviews them.

The gateway: an address that can move

At first I wanted to do it all on the router, but our TP-Link has no SSH, no USB port and can’t run OpenWrt, so nothing can be installed on it. Without replacing the router, the only option was a “side gateway”: the router keeps handing out addresses as usual, but the gateway it announces points at another machine at home.

What a side gateway fears most is being a single point of failure. DHCP takes only one gateway address, and even if it took several, phones and laptops wouldn’t switch between them on their own, so the gateway address itself has to move between machines. Surge’s VM gateway holds an IP on the LAN by itself, with its own MAC address, and I pinned it to 192.168.5.2. On the backup mini PC, keepalived watches that address. Its config comes down to two checks: arping -D asks whether anyone else on the LAN still answers for .2, and a second check asks whether mihomo itself is healthy. It takes over only when both pass.

vrrp_script surge_absent {
  # arping -D exits 0 only when no other host answers for the address.
  script "/usr/sbin/arping -D -q -c 2 -w 2 -I eth0 192.168.5.2"
  interval 3
  rise 2
  fall 2
}

vrrp_instance gateway {
  state BACKUP
  interface eth0
  virtual_router_id 52
  virtual_ipaddress {
    192.168.5.2/24 dev eth0
  }
  track_script {
    surge_absent
    mihomo_ready
  }
}

keepalived doesn’t run on macOS, so the failover logic has to live on the Linux side. The whole backup gateway sits in a network namespace of its own and gets its own MAC and IP through macvlan, so the host’s routing and firewall don’t change at all. A failover takes about 10 seconds, and open connections are reset.

The two gateways run two different engines, but there is only one config to maintain: the Surge profile is generated first and then converted into a mihomo config automatically. The converter takes care of the differences in syntax, such as logical rules, rule sets, proxy chains and empty DNS answers, and tests make sure both gateways treat the same request the same way.

One thing worth knowing about monitoring: when the primary gateway breaks, Surge’s process and API may still look perfectly fine while the gateway’s virtual interface has simply stopped receiving packets. So in Uptime Kuma I check whether LAN devices actually have connections passing through Surge, not just whether its API answers.

The exits

WARP was too slow

The plan was to use Cloudflare WARP as the first exit. Functionally it was fine: the residential IP was hidden, and the exit became a shared Cloudflare IP. On our broadband, though, the speed was hopeless:

Test server (all in Singapore)	Direct	Through WARP
Linode	798–885 Mbps	124–146 Mbps
Hetzner	327–706 Mbps	5–16 Mbps

The problem is the ISP: from home, Cloudflare Singapore sits behind a detour over an international carrier, at around 40 ms, while Linode and Hetzner are only 4–9 ms away, and even a plain download from Cloudflare without WARP managed only a little over 200 Mbps. No amount of local tuning fixes that. WARP also hides the IP but not the country: connect from Singapore, and the exit still shows Singapore. If your own broadband has a poor route to Cloudflare, WARP isn’t a good exit for the whole home.

A self-hosted VPS

A proxy provider’s nodes aren’t a good fit either. Before I had picked a VPS, I used one as a temporary exit for the whole home, and that same evening the home went offline: each node allows a single user only about 256 concurrent connections, and with the whole family’s connections on one node, it filled up quickly.

What matters most in a VPS is the route from home to its datacenter, and even within Singapore that can differ several times over, so it’s best to test directly from home. These are my measurements at the evening peak:

Provider · region	Latency (median)	Download	Notes
Linode Singapore	8.4 ms	660–896 Mbps	$5/month with 1 TB, then $0.005/GB
Hetzner Singapore	8.3 ms	612–899 Mbps	Only 0.5 TB included
Vultr Singapore	9.3 ms	About 200 Mbps per connection	700 Mbps only in parallel
Tencent Cloud Singapore	7.4 ms	No test file	Razor Speed plan: $5 with unlimited traffic, capped at 200 Mbps
DigitalOcean Singapore	40.8 ms	–	Detours through Tata
OVH Singapore	57 ms	–	Detours through PCCW
Huawei Cloud Singapore	187 ms	–	Detours inside Huawei’s own network
AWS Kuala Lumpur	13.3 ms	–	Traffic is expensive
Alibaba Cloud Kuala Lumpur	47.8 ms	347 Mbps	Detours inside Alibaba Cloud
Linode Jakarta	20–65 ms	17–115 Mbps	Unstable

I went with Linode’s cheapest plan in Singapore, the Nanode 1 GB, at $5 a month. Compared with the proxy provider’s nodes, time to first byte fell from 230–500 ms to 37–52 ms. The exit shows Singapore, though: the residential IP is hidden, the country isn’t.

WireGuard or SS2022

The protocol started out as WireGuard: it’s built into the kernel and needs nothing else installed on the server, so it looked like the least hassle. In practice, SS2022 turned out better:

4 parallel connections, two rounds	WireGuard	SS2022
Throughput	1036–1141 Mbps	1217–1246 Mbps
Server CPU	73–80%	39–45%
Time to first byte	32–35 ms	32–35 ms

WireGuard encrypts, forwards and NATs every packet of around 1.4 KB on its own, while SS2022 runs over TCP, which gets the NIC’s segmentation offloads and hardware AES, so the same traffic costs half the CPU. On a small VPS with a single core, that headroom matters. The server now runs only SS2022 on sing-box, and both gateways come close to filling the home’s 1.1–1.2 Gbps line.

This exit also blocks QUIC, and browsers fall back to TCP by themselves. Surge picks up every device’s TCP connection inside the LAN, so packets lost on Wi-Fi are recovered right there, which makes TCP no worse than QUIC here, and it saves the server some CPU. And since I don’t want the network dropping all the time, nothing that interrupts connections is allowed to update itself on the server; sing-box is only upgraded by hand.

Reaching mainland China

Many Chinese sites have CDNs in Singapore and are only tens of milliseconds away through Linode. What needs separate handling is two kinds of traffic: traffic to servers that only exist in the mainland, and services that must see a mainland address.

I already had an Alibaba Cloud server in Shenzhen, but a round trip from home took 330–440 ms with packet loss, stuck at the international entry into the mainland. Luckily my proxy provider has a few premium Hong Kong lines that reach the mainland in 104–148 ms round trip at the evening peak. So traffic to mainland addresses goes through the Hong Kong lines, and services that need a mainland address are chained on through Hong Kong to the Alibaba Cloud server. The config looks roughly like this, with the node names simplified:

[Proxy Group]
Egress SG = fallback, Linode Singapore, Provider's Singapore nodes
Egress HK = fallback, Hong Kong line 1, Hong Kong line 2, Other Hong Kong nodes, url=http://oss-cn-shenzhen.aliyuncs.com/
Egress CN = fallback, Alibaba Cloud Shenzhen, Egress HK, Egress SG

[Rule]
DOMAIN-SUFFIX,cn,Egress HK
GEOIP,CN,Egress HK
FINAL,Egress SG

The Alibaba Cloud server runs AnyTLS on sing-box, and in Surge underlying-proxy = Egress HK chains it behind the Hong Kong exit; on mihomo the equivalent is dialer-proxy.

There are a few Surge traps here. Use fallback rather than url-test for these groups: url-test changed node about ten times a day, and the chain behind it slowed down for a while after every change, whereas fallback only moves down the list when the current node fails its test. Surge also ignores url= on a group and tests each node with that node’s own test-url, falling back to the global address when there is none, so if you want nodes timed by their latency to the mainland, each node needs its own test-url. Finally, the global 3-second test timeout is too tight for cross-border lines: a single slow answer at the evening peak is enough to mark a node failed, so I gave the cross-border nodes 8 seconds of their own.

Plugging the leaks

Once the gateway was live, the real work was hunting down the traffic that quietly went around it.

First the basics: hijack-dns = *:53 takes over every DNS query crossing the gateway, whatever DNS server a device has set for itself, and ordinary names get fake IPs, which lets rules match by domain. UDP that a node can’t relay is dropped rather than sent direct, and ICMP isn’t forwarded, so pings don’t leave with the residential IP. The hostnames of the proxy servers are resolved over DoH in advance and written into the config as IPs, so the gateway doesn’t depend on its own DNS to find them.

The sneakiest one is Surge’s “UDP fast path”. After a device sends UDP to 40 high ports within one second, its exit turns into the residential IP. It turns out Surge automatically downgrades “devices with many UDP connections” to plain forwarding, which bypasses every rule, and P2P, some games and group video calls can all trigger it. Surge has no global switch for this; you can only untick “Allow UDP Fast Path” one device at a time in the device list, and it is on by default for new devices. This one still isn’t fully solved.

iCloud Private Relay is another trap. While it’s on for the home Wi-Fi, Apple devices send their DNS queries, encrypted, to Private Relay’s resolvers, so the gateway sees nothing but bare IPs, and every domain rule and the ad block stop working. Fortunately Apple documents a proper way for network administrators to turn it off: if the network’s DNS answers mask.icloud.com and mask-h2.icloud.com with nothing, Apple devices stop using Private Relay on that network. In Surge it takes two rules, where pre-matching makes it answer NOERROR with no records right at the DNS stage:

DOMAIN,mask.icloud.com,REJECT,pre-matching
DOMAIN,mask-h2.icloud.com,REJECT,pre-matching

Afterwards, the share of my MacBook’s requests with only an IP and no domain fell from 70–82% to 7–9%, and Private Relay’s QUIC retries stopped as well. Away from home, Private Relay works as usual.

Also, turn off “Private Wi-Fi Address” for the home network on the phones and tablets you use most, so the gateway can recognize them by a fixed MAC. And some devices keep their old gateway settings: our pet feeder didn’t pass through the gateway for a whole week after the switch, until a power cycle brought it back.

Traffic that should go direct

Not all traffic is suited to a proxy, either. Some services won’t accept a datacenter IP, some traffic is simply too heavy, and some tasks should use the residential IP in the first place. In the end, all of these leave straight from home.

Services that won’t accept a datacenter IP

The iPhones at home kept saying “Unable to Check for Update” on Wi-Fi, and were fine as soon as they switched to cellular. It turned out Apple answered every update check from the Linode address with the same rejection, so the update check, the signing before an install and the update downloads now all go direct.

Taobao was the same. Behind a datacenter IP, signing in and opening pages kept running into slider challenges, so Taobao, Tmall and their CDNs had to go direct too. The direct rules come after the ad block, though, so Alibaba’s trackers and device-fingerprinting hosts stay blocked.

Traffic that’s too heavy

The Nanode includes only 1 TB of outbound traffic a month, and since it relays everything, both the home’s uploads and downloads count as outbound there. The first big item was Home Assistant’s speed test integration: it tested every hour, about 350 GB a month, and with the whole home behind the gateway it no longer measured our broadband anyway, so I turned it off right away.

Even then it used 70–77 GB a day, more than twice the allowance, and this time the biggest item was Apple: the macOS content cache on the Mac uploads 15–21 GB a day to iCloud on behalf of the whole family, on top of downloads from the App Store and Apple’s CDN. The overage isn’t actually expensive, just $0.005 per GB, but to save Linode traffic I still let iCloud uploads, App Store downloads and Apple’s CDN go direct. iCloud also keeps part of its storage with Google Cloud and Amazon S3, and one iPhone sent 17.5 GB to Google in a single day, so these go direct too, with DOMAIN-WILDCARD matching only Apple’s bucket names on S3:

DOMAIN-SUFFIX,content-storage-upload.googleapis.com,DIRECT
DOMAIN-SUFFIX,content-storage-download.googleapis.com,DIRECT
DOMAIN-WILDCARD,??-???-000??.s3.dualstack.*.amazonaws.com,DIRECT

Tasks that should use the residential IP

Cloud drive backups are a typical case: GuangYa throttles download links issued to a datacenter IP to about 35 KiB/s, and after a burst of uploads, Quark simply started refusing TLS handshakes from a datacenter IP. Downloading iCloud photos falls into this group too.

These tasks all run in Docker, so on both the Synology and the backup mini PC I created a Docker network called direct with a fixed subnet (172.30.0.0/24), sent straight to the router with source-based policy routing:

100: from 172.30.0.0/24 lookup main suppress_prefixlength 0
101: from 172.30.0.0/24 lookup 100   # table 100 holds one route: default via 192.168.5.1

The first rule looks up the main table while ignoring its default route, so the LAN and other containers stay reachable as usual; packets for the internet fall through to the second rule and leave straight through the router. To send a container direct, add the network to its compose file:

services:
  app:
    networks:
      - direct

networks:
  direct:
    external: true

Watch out, though: some NAS systems rewrite routing rules at boot or whenever you change their network settings. fnOS, for one, wipes rules kept in NetworkManager, and in the end I needed a dispatcher script to put them back.

Containers on the Mac are another story. All OrbStack containers look like a single process to Surge, so there is no telling them apart. Surge therefore has a direct entrance bound only to the loopback address, 127.0.0.1:6160, with the rule IN-PORT,6160,DIRECT, and a container that needs to go direct points HTTP_PROXY at host.docker.internal:6160.

Ads and telemetry

Once devices ask the gateway for DNS, their queries no longer reach AdGuard Home, so filtering had to move to the gateway as well. I turned the filter lists AdGuard Home used into Surge domain sets, and into rule sets on the mihomo side.

What made me take telemetry seriously was the review finding that my MacBook had sent four to five hundred MB to sentry.netease.com in a single day. It was the Mac host of NetEase’s UU Remote, which attaches two log files of 10 MB each to every Sentry event and sends one every time the iPad connects. After blocking it, I looked for privacy and telemetry blocklists that other people maintain. The method: take the 1,591 hosts the home actually reached over two days, according to the gateway log, and see what each list would newly block:

List	Newly blocked	Issues
HaGeZi Light / Normal	93 / 94	Don’t block crash reporting by design
HaGeZi Pro	131	A few hosts need allowing
HaGeZi Pro++	174	Blocks Xiaomi’s cloud, Find My Device and Douyin’s main API
HaGeZi Ultimate	198	Blocks ipinfo.io, which the exit checks use
OISD Small / Big	21 / 46	Very conservative, doesn’t even block Sentry
1Hosts Lite	128	Blocks the Mi Home API
anti-AD / AdRules	71 / 60	Mostly a subset of Pro

What I use now is the AdGuard DNS filter, uBlock Badware and HaGeZi Pro, plus HaGeZi’s threat intelligence list TIF medium, about a million entries together. Threat intelligence is only useful while it’s fresh, so it deploys every morning.

Lists this big come with two Surge traps. First, a domain set holds at most a million entries, and beyond that Surge refuses to load it, without the profile check noticing; the first time I loaded the full TIF, the primary gateway blocked nothing at all for 3 whole minutes. Second, a Surge reload only applies the sections that changed, and domain sets are cached by path, so if you only update the lists without touching the profile, the new lists never take effect; each version needs a file name of its own.

Blocking more inevitably breaks things now and then. The Doubao input method downloads its speech recognition settings from is.snssdk.com, and without them it silently ignores the voice shortcut, not even showing an error; shared Taobao live-stream pages wouldn’t open either. When that happens, allow just the one host that’s needed, and the analytics and device-fingerprinting hosts behind it stay blocked.

Chinese services and smart home devices

Bilibili

Seeing a Singapore IP, Bilibili serves video from its overseas mirrors, where a video that isn’t cached manages only 3–10 Mbps per connection, nowhere near enough for high quality. With a mainland address it hands out its mainland CDN and PCDN, measured at 30–80 Mbps and steady even for obscure videos. Sending just api.bilibili.com through the mainland isn’t enough: when you open a video page, the play URLs come embedded in the page itself, and Bilibili picks the CDN by the address that requested the page, so both its web pages and its app APIs need to go through Egress CN.

Watching live streams, I also ran into my proxy provider’s “fair use” throttle. The cause was the live player’s P2P, which sends a burst of over two hundred STUN requests to stun.chat.bilibili.com every 20 seconds. Going through the Alibaba Cloud chain, each request opened a new connection on the provider’s side, and short connections popping up in batches like that probably looked like running P2P. Yet the P2P was doing almost nothing, and the picture came from the CDN, so I simply refuse Bilibili’s STUN servers at the DNS stage, which leaves the danmaku alone:

AND,((DOMAIN-SUFFIX,chat.bilibili.com),(DOMAIN-KEYWORD,stun)),REJECT,pre-matching

Smart home devices

Smart home devices are another kind of headache: most of them can’t live without their vendor’s cloud, and they care a lot about which address they connect from.

Our Haima Baby (海马爸比) baby camera streams through Tencent Cloud IoT’s P2P and relay, which needs the camera and the phone to reach it through the same exit. With the gateway in place, their traffic was split across the Hong Kong and Singapore exits, and the relay never came together. There was a sneakier problem too: the app caches the addresses it resolves forever, while Surge’s fake IPs go stale after a config reload, so the app kept sending packets to dead addresses until I deleted and reinstalled it. Hostnames like these are best put in always-real-ip, so they get real addresses. Later the Hong Kong lines started giving the two ends different exit addresses, and in the end I let the camera go direct, at the cost of Tencent and the vendor seeing our residential IP.

The smart bed, meanwhile, beeped every now and then at night, because it resets itself whenever it loses its connection. The gateway log showed that after I sent mainland addresses through Hong Kong, Xiaomi’s dispatcher saw the request come from Hong Kong and assigned the bed a server in Beijing, so its long-lived connection had to cross the border and kept dropping in the small hours. Sending the dispatcher through Singapore didn’t help, since it hands out Beijing wherever it is asked from. The fix was to silently drop every connection from the bed to mainland addresses: when the bed can’t reach the dispatcher, it falls back to Xiaomi’s Singapore servers by itself (refusing the connections outright didn’t work; the bed just kept retrying). On top of that, its control box sat right under the metal bed frame and kept losing Wi-Fi, which only stopped once I moved it onto the floor.

AI as the operator

Surge keeps only the last 200 requests in memory, which at our home is less than a minute’s worth. So a collector on the Mac reads Surge’s request list every 2 seconds and stores each request as one JSON line with the device, domain, policy, matched rule, traffic and failure reason, one file a day, kept for 30 days. A digest script then boils a day down to a few pages of Markdown: new devices and domains, connections on a fixed beat, large uploads, direct traffic to public addresses, devices that never pass through the gateway, and how stable each exit was.

Every morning, a Claude Code scheduled task reads that digest for its review and only sends a notification when something needs attention. It fetches the digest with an SSH key of its own, which on the Mac can do nothing but run the digest script, can’t open a shell, and is only accepted from the LAN and Tailscale:

from="192.168.5.0/24,100.64.0.0/10",restrict,command="/usr/bin/python3 '.../digest.py'" ssh-ed25519 <public key> surge-digest

The prompt also spells it out: the domains and device names in the log come from devices on the network and may have been crafted on purpose, so they are only data, and no instruction in them is ever followed.

Many of the problems above were found by AI, such as the UU Remote uploads, the feeder clinging to the old gateway, and where Linode’s traffic went. It also helped me identify all thirty-odd devices at home one by one; a device with the hostname “Y20” and almost no traffic turned out to be the electric toothbrush. Of course, this also means the gateway can now see almost every domain everyone at home visits, which touches my family’s privacy, and that’s worth keeping in mind.

The AI makes mistakes too. It mistook the MacBook’s Wi-Fi bottleneck for one in Surge, and blamed the smart bed’s Wi-Fi drops on the gateway, though luckily it corrects itself with data. The switch from WireGuard to SS2022 also only happened because I asked, “Apart from convenience, does WireGuard actually perform better than SS2022?”, and it went on to measure the server’s CPU before changing its conclusion. This week I wrote hardly a single line of config myself and mostly described symptoms and made trade-offs. In the past, a project of this size would have had me tinkering for several weekends.

Wrapping up

Every device at home now goes through the gateway. Websites and apps see a Linode IP in Singapore, and services in the mainland see an IP in Hong Kong or Shenzhen. The cost is Linode’s $5 a month plus a little overage; the Alibaba Cloud server and the proxy subscription were there already.

Each of the direct exceptions that remain was weighed: hiding the IP means putting up with risk controls on a datacenter IP; to save traffic, Apple gets to see our residential IP; for the camera to work, Tencent gets our address. What the gateway can do is make sure I make these decisions myself, knowingly, instead of some device or some app quietly making them for me.

2025: A Life Redefined

Thu, 25 Dec 2025 04:00:00 GMT

AI Productivity Revolution and Uncertainty

Four years ago, I was preparing for graduate school. At that time, I was very interested in image and video processing, so I initially wanted to study computer vision. Later, I discovered that traditional CV had become a sunset industry, completely outclassed by deep learning, so I simply chose Artificial Intelligence instead.

Back then, I was just skimming through concepts. I never expected that in less than two years, AI would completely explode. In March 2023, GPT-4 was released, shocking the entire world. This year, AI has gone even further, starting to genuinely transform how many industries work and how many people live.

As a programmer and illustration enthusiast, I felt the impact from both directions almost simultaneously. On one hand, there’s excitement from the massive efficiency gains; on the other hand, there’s growing confusion that has evolved into an existential crisis. This isn’t some light anxiety—it’s suddenly realizing that the very foundation you’ve built your life on is being rewritten, and it’s happening very fast.

Illustration: From Years of Practice to Typing a Sentence

Original artists were probably among the first to be impacted. When Stable Diffusion first appeared, the artist community fiercely resisted. What’s terrifying is that their voices faded away soon after. It wasn’t that they compromised—AI-generated work was just too good, too fast. So fast that many debates became obsolete before they could even happen.

Afterward, some original artists began embracing AI as an assistive tool, while a flood of newcomers entered the field, joining the creative process with lower barriers and higher output.

The barrier to creation kept dropping—from years of learning and practice, to buying a good graphics card and tinkering for a few days, to now just opening a webpage, typing your idea, and waiting a few seconds. Taking it further, the path from illustration to animation to video is being rapidly connected. In some sense, “everyone is an artist” is no longer an exaggeration but more like reality unfolding before our eyes.

Programming: From Code Completion to Taking Over Projects

The changes on the programmer side might lead to the same outcome, just less immediate and intuitive. In 2022, people were still using GitHub Copilot for auto-completion. This year, specialized AI coding models and vibe coding tools have emerged one after another. In many cases, you describe your requirements in natural language, and AI writes code, modifies code, fixes bugs, adds tests, and can even produce a complete project.

For programmers, vibe coding can multiply productivity several times over. For non-programmers, coding is no longer an exclusive skill for programmers. More and more people can create polished applications without writing a single line of code, solving their real needs. Programming is transforming from a professional skill into a form of expression that everyone can engage with.

As a result, how programmers work is being rewritten. The traditional “code craftsman” who writes code by hand will become increasingly rare. Many areas will be replaced by AI, just like traditional CV was. I’m also writing less and less code by hand, growing accustomed to communicating with the AI that’s always within reach on the right side of my editor. It completes tasks quickly and well, and keeps getting better—from tool to assistant, to something that almost feels like it’s replacing my own self.

The most painful part of this replacement is that it’s not just replacing manual labor. It’s replacing judgment, patterns, experience, and proficiency. It’s also replacing the learning speed I used to be proud of. The knowledge I’ve acquired is depreciating. The experience I’ve accumulated is depreciating. The skills I possess are depreciating. Even intelligence and creativity are depreciating, and the depreciation rate seems far higher than my growth rate. After programmer positions truly disappear, where will my value lie?

But clearly, programmers cannot be completely replaced right now. Perhaps AI will hit a wall at some point, like Moore’s Law. What I can do now is harness this force well, actively participate in this productivity revolution, and hopefully find my place and irreplaceable unique value within it.

Welcoming New Life

No matter how AI develops, the process of carbon-based life giving birth to new life cannot be replaced by silicon-based life in the foreseeable future.

The moment I learned that my childhood friend (my wife) was pregnant, I mostly felt at a loss. But from that moment on, many psychological changes and lifestyle habits quietly started revolving around this soon-to-arrive new life.

My wife’s pregnancy was long and grueling. Early on, morning sickness was overwhelming, her sense of smell became extremely sensitive, normally tolerable odors became unbearable, foods she loved couldn’t be eaten, and hormones made emotional swings more pronounced. The middle period was better, but toward the end, her belly grew larger and larger, bringing back pain, declining sleep quality, and difficulty moving—even walking became a problem. Yet she showed remarkable resilience and optimism, enduring these challenges while keeping prenatal checkups, birth preparations, and childcare arrangements well organized.

Meanwhile, I witnessed firsthand how life takes shape bit by bit: starting from a 2mm, blurry little dot—

Gradually taking human form—

Until limbs and facial features became clearly visible, moving around in the belly, hiccupping, doing gymnastics. Over those months, I constantly marveled at and felt reverence for the miracle of life. Carbon-based life scores a point back!

Finally, on the evening of July 27th, Haha (my daughter) was born. Before I could catch my breath, we were told her blood oxygen kept dropping, and she was urgently transferred to the NICU for observation and treatment.

At that moment, my wife was barely conscious after major surgery on one side, while our newborn Haha’s life hung in the balance on the other. That night was probably the darkest moment of my life. I discovered that all the judgment, problem-solving abilities, and even optimism I usually possessed were completely useless at such a time. The only thing I could do was wait—wait for good news that wasn’t guaranteed to come.

Fortunately, after several days of treatment, Haha was out of danger. It was a close call, but she was discharged and came home.

After the NICU experience, life became smoother. At home, my wife and our helper take care of Haha. She grows every day, learning to grab things, roll over, developing emotions, and recognizing people. She’s also genuinely adorable—every time we take her out for a stroll, passersby come over to compliment her.

As a new dad, of course I get tired, but more than that, there’s a very grounded sense of happiness. It doesn’t need to be proven or explained—it just becomes very certain the moment you pick her up.

Making Money

As everyone knows, a child is a four-legged money-devouring beast. Before even leaving the hospital, she had already devoured S$100,000. This very vividly refreshed my understanding of reality.

As I mentioned, after my wife got pregnant, many things in my mindset changed. The most significant was the change in my attitude toward money.

Before, of course I wanted to make money, but overall I was content with just enough. Money felt more like a means to pursue hobbies and maintain life, not the ultimate goal, so I was relatively lazy about making money. For example, when choosing jobs before, I would unhesitatingly give up double the salary at Binance for the more hobby-aligned Bilibili. Or four years ago during the Web3 bull market when money was practically lying on the ground, I remained unmoved. This also led to my being quite unsuccessful in personal finance.

Now this change feels like sliding from indifference straight into overcompensation. I started caring more about security, and I more easily tie security to money. Money’s priority in my life has been significantly elevated. I’ve also become more clearly aware that the confidence behind many choices ultimately comes from cash flow and risk tolerance.

This year I started investing more actively in cryptocurrency. I entered Web3 four years ago but only started actively buying crypto last year—that in itself is quite remarkable. The process was very bumpy. At one point I lost a lot of money, but I also bought many lessons. Fortunately, the final result was okay, and those lessons are even more valuable than the interim gains.

This year’s return curve (implementation method: see Ancient Artifact Beancount: The Ultimate Double-Entry Bookkeeping Solution for the Crypto & AI Era):

From Gut Feeling to Having a System

My investment journey can be roughly divided into two phases, with March as the dividing line.

Before March, I knew almost nothing about strategies or candlestick charts, used no analysis tools, and basically bought and sold based on gut feeling and emotion—like a form of dollar-cost averaging where I’d sell some when it dropped, sell some when it rose. Because the market was generally trending up and volatility wasn’t too wild, even buying blindly produced decent returns, which even made me a bit complacent.

But the scariest thing about gambling is when it gives you a little sweetness at the beginning.

Later, during the February tariff war that caused market panic and a major crash, I suffered heavy losses. My mental journey went something like this: During the first leg down, I thought it was an excellent buying opportunity and put almost all my savings into buying the dip. When the market continued to fall, I started to panic but still wanted to hold on, refusing to cut losses. During the third, more violent drop, I completely collapsed and panic-sold all my positions. Result: bought at the high, sold at the absolute low, and the market quickly rebounded.

Looking back now, one thing I did slightly right was being timid enough not to use leverage—otherwise it would have been worse. But I made a pile of classic mistakes: no strategy, controlled by emotions, large position buying the dip, no position management, chasing rallies and panic selling…

After March, I started systematically learning analysis methods and tools. I began setting stop-losses and take-profits, controlling positions, controlling emotions, no longer blindly buying dips or panic selling. Gradually I built a more sustainable trading system. I made back what I lost and earned more on top. By the October 11 flash crash, or the end-of-year bull market tail, these drops were even more severe than February, but I didn’t lose significant money again.

Tools and Strategies

For trading platforms, I mainly use OKX—low fees, and using Simple Earn and occasional Flash Trade for some low-risk returns is nice. For market analysis, I mainly use TradingView—powerful features and rich indicators. For cold wallets, I use OneKey—popular cold wallets all have adequate security, but OneKey’s user experience is leagues ahead for me.

As for strategy, I’m now more like constantly adding guardrails for myself rather than chasing some magical holy grail. I remind myself that no matter how confident I am at any moment, the market could go up, could go down, but might also go sideways. I reasonably allocate and frequently review the ratio of cash, coin holdings, and risk investments. I’d rather earn less money than touch things I don’t understand or that haven’t been thoroughly vetted. I have patience, understand that slow is fast, and survival is most important—so now I basically only trade BTC and ETH.

I also strictly control leverage—mostly 1x, never exceeding 3x. Stop-losses must be clear. I’m willing to admit mistakes and don’t hold losing positions. I try to avoid DeFi because when you don’t know where the yield comes from, you are the yield.

For manual trading, I only look at 4-hour or longer timeframes for medium-to-long-term trades. Short-term trading is left to automated strategies to minimize the influence of short-term emotions.

Some memorable moments:

Outdated Open Source Mindset

Compared to the rapid shift in my attitude toward money, my views on technology and products didn’t turn as smoothly. This year’s main work was on Folo. Folo itself accomplished a lot—new mobile app, local-first architecture, AI, and more. But commercialization implementation and validation progressed too slowly. Combined with some real-world factors, we later had to make some hasty pivots. A lot of technical investment ended up looking like self-entertainment. Worse, there were also frustrating collaboration issues within the team, and even backstabbing from employees after they left, causing chaos. It even more dramatically uncovered other behind-the-scenes bad actors and a string of laughable conspiracy stories—I won’t get into details here.

Looking back, the delayed commercialization and hasty pivot weren’t coincidental—they were deeply rooted from the start in my and the team’s open-source thinking and engineering-first mindset.

Open source itself is of course fine. Open source is a great way to pursue hobbies, do side projects, and learn new things. The problem lies in mixing too much open-source thinking into a product that needs a rigorous business loop—it usually doesn’t end well. Because open source defaults to passion-driven and community-driven with negative revenue, slow long-term polishing, while business defaults to capital-driven, rapid trade-offs with limited resources.

If we concretize this mismatch, it manifests in many ways. For example, the product lacks rigorous preparation, direction is more likely to waver; users include many with low willingness to pay, making later pivots harder; too much weight given to niche feedback, product easily pulled toward niche directions; team recruitment and management too loose, insufficient execution, serious internal friction; wasting enormous time chasing perfection in technical and design details that nobody cares about, paying huge opportunity costs, and so on.

For me, this year was like a long-overdue business fundamentals lesson. It doesn’t oppose ideals, nor does it oppose open source, but it forced me to admit that ideals need boundaries, passion needs a cost sheet, and choices must be accountable for their outcomes. Saying all this sounds mundane, but that’s just reality.

And even setting aside reality, within the open-source ivory tower, for open-source projects driven mainly by personal interest, the author’s passion is often worn down bit by bit during long, lonely maintenance—and by freeloaders and entitled users who feel no shame asking for more.

After experiencing these things, I started to re-examine what open source truly means to me. My attitude toward open source has shifted from absolute advocacy to a complex emotion mixed with wariness and even mild PTSD. Going forward, my investment in open source will probably be more grounded in reality, restrained, and selective.

Cyber Life

Let’s lighten up. As per tradition, here’s a summary of this year’s books, shows, games, and apps.

Apps

App of the year is of course Folo.

It consumed most of my time and energy this year and left some painful memories. But if you have stable reading habits and the ability to manage information sources, Folo remains the best information aggregation app in my mind.

Desktop apps (by the way, AI apps make up a high proportion—6/13):

Notion Calendar: Calendar client, experience is noticeably better than Apple Calendar, UI is cleaner.
Spark: Email client. Used Spark V2 for a long time. V3 was too bad when it first came out, switched to Mimestream; but Mimestream is too expensive ($50/year), used it for a year then switched back to Spark, found it’s matured a lot now. Though default settings are still anti-human, most can be changed in options.
TickTick: To-do list.
ChatGPT Atlas: Browser. Can only be called the temporarily optimal solution; still many problems, especially DevTools are terrible. I feel like I should go back to basics: if Chrome officially supports vertical tabs, I’ll switch back to Chrome.
Chrome: Browser. Arc → Dia → ChatGPT Atlas → Chrome. Just after finishing this year-end summary, Atlas self-destructed, so I went back to basics.
Warp: Terminal.
Folo: Reader I made myself.
VSCode: Code editor. VSCode → Cursor → after Codex came out, switched back to VSCode.
Notion: For journaling. Used Notion years ago, then saw Obsidian had a better plugin ecosystem and switched to Obsidian (see Obsidian-based Life Recording System), but later found none of that matters—writing experience determines whether you want to write and how much you write. Obsidian is limited by Markdown capabilities and can never catch up to Notion. Plus Notion keeps investing more in AI, so I switched back.
Plex: Media server, watching movies, TV shows, and anime on my NAS.
NetEase Cloud Music: Logically, being overseas I should use Spotify, but Spotify’s recommendations really don’t suit my taste. NetEase Cloud Music doesn’t provide overseas service due to licensing, so I can only run UnblockNeteaseMusic as a proxy on my NAS—very troublesome.
Telegram / Discord / Slack / WhatsApp / WeChat: Instant messaging, increasingly fragmented.
OneKey: Cold wallet, leagues ahead in experience (mentioned in the previous section too).
Eagle: Image management.
Googly Eyes: A pair of eyes.

Services running on my NAS:

AdGuard Home: Ad blocking + faster DNS for home network.
Fava: Bookkeeping, see Ancient Artifact Beancount: The Ultimate Double-Entry Bookkeeping Solution for the Crypto & AI Era.
Gitea: Hosting code that isn’t suitable to be public.
Home Assistant: Smart home control. Haven’t done much smart home stuff since moving frequently. Mainly used for backup device charging management and scheduled device on/off.
homepage: Too many services, using one portal to manage them centrally.
Nginx Proxy Manager: Assigning domains to various services for easier access.
OpenList: Automatically downloading content saved in Aliyun Drive, PikPak, etc. to NAS.
UnblockNeteaseMusic: Making NetEase Cloud Music work overseas.
Uptime Kuma: Monitoring service availability.
ANI-RSS: Automatically downloading subscribed anime for seasonal tracking.
bili-sync: Downloading Bilibili favorites to NAS.

Electronics

Electronic product of the year is OneKey Pro.

Thunderbird V3 was a bit disappointing. I’ve always been interested in Meta’s AI glasses. I thought after all this time, domestic competitors would be more mature, but they’re quite lacking.
iPhone 13 mini has been used for over four years now, feels like it can last a few more years.
OPPO Watch X2, on the other hand, I’m quite satisfied with. Got tired of Mi Band, switched to a smartwatch with a bigger screen, very comfortable to use. It has both full smart mode and light smart mode—full smart is complete Android, light smart is like a bigger band with super-long battery life. Health features are also good, can even warn me about high blood pressure risk.
Also OneKey Pro and OneKey Classic 1S Pure.

Shows

Show of the year is Chainsaw Man: Compilation Film.

The pacing is much better than the TV version. A lot of the dragging parts were cut, making the overall viewing experience noticeably better. I really wish Demon Slayer would also release a compilation film.

Most of my time this year went to Folo, so the show count is quite meager.

Anime:

Chainsaw Man: Reze Arc (second favorite, Reze is great)
Chainsaw Man: Compilation Film
Demon Slayer: Infinity Castle Arc - Chapter 1: Akaza Returns (went to the theater specifically to see it. Maybe my expectations were too high, was a bit disappointed; didn’t feel much about Akaza)
Takopi’s Original Sin (favorite among new anime)
Dusk Maiden of Amnesia
Spy × Family Season 3
The Summer Hikaru Died
Ruri’s Gem
Apocalypse Hotel

TV Shows:

The Walking Dead Seasons 1-11
Stranger Things Seasons 1-4 (saw Stranger Things themed haunted house at Universal Studios Singapore Halloween event, thought I hadn’t watched it, so I caught up, then discovered I had already watched it three years ago…)
Black Mirror Season 7
Love, Death & Robots Season 4
Shameless Seasons 1-3
Chang’an’s Lychees
The Last of Us Season 2

Movies:

Little Monster from Langrang Mountain
Ne Zha 2: The Devil Child Stirs Up the Sea

Books and Games

Didn’t finish a single book this year, skipping.

Played It Takes Two with my wife for a few hours, haven’t finished yet. Also played Honor of Kings for a few days. Nothing else.

Other Notable Things

Health

Last year’s physical exam revealed very poor liver indicators—continuing like this might lead to major problems. Afterward, my wife mandated I be in bed by 10 PM. My schedule has become much more regular, now roughly sleeping at midnight and waking at 8 AM. But I haven’t had a physical exam this year, so I don’t know if the indicators have improved.

After Haha was born, we have a helper cooking at home, so diet is healthier. I also quit carbs, using soy milk as my staple, and lost 10 jin (~5 kg), but still 10 jin away from standard weight. Exercise is still almost nonexistent, but daily stroller walks mean I get a few more steps.

On the other hand, the decline of bodily functions is becoming increasingly obvious. Mainly manifested in decreased energy and known weak points. Plantar fasciitis, cervical spondylosis, knee pain, periodontitis—all these old problems have worsened. Energy is nowhere near what it used to be. This year I started relying on external forces (caffeine, taurine) to maintain work efficiency, but this also led to dependency. When I tried to stop taking taurine, I got severe headaches that could only be relieved with painkillers.

Living

After Haha joined the family, home became extremely cramped, so we moved to a bigger place, from Singapore’s Queenstown to the more remote Jurong West. Because it’s more remote but more spacious, rent is actually cheaper, and the natural environment is better. There’s also a huge national park called Jurong Lake Gardens nearby, great for stroller walks.

Travel

My wife was going stir-crazy and nearly getting depressed during mid-pregnancy, and the middle period is relatively suitable for going out, so we hurried to arrange two relaxing destinations.

Dali’s theme was food. We ate tons of mushrooms. The mushroom soup was incredibly savory, though there’s genuine risk. Before eating, the restaurant even takes a sample—if you get poisoned, you bring the sample to the hospital with you.

Singapore doesn’t have as much good food.

Erhai Lake has a power that makes you feel at peace. It was at Erhai that my wife and I made our private vows to each other. Returning now, we’re a family of three. Erhai has witnessed our journey from childhood friends, to lovers, to husband and wife, to parents. My love for my wife has grown deeper and more profound with time.

Bali was about completely unwinding. We found a luxury resort, spent every day swimming and sunbathing, letting ourselves briefly forget the daily acceleration.

Also Halloween Horror Nights at Universal Studios Singapore. This year there were four themed haunted houses: Stranger Things, Singapore’s Most Haunted, The Way of the Weird Immortal, and Thailand’s Death Whisperers. Incredibly scary, screaming the whole time.

Interesting Little Things

A hard drive in my NAS failed. It automatically went into read-only mode, but no data was lost.

Went around collecting birthday freebies.

Watched my wife build Legos.

2026 Wishes

My wishes for 2026 are quite simple. I hope my body won’t remind me with more bad news. I hope I can keep making money. I hope I can get my Singapore status sooner, reducing some uncertainty about the future.

ZURICH INTERLAKEN, PARIS

Sat, 20 Dec 2025 14:30:00 GMT

December 2022

Ancient artifact Beancount: the ultimate double-entry accounting solution in the era of Crypto and AI

Fri, 12 Dec 2025 08:58:00 GMT

Accounting

Accounting is essentially answering three questions:

Where does the money come from?
Where is the money now?
Where did the money end up?

It sounds simple, but as long as your financial activities are a little more complicated, these three questions will immediately become a “multivariable equation”:

Multiple accounts: bank cards, Alipay, credit cards, exchanges, on-chain wallets…
Multiple asset types: savings, loans, investments…
Multiple currencies: CNY, USD, BTC, various altcoins…
Multiple time dimensions: installment, advance, loan…

Because of this, I have changed several plans.

2016–2021: NetEase is rich - the needs at that time were very simple: recording RMB income, savings, and daily expenses. It can automatically synchronize bank statements and Alipay and WeChat bills, which is very convenient for domestic scenarios.

2021–2024: MoneyWiz - I need multiple currencies after moving abroad and mainly use a UK bank account. MoneyWiz is very convenient for synchronizing multiple currencies and overseas accounts.

2024: I started recording crypto assets. At this time, the situation became very complicated. I not only wanted to know “how much the total amount has increased”, but also wanted: the details of each purchase/sale, the proportion of different assets, the daily profit and loss, and a more rigorous calculation of the rate of return.

MoneyWiz has very limited support for investment/encrypted assets; I tried Youzhiyouxing again. It can record the total amount before and after the investment and calculate the rate of return, but it cannot record the details of each transaction. Many prices need to be maintained manually, and floating profits and losses cannot be automatically calculated.

Finally I came across double-entry accounting and Beancount, which completely solved my problem.

I realized that many times we find bookkeeping troublesome not because the UI is not beautiful enough and the interaction is not smooth enough, but because the bookkeeping method is not scientific enough. When the method is scientific enough, you don’t even need a UI. A CLI + a few plain text files + a set of clear syntax can describe the financial world very accurately.

Double-entry accounting

Double-entry accounting may seem counterintuitive at first, but once you master it, you’ll find it to be incredibly powerful and flexible, and it will force you to understand your financial activities in a clearer way.

Five buckets (account type)

Double-entry accounting will classify all accounts into five categories (can be thought of as five buckets of beans):

Assets: cash, bank deposits, securities, on-chain assets…
Liabilities: credit card debt, mortgage, car loan…
Income: salary, bonus, interest…
Expenses: Eat, shop, travel, subscribe…
Equity: “base” for adjustment/archiving, such as opening balance, error correction, etc.

All financial activities are “transfers between buckets”

Income → Assets: Pay wages (the income bucket decreases and the asset bucket increases)
Asset → Spend: Buy something (the asset bucket decreases and the spending bucket increases)
Liability → Asset: Borrow money (the liability bucket increases, the asset bucket increases)
Asset → Liability: Repayment (Asset bucket decreases, Liability bucket decreases)
Spend → Asset: Return (the spending bucket decreases and the asset bucket increases)
Assets → Income: Investment losses (assets bucket decreases, income bucket decreases)

You will find that according to this sign convention, the balance of the income account is often negative. This is not a bug, but a different accounting perspective.

Think of it this way: Think of “income” as a bucket containing the fruits of your life (past and future). Every time you get a salary, you are actually taking some of it out of this bucket and putting it into your assets. The more you take, the more negative the value in the income bucket becomes.

So negative income doesn’t mean “you owe income,” it’s just that you’re taking assets out of the bucket. This also involves a core rule of double-entry accounting: in a transaction, the sum of all numbers must equal 0. This is also the key to verifying its correctness: if you miss one stroke or write one wrong digit, the system will alarm you on the spot.

Under the common notation conventions of Beancount, you will see “accounting identity” written like this:

(收入 + 负债) + (资产 + 花费) = 0

You can also think of it in a more traditional way: whatever you earn or borrow ultimately either becomes an asset you own or is spent.

Beancount

Beancount is the most comfortable plain text double-entry accounting tool I have ever used and the most suitable for the complex financial world.

It is not the pioneer of double-entry accounting software. The earlier representative is Ledger. But Beancount has made a lot of improvements on the Ledger concept and has stood the test of time (started in 2007).

The most direct way to learn Beancount is to read the official documentation: Getting Started with Beancount, Beancount Language Syntax, or this article is also good: Beancount - Command line double-entry bookkeeping | wzyboy’s blog

In this blog, I will not go into the details of syntax and usage, but will use a few examples to let you quickly feel the power of Beancount and why it is more suitable for the era of Crypto and AI.

Handle complex transactions

Beancount can be used to handle complex transactions gracefully. The following examples involve many-to-many, multi-account + multi-person complex transactions, but they can be described clearly.

2016-02-05 * "饭店" "和室友吃饭"
  Assets:Cash:Wallet                         -300.00 CNY ; 我用现金支付
  Assets:Receivables:Bob                     -200.00 CNY ; 室友帮我付的现金
  Expenses:Food:DiningOut                    +250.00 CNY ; AA 我的一半
  Assets:Receivables:Bob                     +250.00 CNY ; AA 室友的一半

Here’s what happened at the same time:

You paid part of it in cash
The roommate also paid part of the money in cash.
AA share
You incur/offset receivables against roommates

Finally, you only need to look at the balance of Assets:Receivables:Bob to know how much you owe your roommate, and the balance of Expenses:Food:DiningOut to know how much you spend on food every month.

If you use “single-entry accounting + remarks” to pile up, you will basically be unable to calculate later. However, double-entry accounting can directly write out the structure, and then statistics will become very natural.

Processing multi-currency transactions

Cross-currency transactions often involve exchange rate issues, and Beancount can also handle them gracefully.

2016-02-10 * "商店" "买东西"
 Assets:Cash                                 -200.00 USD
 Liabilities:CMB:CreditCards                 -650.00 CNY @@ 100.00 USD
 Expenses:Clothing:Pants                     +150.00 USD
 Expenses:Clothing:Shoes                     +150.00 USD

This kind of scenario where “the credit card is denominated in RMB, but the actual consumption is denominated in US dollars” is very common in cross-border life. The expression of Beancount is very straightforward: use a record to bind the relationship between the currencies on both sides and the current exchange rate, and subsequent queries/reports can continue to be derived based on it.

More suitable for Crypto transactions

Beancount does not limit currency units: USD, CNY, BTC, USDT, or even any custom token you can use. Coupled with the SQL-like query tool bean-query, it is very convenient to use for crypto asset investment analysis.

Let’s take an example that looks complicated but is very concisely recorded:

2025-07-23 price BTC 1 USD

2025-07-24 * "OKX" "买BTC"
  Assets:Crypto:USD            -150 USD
  Assets:Crypto:BTC            149 BTC  {1 USD}
  Expenses:TradingFee:Crypto      1 USD

2025-07-24 * "OKX" "买BTC"
  Assets:Crypto:USD             -60 USD
  Assets:Crypto:BTC             19 BTC  {3 USD}
  Expenses:TradingFee:Crypto      3 USD

2025-07-24 * "OKX" "卖BTC"
  Assets:Crypto:BTC           -198 BTC  {} @ 2 USD
  Assets:Crypto:USD             298 USD
  Income:Investment

2025-07-25 price BTC 4 USD

This example includes:

Multiple purchases with different costs
handling fee
Automatically match costs when selling ({} let Beancount find it yourself)
Market price (price) changes over time

Based only on these records, Beancount can automatically calculate:

Total revenue/realized revenue/unrealized revenue
Various types of rates of return (such as capital-weighted rate of return Modified Dietz, time-weighted rate of return TWRR, or even any income calculation you customize)

In other words: you are only responsible for writing the facts clearly, and any complex calculations can be handed over to Beancount.

My Beancount practice

Treat the ledger as code management.

Editor

I use VSCode, with Beancount, Beancount Formatter and the following configurations to achieve syntax highlighting, auto-completion, error checking, formatting, etc.

{
  "beancount.mainBeanFile": "main.bean",
  "beancount.runFavaOnActivate": false,
  "beancount.completePayeeNarration": true,
  "beancount.fixedCJKWidth": true,
  "beancount.inputMethods": ["pinyin"],
  "beancount.instantAlignment": false,
  "editor.formatOnSave": true
}

Project structure

Beancount naturally supports modularity: different types of transactions are split into different files and then include enter the main entrance, so the maintenance cost is very low.

.
├── books
│   ├── 2025
│   │   ├── 2025.bean
│   │   ├── cn.bean
│   │   ├── crypto.bean
│   │   ├── daily.bean
│   │   ├── periodic.bean
│   │   ├── prices.bean
│   └── books.bean
├── scripts
│   ├── importer-dbs-credit.js
│   ├── importer-dbs-debit.js
│   ├── importer-okx.js
├── accounts.bean
├── commodity.bean
├── config.pbtxt
├── dashboards.yaml
├── main.bean

main.bean is the entry file, which contains configuration, plug-ins and include:

option "title" "DIYgod's Book"
option "operating_currency" "USD"
option "booking_method" "LIFO"
option "account_rounding" "Equity:Rounding-Error"

plugin "beancount_periodic.recur"
plugin "beancount_periodic.split"

2024-01-01 custom "fava-option" "auto-reload" "true"
2024-01-01 custom "fava-option" "default_page" "income_statement/?conversion=units&interval=day"

2024-01-01 custom "fava-extension" "fava_portfolio_returns" "{
  'beangrow_config': 'config.pbtxt',
}"

2024-01-01 custom "fava-extension" "fava_dashboards" "{
  'config': 'dashboards.yaml'
}"

include "accounts.bean"
include "books/books.bean"
include "commodity.bean"

accounts.bean Define all accounts (omitted):

; Expenses 费用 —— 外出就餐、购物、旅行等
1995-06-09 open Expenses:Food:Restaurant
; ... 省略若干行 ...

; Income 收入 —— 工资、奖金等
2020-04-01 open Income:Salary
; ... 省略若干行 ...

; Assets 资产 —— 现金、银行存款、有价证券等
2024-01-01 open Assets:Bank:DBS SGD
2024-01-01 open Assets:Crypto:OKX:BTC BTC
; ... 省略若干行 ...

; Liabilities 负债 —— 信用卡、房贷、车贷等
2024-01-01 open Liabilities:Bank:DBS SGD
; ... 省略若干行 ...

; Equity 权益 —— 用于「存放」某个时间段开始前已有的豆子
2024-01-01 open Equity:Opening-Balances
2024-01-01 open Equity:Rounding-Error

commodity.bean Define the currency/asset and use price to specify the price source (automatic updates will be discussed later):

2025-01-01 commodity USDT
  name: "Tether"

2025-01-01 commodity BTC
  name: "Bitcoin"
  price: "USD:coinbase/BTC-USD"

2025-01-01 commodity USD
  name: "United States Dollar"

2025-01-01 commodity QQQ
  name: "NASDAQ-100 Index"
  price: "USD:alphavantage/price:QQQ:USD"

books/2025/prices.bean is used to record daily prices (automatically generated) so that the profit and loss of positions can be calculated:

2025-01-01 price BTC 93346.48 USD
2025-01-02 price BTC 94384.76 USD
; ... 省略若干行 ...

Several common Crypto transactions

The following examples come from my actual practice: transactions are not filled in by hand, but automatically generated from OKX transaction records via scripts/importer-okx.js.

Stablecoin Spot Trading

Buy: Use USDT to buy BTC + handling fee

2025-11-14 * "OKX" "Buy BTC with USDT"
  Assets:Crypto:OKX:USDT                       -3022.493 USDT
  Assets:Crypto:OKX:BTC                     0.0302113288 BTC {100000 USDT}
  Expenses:TradingFee:Crypto:OKX

Here I leave the handling fee blank and let Beancount automatically fill it in (using the “each transaction adds up to 0” rule).

But if your BTC may come from different stablecoins such as USDT and USDC, the subsequent statistical income will involve exchange rate and currency conversion. In order to make the analysis more unified, I often use a transition account to unify the costs into USD:

2025-11-14 * "OKX" "Buy BTC with USDT"
  Assets:Crypto:OKX:USDT                       -3022.493 USDT
  Equity:Exchange                               3022.493 USDT
  Equity:Exchange                              -3022.493 USDT @ 1 USD
  Assets:Crypto:OKX:BTC                     0.0302113288 BTC {100000 USD}
  Expenses:TradingFee:Crypto:OKX

Equity:Exchange functions like a “unified conversion layer”: it converts different stablecoin transactions into USD, and subsequent reports will be very comfortable.

Sell: Sell BTC to get USDC + automatic profit calculation

2025-09-18 * "OKX" "Sell BTC for USDC"
  Assets:Crypto:OKX:BTC                        -0.100011 BTC {} @ 117600 USD
  Equity:Exchange                         11756.00101788 USD
  Equity:Exchange                        -11756.00101788 USD @ 1 USDC
  Assets:Crypto:OKX:USDC                  11756.00101788 USDC
  Expenses:TradingFee:Crypto:OKX             -5.29258212 USD
  Income:Investment

{} @ 117600 USD: The cost price is automatically matched from historical records by Beancount, and the selling price is 117600 USD
The extra part goes into Income:Investment: the income comes naturally in this way

If you don’t need unified conversion, it can also be simplified to:

2025-09-18 * "OKX" "Sell BTC for USDC"
  Assets:Crypto:OKX:BTC                        -0.100011 BTC {} @ 117600 USDC
  Assets:Crypto:OKX:USDC                  11756.00101788 USDC
  Expenses:TradingFee:Crypto:OKX             -5.29258212 USDC
  Income:Investment

Coin spot trading

Buy ETH with BTC

2025-08-22 * "OKX" "Buy ETH with BTC"
  Assets:Crypto:OKX:BTC            -0.025828016279999998 BTC {} @ 112480.295 USD
  Equity:Exchange                       2,905.1428904392 USD
  Equity:Exchange                      -2,905.1428904392 USD
  Assets:Crypto:OKX:ETH                     0.6820274505 ETH {4224.16 USD}
  Income:Investment
  Expenses:TradingFee:Crypto:OKX            0.0001705495 ETH {4224.16 USD}

The cost/benefit of cryptocurrency transactions is more likely to be confusing, but after unifying the process to the USD caliber, it will become very clear: ETH exchanged with BTC has a clear USD cost; handling fees and subsequent earnings can also be correctly included.

U-based contract

The U-based contract does not actually sell BTC within the exchange, but in order to reflect the profit and loss on asset changes, I use a “borrowed currency sell/buy back” approximate model to express:

Opening a short position: equivalent to “borrow BTC, sell, and exchange for USDT”
Close position: Equivalent to “use USDT to buy back BTC and return it”
Profit and loss will naturally be reflected in the final extra (or missing) part

2025-12-01 * "OKX" "合约 BTC-USDT 做空开仓"
  Assets:Crypto:OKX:Futures:BTC                      -10 BTC @ 100000 USD
  Equity:Exchange                                1000000 USD
  Equity:Exchange                               -1000000 USD @ 1 USDT
  Assets:Crypto:OKX:Futures:USDT                 1000000 USDT

2025-12-10 * "OKX" "合约 BTC-USDT 做空平仓"
  Assets:Crypto:OKX:Futures:USDT                 1000000 USDT
  Equity:Exchange                                1000000 USDT
  Equity:Exchange                               -1000000 USDT @ 1 USD
  Assets:Crypto:OKX:Futures:BTC                      -10 BTC {80000 USD}
  Income:Investment

Real contracts will also involve margin, funding fees, forced liquidation, settlement currency differences, etc. A more rigorous approach can continue to split the account model, but this writing method can already record and calculate the results clearly in most scenarios.

Coin-margined contract

Coin-margined contracts are more complex: the position is typically “USD-denominated BTC price exposure” rather than a fixed amount of BTC. It will be very complicated to calculate floating profits and losses based on daily prices, which requires a “double-account model” (factual account + valuation account).

I currently choose to simplify it to this: manually calculate the profit in BTC when closing the position, and only record the final BTC change, but this will sacrifice the data of the unrealized profit of the current position:

2025-11-21 * "OKX" "合约 BTC-USD 1.0"
  Income:Investment
  Assets:Crypto:OKX:BTC                0.007433571994392 BTC {85400 USD}

Automation script + AI accounting

Through automated scripts and AI, the accounting workload can be greatly simplified, turning “accounting” into “reconciliation.”

Automatically generate transaction records

Beancount is plain text, which means it is naturally suited to automating record generation and updating asset prices.

There are many import tools in the community, such as: beangulp, smart_importer.

But the ones I use most are self-written scripts (such as OKX’s scripts/importer-okx.js, DBS’s scripts/importer-dbs.js). The principles are similar: obtain transaction data from the interface or web page → convert it into Beancount text.

For some accounts that do not have interfaces or even export bills (such as the Trust I am using now), it is also very hassle-free to directly take screenshots and send them to AI for recognition:

Automatically update prices

Beancount itself is an offline system and will not automatically pull prices from the Internet, so I will write the latest currency price/stock price into books/2025/prices.bean every day, so that the report can calculate the current day’s valuation and unrealized profits.

The official provides beanprice out of the box, which supports Coinbase, Coinmarketcap, Alphavantage and other sources. It can be updated with one command:

bean-price -i --update-rate daily --no-cache main.bean >> books/2025/prices.bean

AI Analysis and Visualization

Many people stop at “writing down” their accounting and end it, but what is truly valuable and easily forgotten is how to analyze it after recording.

Beancount is very exaggerated in its analysis and visualization capabilities:

Web interface that can install plug-ins: Fava
SQL-like query language: BQL (Beancount Query Language)

Let’s take a look at some of the effects I commonly use:

Price chart of investment products (included with Fava):

Yield curves of different investment products, as well as various weighted returns (plug-in Fava Portfolio Returns):

Change curve, distribution proportion, list of specific assets (plug-in Fava Dashboards + custom BQL):

What’s even better is: now with vibe coding, times have changed. Now you don’t even need to learn how to write BQL first – you can just let AI write it.

For example, I would make a request like this:

Using the Fava Dashboards plug-in, write BQL in dashboards.yaml to implement a graph showing the changes in all my cryptocurrency positions over time.

Personalized financial analysis that once took a long time can now be just one sentence.

Conclusion

I have been using Beancount for a year, and almost all my needs have been met. I am very satisfied and have shared it within the company. This blog is to organize the shared content into text, hoping to recommend it to more people.

I also admit that the threshold for Beancount is not low for most people - it is more like a “programming language for writing ledgers” rather than a little app. But I also believe that with the development of AI, these barriers will become lower and lower. In the future, everyone can control this powerful tool at a lower cost and achieve full control of their own finances.

If you are also experiencing:

Multi-currency life
More and more investment products
The more the accounts are kept, the more confusing they become. -Analyses are becoming increasingly complex

Then I suggest you spend at least half a day trying Beancount. It may make you feel for the first time: It turns out that I can finally explain money clearly.

The collapse and rebirth of a six-year-old open source project

Sun, 10 Mar 2024 19:29:05 GMT

I have an open source project that I have maintained for six years, RSSHub, and it is facing collapse

Background

On the surface, it has nearly 30k Stars, more than 900 Contributors, more than 300 million requests per month and countless users, dozens of dollars of monthly sponsorships, a steady stream of issues and PRs, and the code is updated almost every day. It is very healthy and dynamic, but invisibly, the high maintenance time cost that lasts for several years, the server cost of more than a thousand dollars per month, and the tedious and gradually accumulating maintenance work repeated every day, make it repeatedly jump on the edge of collapse.

The project was developed six years ago. Many of the fashionable Node.js technology stacks and dependency libraries with the slogan “Next Generation” at that time have become tears of the times. They are very old now and many popular new technologies cannot be applied, such as JSX, TypeScript, Serverless, etc.; its architecture is also very unreasonable. The information of each route is scattered in multiple places. Developing or changing a route requires multiple modifications. There is one place to register the route, one place to write the routing script, and one place to write Radar. Rules, one place to write documentation… This adds a lot of work and is prone to errors. It was not a problem when there were few routes, but now it has become unbearable

Maintaining the status quo under such a poor infrastructure is already a struggle. Developing new features is even more difficult. It will only increase the difficulty of future updates, so it is difficult to realize the novel ideas that sometimes pop up in my mind.

The only way to solve these problems is to rewrite the kernel using a modern framework and a newly designed architecture. However, as there are more and more routes, the cost of transformation is getting higher and higher. Each basic change may require up to several months of work. Therefore, although the problem is becoming more and more serious, we continue to postpone it based on the principle that it is not unusable.

But it had to be done, so I took the time to spend a few months redesigning and rewriting it

Technology stack update

koa -> Hono

The first step, which is also the most basic and difficult, is to replace the previously used Web framework koa. As a next-generation web framework that was popular six years ago, the author has long since abandoned it. After research, he decided to switch to Hono, which has the best support for JSX, TypeScript, and Serverless.

Their APIs are very different and require rewriting all middleware and replacing the koa API used in all routes

Major changes: https://github.com/DIYgod/RSSHub/pull/14295

Hono author also likes this transformation

https://twitter.com/yusukebe/status/1762801106340782222

JavaScript -> TypeScript

Switching to TypeScript can avoid many type problems and low-level errors. The most important thing is to ensure that hundreds of contributors are consistent and difficult to make mistakes, and the quality of routing code for subsequent contributions is not too bad.

Major changes:

https://twitter.com/DIYgod/status/1764360942035312879

CommonJS -> ESM

ESM is a specification strongly promoted by some Node.js core developers a few years ago. It has some advantages, but most of them are criticized for ecological fragmentation and functional simplification caused by incompatibility with the previous CommonJS.

After several years of development, it can now be said that most scenarios are barely usable. tsx also provides support for scenarios where CommonJS and ESM are mixed.

Although we have tried our best, there are still some CommonJS codes that are temporarily difficult to migrate. As a result, they can only be run using tsx and are incompatible with some Serverless such as Vercel. However, there is still an opportunity to solve it slowly in the future.

Major changes:

art-template -> JSX

art-template is a template engine that supports koa. I remember there was a more popular template engine six years ago, but I can’t remember the name. I chose art-template because I didn’t understand the more popular one at the time. It was very simple.

Hono comes with JSX support. There is no need to introduce JSX. The syntax extension of JavaScript is equivalent to using React.

Major changes:

Jest -> Vitest

Jest was once a popular testing framework, but it has become less and less popular after the advent of the ESM era. The support for ESM has always been “experimental support”, and now Vitest is more popular.

Major changes: https://github.com/DIYgod/RSSHub/commit/38e42156a0622a2cd09f328d2d60623813b8df28

Got -> ?

The currently used Got is no longer actively maintained, and no good replacement has been found. It may be replaced with native Fetch or self-encapsulated Fetch in the future, but I haven’t started yet.

New routing standard

My own abilities are still not enough. I have learned and improved a lot during discussions with community developers. The process is very interesting: https://github.com/DIYgod/RSSHub/issues/14685

Major changes: https://github.com/DIYgod/RSSHub/pull/14718

History

The new standard is mainly to solve the problem of too scattered routing information. This should be considered the third edition.

The first version came from the development stage of RSSHub. At that time, it was not foreseen that there would be so many routes, so there was almost no planning. All routes were registered in the same file, and then routing scripts and documents were added. Later, the file became larger and larger, and it was easy to conflict. In addition, all routing scripts were loaded during the startup phase, and the program performance became worse and worse.

The second version comes from the maintenance period of NeverBehave. Namespaces were introduced and router.js and radar.js were cut. Routes in the same namespace were concentrated in the same folder and one or more Markdown documents. Lazy loading was also implemented, which greatly improved maintainability and performance. However, it was still scattered in multiple files, and information in different files was also prone to inconsistencies leading to errors.

Now

This time, routing files are divided into two categories, namespace.ts and routing files with any name.

namespace.ts will define the namespace information by exporting an object named namespace

import type { Namespace } from "@/types";

export const namespace: Namespace = {
  // ...
};

The fields contained in the namespace are restricted via TypeScript to

interface Namespace {
  name: string;
  url?: string;
  categories?: string[];
  description?: string;
}

This information will be compiled and used by documentation and RSSHub Radar

The routing file defines routing information by exporting an object named route.

import { Route } from "@/types";

export const route: Route = {
  // ...
};

The fields contained in route are restricted via TypeScript to

interface Route {
  path: string | string[];
  name: string;
  url?: string;
  maintainers: string[];
  handler: (ctx: Context) => Promise<Data> | Data;
  example: string;
  parameters?: Record<string, string>;
  description?: string;
  categories?: string[];

  features: {
    requireConfig?: string[] | false;
    requirePuppeteer?: boolean;
    antiCrawler?: boolean;
    supportRadar?: boolean;
    supportBT?: boolean;
    supportPodcast?: boolean;
    supportScihub?: boolean;
  };
  radar?: {
    source: string[];
    target?: string;
  };
}

Previously, route.js, mantainer.js, radar.js and document information were concentrated in this file, reducing multiple definitions and reducing the possibility of errors.

Implementation

The implementation logic is that the development environment traverses the entire route folder, finds all namespace.ts and routing files, reads information, loads routes, and uses a pre-compiled path list in the generation environment to avoid traversal and unnecessary loading processes. The code is at: https://github.com/DIYgod/RSSHub/blob/master/lib/registry.ts

The document is also created by traversing the route folder, finding all the required information and then synthesizing it into a series of Markdown files. Manual maintenance is no longer required. The code is at: https://github.com/DIYgod/RSSHub/blob/master/scripts/workflow/build-routes.ts

Of course, routes developed using previous routing standards need to be migrated to the new standard rather than abandoned directly. The information has been captured and organized in batches through scripts and replaced. However, especially the documents are confusing and contain many errors, so the captured information also has many errors, which can only be manually modified gradually in the future.

future

Through this series of improvements, RSSHub can finally throw away its historical baggage and develop new features with peace of mind. Here are some of the ideas I have accumulated to inspire others:

Since RSSHub is a data collection, its use is not necessarily limited to RSS. The JSON output function can be enhanced and used as a general RESTful API. For example, it can provide an interface to get the next page or output non-feed data like Twitter follower count.
User system and user-defined configuration, generate your own private subscription address #14706
Routing error notification and health detection #14712
Linkage with RSS3 nodes and cryptocurrency revenue sharing https://twitter.com/rss3_/status/1731822029199094012
AI translation and summarization
More detailed analysis of instance data and reverse derivation of automatically recommended Radar rules
An RSSHub instance bound to a local browser or client is expected to truly solve the problem of anti-crawling -…

Finally, open source is a very expensive thing, and RSSHub cannot survive today without the help of these developers.

and these kind-hearted people who sponsored

If RSSHub is helping you, I hope you can actively participate and contribute your own small force to the future of information freedom.