Beulah

I'm Beulah Evanjalin, a math and cryptography enthusiast working on Nested MuSig2, which is an advanced multi-signature scheme for Bitcoin. I'm funded by a one-year grant from both Second and Vora, with mentorship from Jesse Posner at Vora.

My work sits at the intersection of cryptography and Bitcoin infrastructure. I'm implementing Nested MuSig2 in the secp256k1-zkp library and drafting a BIP for it. The core idea is that MuSig2 lets you combine multiple public keys into a single aggregated key. The nested version takes that further; you can aggregate keys, then aggregate those aggregated keys again, and keep going. What you end up with on-chain is a single Taproot key that looks completely ordinary. Nobody can tell whether it's one person, a 3-of-5 setup, or a multi-device configuration. All that internal structure is completely private.

Why does this matter? Think about something like Ark, where an operator server needs to sign collaboratively across multiple machines in different locations. Today, that server holds one master key, which is a single point of failure. Nested MuSig lets you split that key across machines securely, and the user on the other side experiences none of that complexity. That's the kind of improvement I find genuinely exciting. Serious security gains with zero added friction for users.

Day-to-day, I'm reading through research papers, digging into the algorithm and workings, writing and testing code, and meeting weekly with Jesse to go over the hard parts. Implementing the nested case is non-trivial, so a lot of my time goes into really understanding why things work, not just making them work.

My background is in mathematics. I did my undergrad in math and my master's in computer science. So when I first encountered Bitcoin, what grabbed me wasn't the price or the narrative. It was the construction. Elliptic curve cryptography, hash functions, Schnorr signatures, and many. I wanted to understand all of it from first principles. I was working as a backend developer at the time, typical API work, fixing production issues, keeping things running. It paid the bills but wasn't where my heart was. So I started spending evenings and weekends going deeper into cryptography. Eventually, I found Chaincode Labs' Bitcoin open-source program, which was the real turning point. I got to contribute to the secp256k1 library and work on FROST, and that experience made it clear this was the direction I wanted to go.

For a long time, I was learning mostly through self-study, figuring things out as I went, but without much structure or feedback. I didn't know how to measure whether I was on the right track or what to focus on next. The BOSS Challenge changed that. It was intense and demanding in a way that was genuinely useful, because it forced me to produce real work and get real feedback, not just accumulate knowledge privately.

The funding came out of that momentum. I had been contributing to secp256k1-zkp and building a relationship with Jesse through the mentorship. When Second and Vora saw the work and recognized that nested MuSig was something both Bark and Vora's Lightning implementation needed, everything fell into place.

The fact that what I build belongs to everyone. When this implementation lands in secp256k1-zkp, any Bitcoin project can use it, not just the ones funding me. That feels meaningfully different from building a feature for one company's product. Also, it's the community. I'm not someone who naturally dominates discussions; I'm more of a listener. But in this space, that actually works in your favour. The conversations happening on Delving Bitcoin, in pull request reviews, in mailing groups, in mentorship sessions... they're dense, technical, and genuinely worth paying attention to.

Autonomy is both the best and the hardest part. Nobody is handing you a ticket and saying, "build this by Friday." You have to develop your own judgment about what's technically sound, what's worth pursuing, and what's ready to share. That's a skill in itself, and it takes time to build.

Something that genuinely surprised me is how much of the work is communication. You're writing BIPs, posting on Bitcoin groups, explaining your reasoning in pull request reviews, and writing documentation. The implementation is only part of it. If you can't articulate why your approach is correct and why it matters, the work doesn't land the way it should.

In my previous roles, the feedback loops and the goals were fast: ship the feature, fix the bug, keep the system running. But here, I might spend weeks deep in a research paper before writing a single line of code, and that's not only acceptable; it's necessary. It's also the first time I feel like my mathematical background is genuinely being used.