Inspiration
OJK's Indonesia Anti-Scam Centre logged 432,637 fraud complaints and Rp9.1 trillion in reported losses between November 2024 and January 2026, and returned only Rp161 billion of it. Recovery isn't winning this fight. A nationally representative survey from the Global Anti-Scam Alliance found that 86 percent of Indonesian adults believe they can spot a scam, but 31 percent of that confident group got scammed anyway in the same year. Every verification tool available in Indonesia today, including the government backed IC4 platform, waits for someone to notice something is wrong, open an app, and paste the suspicious link or file into a form. Most scams arrive through WhatsApp, either as a link or a disguised .apk file such as the fake wedding invitations BSSN has warned about, and by the time a person thinks to check, they've usually already tapped. We wanted to remove that step.
What it does
Bulwark runs quietly on Android and blocks scam links and malicious .apk files the moment they're accessed, without asking the user to check anything first. A local VpnService tunnel reads the DNS query and TLS SNI of every outbound connection on the phone, not just the browser, and drops a connection inside the tunnel before the TCP handshake completes if the destination domain is flagged. A separate file observer watches the Download folder and messenger media folders, hashes any newly written .apk file with SHA-256, and quarantines it before the user can open it. Both checks hit the same on-device cache first, so a verdict the phone already holds comes back in milliseconds with no network call. When a threat is confirmed, a warning overlay appears above whatever app is on screen, explains in plain Indonesian what was stopped and why, and waits for the user to make a choice. Nothing gets forwarded to an external VPN server, and Bulwark never decrypts traffic or installs a certificate authority, so page content stays private.
How we built it
The client runs on Android in Kotlin. VpnService handles network-layer inspection, FileObserver and MediaStore observers handle download detection, and AccessibilityService adds a secondary layer that recognizes Android's package installer showing a flagged file and redraws the warning at that exact moment. Room over SQLite stores the offline threat cache, and Jetpack Compose builds the interface. A Node.js mediation layer sits behind the client: on a cache miss, it receives a truncated hash prefix, never a full URL, so the server never learns what page someone opened, queries our registry, falls back to Google Safe Browsing v5 for domains nobody has reported yet, and writes the result back into the cache. The registry itself is an append-only Solidity smart contract on the Polygon Amoy testnet, chain ID 80002, storing hashed domain entries and APK SHA-256 digests. We chose Polygon Amoy because it mirrors Polygon mainnet's consensus and gas behavior for free, and because every entry is readable on amoy.polygonscan.com with no account or API key, which means a bank, telecom operator, or government agency could verify what we've listed without trusting us to run a private database honestly.
Challenges we ran into
The biggest challenge showed up in Android's own security model. A normal app without device owner or MDM privileges can't force the package installer to refuse an installation outright. Google restricts DISALLOW_INSTALL_UNKNOWN_SOURCES to enterprise managed devices on purpose, since letting any third party app silently block another app's install would be its own attack surface. So the installer warning is a correctly timed, highly visible alert, not a hard block, and the real blocking has to happen earlier, at the network and download stage. We also had to design around a restriction that applies directly to us: from Android 13 onward, an app sideloaded through a non session package installer can't enable an AccessibilityService until the user manually opens App info and allows restricted settings. Our demo build will be sideloaded, so we built the architecture so both layers that actually do the blocking, VpnService and the file observer, use their own consent flows and never depend on that restricted permission. The other challenge was resisting an obvious but wrong assumption: older users. The data says otherwise. Millennials, men, and highly educated people were scammed most often over the past year, and people who said they could always spot a scam still lost an average of Rp576,279. We built the target market section around that finding instead of around the stereotype.
Accomplishments that we're proud of
We backed every claim in the problem statement with a named, dated, linkable source, seventeen of them, from OJK press releases to BSSN advisories to PANDI's own abuse reports, instead of guessing at how bad the scam problem is in Indonesia. We also caught our own bias before it became public: we assumed elderly users would be the obvious target, checked that assumption against the GASA survey, and found it was wrong, so we rebuilt the target market section around millennials and confident users instead. And we're proud of the registry design itself. Using an append-only contract instead of a private database means no single organization, including us, can quietly edit or remove an entry, which is the exact problem that currently splits Indonesia's threat data across OJK, BSSN, PANDI, and IC4 with no way for any of them to audit another's record.
What we learned
We learned that Indonesia isn't short on anti-scam tools, it's short on tools that don't require a suspicious user first. IC4 already checks links, files, phone numbers, and bank accounts, and it has real government backing from BSSN and the Ministry, but only 20 percent of people have ever opened a tool like it. That told us the fix wasn't a better checker, it was moving the check off the user and onto the phone itself. We also learned how scattered Indonesia's threat intelligence really is: OJK, BSSN, PANDI, and individual banks all keep their own lists, and none of them can verify another's history. That's what pushed us toward a public ledger instead of another private database. And technically, we learned exactly where Android draws the line on what a third party app is allowed to block automatically, which shaped which parts of Bulwark actually stop something and which parts only warn.
What's next for Bulwark
Three things are deliberately out of scope for the 24 hour build: TLS interception, machine learning classification of domains nobody has reported yet, and iOS. Each is a separate project on its own, and none of the three made it into this proposal as something we'd promise and then not deliver. For a real release, we'd move off Google Safe Browsing v5's free tier and onto the paid Web Risk API, which we've already priced into the roadmap instead of discovering it later. The bigger goal is getting OJK's IASC, BSSN, PANDI's IDADX, and IC4 to actually write to a shared registry instead of keeping four separate lists that none of them can audit against each other. None of the client code is Indonesia specific either, so expanding to a new country is mostly a matter of seeding the registry with locally relevant entries and translating the onboarding copy, not rebuilding the app.
Log in or sign up for Devpost to join the conversation.