Building the Rails — My Work on PulseVM

I've spent most of my career close to blockchains that actually move money. For years that meant running production infrastructure on Antelope networks — operating validators, keeping nodes healthy, watching what real usage does to a chain at 3am. It's unglamorous work, and it teaches you things you can't learn from a whitepaper. Mostly it teaches you what breaks.

These days the project I care most about is PulseVM, and I want to write a little about what it is and what I actually do on it — because "I work on a blockchain" is both true and almost meaningless without the detail.

What PulseVM is

PulseVM is an open-source blockchain built for financial infrastructure rather than retrofitted into it. That distinction is the whole point.

Most chains pitched at banks ask the institution to translate its world into crypto's — hex addresses, gas markets, anonymous validators, every transaction public — and then bolt on layers of tooling to make it usable. PulseVM starts from the other end. Accounts are named and human-readable. Permissions are a real hierarchy — the kind of "teller can do this, treasury needs two approvals, here's the recovery path" structure a financial institution already runs on. Multisig is a protocol primitive, not a contract you deploy and pray you audited correctly. Settlement is instant and final: a transfer is either rejected immediately or settled permanently, with nothing probabilistic in between. And customers never touch a gas market — the institution provisions resources and sponsors its users, so the experience is just an app.

Under the hood it's the Antelope execution model — proven over a decade in production — running on modern Avalanche-style consensus. Old, battle-tested ideas about how accounts and contracts should work, on a new and fast foundation.

The part that matters commercially: because an institution can run its own network with its own rules, it can issue its own tokenized money and keep the deposits, the data, and the customer relationship on its own balance sheet — instead of watching all three leak out to a third-party app. That's not a small thing for a community bank or a credit union. It might be the thing.

What I do on it

PulseVM is the work of Glenn Mariën, Metallicus' CTO and one of the sharpest engineers I've worked with. He created it; I work alongside him on it. In practice that means a bit of everything, which is exactly how I like it:

• The core. Reading the codebase deeply, finding bugs, and contributing fixes and features upstream. Some of my favourite days lately have been the unglamorous ones — chasing down why a particular failure surfaced with no error message, tracing it through the VM, and shipping a fix that makes the next developer's life easier.
• Infrastructure. Running and maintaining a fleet of validators on the test network. This is the part my background prepared me for — the operational discipline of keeping a network healthy, coordinating upgrades, and treating other people's money with the seriousness it deserves.
• The supporting layer. A blockchain on its own isn't usable; it needs the services around it. I've been building command-line tooling, REST and indexer layers so standard tooling works against it, oracle and exchange backends to put it through real workloads, and the developer documentation at pulsevm.dev.

None of it is solo work, and I don't want to imply otherwise. It's a team, Glenn leads the core, and my job is to make the whole thing more real — more tested, more operable, more documented, easier to build on.

Why it's the most interesting thing I've worked on

I've watched a lot of "enterprise blockchain" come and go. Most of it failed for the same reason: it asked institutions to accept a model that didn't fit how they work, and papered over the gap with marketing.

PulseVM is the first time I've seen the primitives genuinely line up with the problem. The hard things — multisig, recovery, sponsored transactions, instant settlement, privacy within a network you control — aren't features here. They're the foundation. That changes what it means to build financial software on-chain: you configure your institution's structure instead of building and auditing a platform to express it.

It's early, and we're hardening it through real use — which, if you've done this long enough, you know is the only way maturity actually happens. But the direction is right, and getting it ready for real institutional use — banks, credit unions, payments — is the most rewarding engineering I've done.

If you're working on anything in this space — tokenized deposits, settlement, on-chain financial products — I'd genuinely like to compare notes. And if you just want to see what it looks like, pulsevm.dev is the place to start.