We are officially continuing our learning journey! If you missed the breakdown on the Weaver Protocol, do yourself a favor and catch up. Consider it a light warm-up before we dive headfirst into the deep end.
The Great Escape: Welcome to EXODUS
Today, we are talking about EXODUS (or EXchange Of Digital Unified Signatures, if you want to be formal).
Where does the name come from? Take your pick:
- The Bible: People gaining ultimate freedom over painful, slave-like complications.
- Transformers: Exodus - seriously, what is Michael Bay waiting for?
- Thrash Metal Band: because this protocol absolutely shreds.
- Gaming: A nod to the brilliant post-apocalyptic shooter Metro Exodus.
Whichever one you choose, the name goes hard. Let’s figure out what it actually does.
The Problem: We Were Supposed to Be Rebels
Let’s be honest. The crypto industry currently has the attention span of a goldfish on espresso. It loves to hype up shiny new buzzwords to distract you from the fact that the basic stuff is still broken.
Everyone on Crypto Twitter is screaming into the void about TPS, DePIN, PayFi, RWA, and ZK-Everything. If that’s not enough, we are being force-fed a daily alphabet soup of:
- Chain Abstraction
- Restaking
- L3 Hyper-Scaling
- Parallelized EVMs
- Modular Execution Layers
- Liquid Restaking Tokens
- Autonomous Crypto AI Agents
- Price Oracles
This is an infinite scroll for our media outlet. But at the end of the day, it is a multi-billion-dollar marketing circus designed to make you feel stupid if you aren’t investing in something that sounds like a sci-fi movie title.
But while everyone is hyper-ventilating over these abstract academic playgrounds, we are collectively ignoring the massive, bleeding elephant in the room. We are avoiding the one topic that actually impacts our everyday life from day one: actually exchanging our crypto without getting rekt.
The Great Amnesia: How the Revolution Throttled
When the first cryptocurrencies took their adoption, they were beautiful. A closed, perfect system - an ideal state machine that had predictable outcomes based on pure math! No banks, no intermediaries, no corporate bosses tracking our location and personal data. Just code, consensus, and freedom.
But from the very beginning, there was a birthmark that was always there. It was a genetic deformity in the ecosystem, yet we chose to look away from it because it was convenient. That birthmark is “centralized crypto exchanges”.
Look at how they evolved. They started in cozy internet corners and chat rooms as simple peer-to-peer swapping spots. Then, they entered their “Pirate Bay” era - wild, lawless and chaotic. But instead of evolving into true decentralized hubs, they mutated into corporate monsters.
Today, these platforms operate like traditional legacy banks, wrapped in a fake decentralized skin. They enforce arbitrary rules that their own customer support teams don’t understand, they hold our keys, they freeze our funds on a whim, and they harvest our data like Mark Zuckerberg on a good day.
The Illusion of Necessity
Let’s state the absolute obvious: there is zero need for a third party if you want to swap tokens inside the same network or transfer coins to someone.
The only logical use case for a centralized exchange is to act as an on/off-ramp to swap your crypto for real-world cash - and frankly, even that utility is shrinking by the day.
Instead of using this native, middleman-free architecture, we let our own laziness get the better of us. We fought a literal war against the legacy financial system to take full control of our money. But because true decentralization was “too hard” for the average user, we voluntarily handed the keys right back to a new pack of unelected corporate gatekeepers. We replaced the Wall Street suits with hoodies, but the Devil Wear Hoodi nowadays.
- It’s Your Money Bro (Until We Ctrl+C/Ctrl+V It Into Our Trading Account)
- Certified Emoji-Based Auditing Standards (GAAP-Approved by
)
We wanted absolute financial power. Instead, we traded our liberty for a slick mobile app UI and cheered while doing it.
The Bridges: The Ultimate Betrayal
If centralized exchanges were the first crack in the armor, what came next was a total breach of the wall.
Then came the bridges. The real Judases of this industry.
First of all, they tried so hard to make these apps user-friendly, but honestly? The app has no friends anymore. It’s completely alienated everyone who isn’t 3D chess grandmaster playing blindfolded against three supercomputers while solving a Rubik’s cube with their toes. The grand intent was to build it for everyone, but in the end, it was built for absolutely no one.
Moreover, they claim to be part of the tribe. They wear the t-shirts, they go to the hackathons, and they tweet about decentralization. But behind the flashy marketing, they completely violate the ultimate, foundational rule of crypto: Don’t trust, verify. Instead, their entire multi-million-dollar cross-chain architecture sounds like a shady Craigslist ad:
Hey, just send your life savings to this random address on Chain A. I promise I’ll automatically mint a wrapped version and give it back to you on Chain B. Trust me, bro.
And the moment you hesitate or ask about the underlying architecture, they try to hypnotize you with corporate gaslighting and security theater:
Don’t worry, we are bulletproof! We use a state-of-the-art multi-sig wallet to secure all locked funds!
The Multi-Sig Illusion
Do you really feel safe knowing your hard-earned money is trapped in a digital vault where the ultimate security strategy is literally just:
Hopefully a few anonymous guys in separate group chats don’t lose their keys or go rogue.
That isn’t cutting-edge security method; it’s a digital joint-checking account run by a handful of validators who might be storing their private keys on a sticky note or a compromised laptop.
SPOILER ALERT: They will lose them. Or they will get phished. Or a teenager in a hoodie sitting in a basement halfway across the world will exploit a logic flaw and drain their “bulletproof” vault over a long weekend.
And when the vault hits zero? Generic AI generated Twitter post that is always the same:
Community Update: We are actively investigating an unusual exploit involving our bridge contract. Security is our absolute top priority. We have paused all network activities and are collaborating with leading blockchain forensics teams to track the flow of funds. To our incredible community: thank you for your patience and loyalty as we work tirelessly to emerge stronger from this incident. Stay tuned for further updates.
(1/28)
Oh, and as a parting gift? Because you had to go through their compliance gate to use the bridge, your leaked KYC data, your passport scan, and your home address are now being sold on the dark web for the price of a cheap burrito. Enjoy the spam calls!
Forcing the Past Into the Future
But why do we keep believing them? Why do we fall for it every single time?
Because deep down, as human beings, we need to believe that there are honest people out there. If we lose that believe, living our lives simply hurts too much.
Our first great betrayer was the centralized exchange. Watching them evolve was a knife to the heart. They started as our friends, our peers, our entry ticket to the revolution. But then they slowly transformed into a cold, heartless bureaucratic machine. It is a deeply painful thing to watch your buddy transform into the very monster you were both fighting against.
So, heartbroken and desperate, we went in search of new allies. We looked for new ways to move our assets freely. And that’s when we found the bridges. But these guys are actually worse - they didn’t transform into villains over time; they started cheating us right from the beginning.
Bridges by themselves aren’t evil. Tools can’t be malicious; only people can. The real tragedy is that their creators are forcing clunky, vulnerable 2006-era centralized database mentalities onto modern decentralized ideas that were explicitly built to be free.
We tasted a brief feeling of freedom - the profound dream of what a truly digital, borderless world could give us. But instead of standing our ground, we fell for the shiny marketing, handed the keys right back to a new set of corporate gatekeepers, and cheered while doing it.
Rebellion Re-Born
These ideas, these warnings, and the sinking feeling that something is fundamentally wrong have been swirling around the space for years. The belief that this could be done has been burning inside our minds like a slow-burning fire, getting hotter day by day.
Maybe it’s just tech-fueled OCD kicking in, who knows? But watching the industry burn billions while chasing shiny trash makes it impossible to just sit still.
It was driving us absolutely crazy because, nobody could understand how to actually solve this cross-chain nightmare without turning back into the same old Judas-style centralized setups. But the engineering soul inside us was practically screaming: “The solution should be there!”
The initial part of the solution is dead simple: “Birds of a feather flock together.” We need our own blockchain to connect other blockchains.
The core riddle we had to solve was this: these validators, acting together as a single collective, need full control over the other side of the bridge - but never individually. No single rogue validator, no phished dev laptop, and no compromised Slack channel should ever be able to run away with your tokens.
But forcing a bunch of completely independent node operators to act like a single, tightly synchronized hive-mind across different networks is an absolute nightmare. By default, blockchains flat out refuse to talk to each other. They can use different elliptic curves, separate RPC configurations, and completely conflicting consensus engines.
To make this collective mind work across these hostile, isolated ecosystems, they need to speak a universal language. And what is the only thing that completely unites all blockchains?
Pure, unadulterated math.
Blockchains don’t care about corporate marketing, shiny UIs, or pinky promises. They care about cryptography. The ultimate tool for building this collective mind is digital signatures. But we aren’t talking about standard ECDSA.
We are talking about Schnorr Signatures.
Fun Lore: There is a legendary crypto myth that Satoshi Nakamoto actually wanted to use Schnorr signatures for Bitcoin originally. But the tech was locked down by an annoying math patent until late 2008. Satoshi couldn’t wait around for the patent office, so he rushed out with ECDSA instead. Talking about bad timing.
Ministry of Magic Approves: The “Illegal” Superpower of Linearity
But why are we obsessing over these signatures? Because Schnorr signatures possess a beautiful, almost illegal cryptographic superpower: Linearity.
In plain English? The sum of the individual Schnorr signatures equals the signature of the sum of the keys. With Schnorr, the validators can take their separate private keys, add them together mathematically, and generate a single, unified public key.
The result? A single, completely normal-looking signature that gets broadcasted to the network.
The destination blockchain has absolutely no idea a whole group was involved. It just sees one perfect signature, approves the transaction instantly, and charges you next to nothing for gas. It’s the ultimate cryptographic trench coat.
The Open Secret: Why Pay For What is Already Known?
For the curious readers who want to look smart at tech parties, here is how the Schnorr Signature math works. Grab a coffee - it’s actually beautiful in its simplicity.
G = The generator point on an elliptic curve (basically, a fixed mathematical starting point).
sk = Your secret key (a massive random scalar number, consist of 256 zeros and ones).
Shoutout to super-sophisticated crypto hardware wallets that charge $150 just to help you store what is essentially a 256-bit string of ones and zeros. It is truly an unsolvable computer-science problem to store 256 bits on a disk in 2026!
Example of a real, multi-billion-dollar master private key (this is the actual Sony PS3 root key that Geohot leaked):
0xc54553086da226a94ea2cee1aecef4b9e287edc106a1c1a073ca4cacecc492acSave it anywhere on your computer right now! Congratulations, you are now a co-owner of the Sony corporation wallet!
Pk = Your public key, derived by point multiplication sk * G
When you want to sign a message (m), you need to generate a one-time random secret number called a nonce (k)
- R = k * G (the public representation of that random nonce).
- e = hash(R || Pk || m) (this is called the challenge).
- s = k + e * sk (this is the actual signature scalar, REMEMBER THIS GUY - he is the star of the show).
The final signature you broadcast to the world is simply a pair of two numbers: (s, R).
The verifier doesn’t know your secret key (sk) or your secret nonce (k). They only have s, R, Pk, and the message m.
Verifier calculates the challenge e = hash(R || Pk || m) just like you did. Then he checks if both sides of this elliptic curve equation match:
Does s * G == R + e * Pk ?
s * G = (k + e * sk) * G
= (k * G) + (e * sk * G)
s * G = (k * G) + (e * sk * G)
s = k + e * sk
BOOM! Do you remember that s = k + e * sk guy from above? Yeah, he just balanced the whole equation! The math proves you know the secret key without ever revealing it.
Isn’t that elegant? If your brain is melting a bit, take a sip of coffee and look at it from a high level. While you process that, the knowledge train is departing for our next stop…
A Schnorr Song of Ice and Fire
Schnorr signatures are absolutely awesome. But we can’t just throw them into a decentralized bridge out-of-the-box. Why? Because really smart mathematicians found some nasty edge-case pitfalls.
Let’s just believe them. They are definitely smarter than the person writing this post. Instead, we have to upgrade our toolkit with two beautifully named protocols: FROST and its even cooler cousin, ROAST.
FROST (Flexible Round-Optimized Schnorr Threshold Signatures)
FROST is built purely on top of Schnorr signatures. In plain English, it lets a total number of participants (N, because it stands for Number) jointly control a single public key. However, it only requires a minimum threshold (T, because it stands for Threshold) to actually sign a message.
This is an absolute mathematical miracle! If you want a deep dive, go read the original academic paper. The authors deserve to be inducted into the Humanity Hall of Fame - they are absolute badass crypto wizards.
But for those who don’t want to read an academic paper (remember: don’t trust, verify… unless it involves 35 pages of dense math, then just trust me bro), here is how the magic happens in two rounds:
Round #1: The Prep:
- Each participant generates two secret numbers: a binding nonce and a hiding nonce.
- Participant converts them to public representations (multiplying them by our old friend G).
public_hiding_i = secret_hiding_i * G
public_binding_i = secret_binding_i * G
public_nonce_i = public_hiding_i || public_binding_i
- Participant sends these public nonces to a Coordinator (whatever they mean by that).
Round #2: Perfomance:
- The coordinator rounds up any group of participants that satisfies the threshold.
- The coordinator calculates a binding factor for every participating signer.
all_public_nonces = public_nonce_1 || public_nonce_2 || ... || public_nonce_t
p_i = hash(i || message || all_public_nonces)
- The coordinator sums up individual public nonces scaled by their respective binding factor.
R = ∑ (public_hiding_i + public_binding_i * p_i)
- The coordinator creates and broadcasts the challenge (e)
e = hash(R || GroupPublicKey || message)
- Each participant does their partial signing step:
l_i = Lagrange coefficient, will be covered later.
s_i = (hiding_secret + binding_secret * factor) + e * sk_i * l_i
- Everyone sends their partial signature back to the Coordinator.
- The Coordinator sums them all up into one final, standard Schnorr signature.
s = ∑ s_i
Boom! The output (R, s) is a perfect, vanilla Schnorr signature. Anyone verifying it on-chain will think it was signed by a single person using the group public key. No one will ever know it took a hidden council of wizards to forge it.
ROAST
FROST is brilliant, but it has a massive flaw. Once the Coordinator assigns participants to a signing session, nobody is allowed to leave.
This means a single malicious actor (or just an intern who tripped over a power cord) can completely block the protocol from reaching a successful signature. It’s a total bottleneck.
Enter ROAST. These guys had a genius idea: let’s run automated sub-sessions to make FROST bulletproof against lazy or evil participants. How it works:
- Instead of waiting around for slow pokes, the Coordinator maintains an active pool of available participants.
- The moment the Coordinator receives the minimum threshold (T stands for Threshold) of valid partial signatures from the fastest participants, it immediately aggregates the signature and broadcasts it.
- If a participant lags, acts malicious, or falls asleep, ROAST doesn’t get stuck waiting in the room with them. It instantly routes around them, logs their bad behavior (identifiable abort), and blacklists them from the next fast-path session.
- If a participant passed both steps of FROST, he could participate in a next signing session right away.
And that’s literally it! Don’t mistake this simplicity for weakness - the authors have ironclad mathematical proofs showing that this system cannot be broken.
FROST => ROAST => GHOST
Let’s talk about how this actually applies to our system. Because our blockchain acts as the Coordinator, we cannot afford massive, heavy computations in the runtime.
Mathematicians love doing their abstract “Esperanto magic” on paper, leaving us engineers to deal with the real-world fallout. Maybe some day they will become respectful and do the actual optimization work for us. Until then, we build.
The Problem with Pure FROST/ROAST
For the first round, everything is fine. Participants generate their nonces, send the public representations, and we store them cleanly in the ledger. We use a First-Come, First-Served rule: validators submit nonces until the session hits the threshold (if you remember T, stands for Threshold). If extra nonces show up late, they automatically spawn a new parallel session right away.
But then we hit the step where the “coordinator calculates the binding factor.”
Think about the sheer weight of that for a second. If we do this the academic way, during block prodction we should calculate a unique binding factor for each participant, plus group the nonces. Then each validator should recalculate it one more time to verify block inclusion.
It is an absolute computational disaster. We aren’t a massive AI data center with a couple of nuclear power plants sitting in our backyard. We want to be lightweight and blazingly fast!
Enter: The GHOST Round
It’s time for some clever optimizations. We are inserting a brand new Ghost Round right in the middle of the protocol.
Instead of forcing runtime to calculate everything, participants calculate them locally and send the group nonce along with a tight Merkle root of all binding factors. We then use hash of this root and group nonce as cryptographic keys to instantly split the nodes into distinct voting groups (remember, they are all locked in place for now).
By leveraging a simple consensus trick, we can confidently state that if more than 50% of a session’s participants vote for the exact same group nonce and Merkle root, the data is guaranteed to be valid.
Why is that mathematically safe? Let’s look at standard Byzantine Fault Tolerance (BFT) bounds:
Total Nodes in network = N
BFT Threshold (Honest Nodes needed) = (N * 2 / 3) + 1
Maximum Malicious Nodes Allowed = N - Threshold = (N / 3) - 1
Because the maximum number of bad actors can never exceed roughly 33% (N/3), they can never form a 50%+ majority on their own. If a group nonce gets more than half of the votes, it is mathematically impossible for that data to be a malicious lie. Honest nodes had to participate to cross that 50% line.
This idea came to the mind of the writer of this post, while he was staring down a slice of four-day-old pizza sitting on his counter. It was a complete psychological gamble. That is not important at all, just for the history.
The Final Handshake
Once the Ghost Round clears the path, the partial signing phase becomes a breeze.
When validators submit their partial signatures, they bundle it with the Merkle proof for their binding factor. The runtime quickly verifies it, accumulates the signature scalar s right away (since standard Schnorr math allows us to just sum them up linearly), and immediately releases those participants so they can jump into a brand-new signing session.
No wasted power.
The Hateful Eight
If you are tired, close your eyes and take a break. Walk away. Because this next chapter is going to melt your brain. If you think you’re strong enough to handle it, grab a massive cup of coffee. We are entering the danger zone.
In the previous steps, we built a beautiful, robust signing process. To actually use this for Bitcoin/UTXO chains, we have native Schnorr support. For Ethereum and EVM chains, we can pull off a clever ecrecover trick originally highlighted by Vitalik Buterin himself.
Everything looks perfect on paper. But then, the ultimate engineering nightmare slaps you in the face:
How on earth do these decentralized validators get a single, unified group public key in the first place?
Think about it. To have a group public key, someone usually needs to know the group secret key. If one centralized guy generates it, the whole Web3 promise is dead. If the validators try to share it, who do they trust?
And it gets worse. What happens when a validator gets bored and leaves the network? What happens when a shiny new validator joins the club? We need a protocol that can literally breathe - generating, updating, and rotating keys on the fly based on a constantly shifting number of participants. It has to be perfectly secure, completely decentralized, and mathematically bulletproof against rogue nodes trying to steal the master key.
The weight of this problem is enough to make a senior developer cry themselves to sleep.
Lord of The Keys: The Fellowship of the DKG (Distributed Key Generation)
The theoretical solution is DKG, specifically a protocol called GJKR (named after the brilliant mathematicians Gennaro, Jarecki, Krawczyk, and Rabin).
Once again: incredible mathematicians. But why, in the name of all that is holy, is it so abnormally hard for real-world engineers to implement their crazy ideas?!
Because of our specific blockchain environment limitations, our implementation requires eight brutal rounds of communication. Each one of these rounds was full of pure, unadulterated hate during the ideation and development phases. It took a piece of the soul from every single member of our team.
The rule of thumb: if during any round participants count fall below the threshold, restart it in any case!
Round #1: Bad Romance - Cryptography Poker Face
The main purpose of this round is to force every participant to lock in their hidden cryptographic commitments publicly without revealing them to anyone else. It’s the ultimate high-stakes game of cryptographic poker. The problem? Anyone can bluff and try to submit garbage data, so we have to force their hand onto the table right from the start.
Each authority node begins by generating its own secret share (a random 256-bit number; could literally be anything) to contribute to the upcoming master key. But that would be far too simple for an academic paper, wouldn’t it?
Instead of stopping there, the protocol demands that they generate even more secret numbers to generate SECRET FUNCTION! The total count of these secret coefficients must equal T (do you remember that T stands for Threshold?).
Now for the setup. Each validator looks up their specific index inside the current network era (which lasts at minimum 1 day).
With those pieces on the board, each node builds its own secret polynomial function:
f_i(x) = a_i0 + a_i1 * x + a_i2 * x^2 + ... + a_i(t-1) * x^(t-1)
F_i(x) = A_i0 + A_i1 * x + A_i2 * x^2 + ... + A_i(t-1) * x^(t-1)
# where
A_ik = a_ik * G
This set of public points forms their official VSS (Verifiable Secret Sharing) commitments.
The Ultimate Anti-Bluff: Zero-Knowledge Proof
Since we are professional players and not dupes, we can’t just leave them along and make them throw random math points into the runtime while hoping nobody notices.
To prevent rogue-key attacks (when a filthy cheater tries to impersonate an honest guy), each participant must also generate a Zero-Knowledge Proof (ZKP) - specifically, a discrete logarithm proof of knowledge.
Think of it as showing the tip of your cards without letting anyone see the faces: you prove to the entire network that you actually know the secret scalar corresponding to your first public commitment (A_i0), without revealing a single bit of the secret itself.
Participants broadcast this VSS package along with the ZKP straight to the network. You are officially all-in, your commitments are unchangeable, and your poker face is locked.
Catch-22: The 22MB State Bloat Disaster
If you implement this step exactly the way the academic papers describe it, you will kill your network before the first day ends. Let’s do some quick back-of-the-napkin math to expose the absolute horror of academic storage design:
- Total Participants: 1,000 nodes
- Threshold (T): 667 nodes (2/3 majority)
- Size per Public Coefficient: 33 bytes
- State Bloat per Authority: ~22 Kilobytes
- Total State Bloat: ~22 Megabytes
Now, consider that our maximum allowable block size is 5 Megabytes. If we store these commitments directly inside the globally replicated ledger state, a single DKG routine will completely choke the consensus mechanism, blow past the block size limits, and cause a total system meltdown.
To avoid this disaster, we pulled off a dirty engineering trick.
Instead of dumping all 22MB into the global ledger, we only register the tiny cryptographic fact that an authority successfully submitted their payload. The massive mountain of actual VSS commitments is completely stripped out of the ledger state.
Instead, it is routed straight into the local disk storage of nodes running with the --validator flag. It’s called the Offchain Index. Every validator processes the transaction, runs the validation logic, and saves the commitments locally in their own private database outside of the core chain state. The network stays lightweight, the block sizes stay small, and the academics can keep their 22MB ideas on paper.
Round #2: Along Came Polly - ChaCha20 & Salsa20
Now that everyone has locked in their public commitments, we need a way to securely pass secret data between validators without the rest of the world catching a sneak peek. It’s time to open up the dance floor and look at the cryptographic couple holding our privacy together.
This is where the Lagrange magic officially takes place. If you remember from earlier, I promised we would come back to this wizardry. Well, the time has come!
We are using Lagrange Interpolation now, which is a clever mathematical trick that gives you the ability to completely restore a hidden value out of a puzzle of many scattered pieces. To set this up, every validator takes their brilliant secret polynomial function from the poker table and computes f(i) for each individual participant, where i is the counterparty’s specific Lagrange index.
But right here is where the academic paper hits you with a massive catch. The researchers casually write: “This data should be sent over a secure peer-to-peer (P2P) channel between participants.”
Disgusting!
Secure P2P sounds amazing on a whiteboard. But what happens in reality when two validator nodes are stuck behind complex NAT setups, or shifting residential IP addresses and literally cannot establish a direct P2P connection? The entire DKG routine would instantly stall, and network freezes up.
To save the protocol from collapsing, we deployed another massive engineering workaround.
Since every validator’s long-term authority public key is already known to the network, we don’t need to pray that a raw P2P connection works. Instead of praying that a raw P2P connection works, we force the nodes to execute an ECDH (Elliptic-Curve Diffie-Hellman) key exchange straight through the network architecture.
But using them completely raw would be far too simple, right? It’s only the second round and we’ve already faced enough existential design challenges to last a lifetime. Instead of generic AES-GCM, we are using ChaCha20-Poly1305 to secure the payload. (See? I’m not crazy, they really do have these fun dance names!)
ChaCha20 - The Dance
ChaCha20 is responsible for turning your clear, readable text into unreadable digital noise.
- It takes a secret key and a starting number (called a nonce) and uses them to generate a massive, endless stream of completely random numbers.
- It then blends your original message with this random stream using a simple computer math trick (XOR).
- The result is pure gibberish. Only someone who has the exact same secret key can reverse this process and read the text.
- The number 20 means it scrambles the data in 20 distinct math rounds, making it incredibly secure against cracking.
Poly1305 - The Dancer
Just hiding data isn’t enough. A hacker could intercept the encrypted gibberish and change a few random bytes. To stop this, we bring in Poly1305, the ultimate cryptographic bouncer:
- Poly1305 creates a “Message Authentication Code” (MAC). It takes the gibberish produced by ChaCha20, processes it through a mathematical formula, and creates a unique 16-byte digital wax seal (the authentication tag).
- When the recipient gets the package, they check this seal first. If a hacker altered even a single bit of the encrypted message during transit, the seal instantly breaks, and the recipient throws the package away without opening it.
For a Dance, We Need Two People
This is awesome video that explains how ECDH works!
But assuming you have already graduated from kindergarten and don’t need crayons to understand simple math, the absolute shortest explanation:
Pk_1 = sk_1 * G
Pk_2 = sk_2 * G
S_1 = sk_1 * Pk_2 = sk_1 * sk_2 * G
S_2 = sk_2 * Pk_1 = sk_2 * sk_1 * G
# Because multiplication commutes perfectly on the curve:
S_1 == S_2
Boom! By simply multiplying my private key by your public key, and you multiplying your private key by my public key, we both land on the exact same collective key. No passwords were exchanged. No data was leaked. But we now have a completely private, un-hackable symmetric key that belongs only to the two of us. We can feed this secret right into the ChaCha20-Poly1305 machine, and start exchanging our private polynomial shares without a single soul on the outside understanding what we are saying. Finally store them in Offchain Index because each one should sent to each one and that is too much space for the ledger.
Round #3: Shake It Off - Haters Gonna Hate, Accusers Gonna Accuse
Only those authorities who successfully danced with each other in the previous rounds are allowed to step forward.
Let’s take a deep breath… That was a hard party. Some things went perfectly, but some things definitely did not. Everyone now holds a slightly different opinion of each other, which means it is officially time to start complaining, accusing, and pointing fingers!
We couldn’t actually verify on network layer whether the packages distributed in Round #2 were mathematically valid. Remember, they were wrapped up in an encrypted blanket using that fun dance-named algorithm. This is why Round #3 is mandatory for absolutely everybody. Every authority node wakes up, reads all the values sent to them over the past two rounds from the offchain index, and runs them through a cryptographic reality check.
Here is the local task list for each node:
- Decrypt the payload using your derived ECDH shared secret and the ChaCha20-Poly1305 engine.
- Verify that the decrypted value is actually true by matching it against the super cool public representations (VSS commitments) published all the way back at the poker table in Round #1.
Let’s look at a simple, non-boring math example of how a node verifies a share at Lagrange index 69 without knowing anyone’s private keys:
# The secret polynomial from Round #1 (hidden from you):
f_i(x) = 420 + 1337 * x
# The public VSS commitment from Round #1 (visible to everyone):
F_i(x) = (420 * G) + (1337 * G * x)
# Let's say your specific Lagrange index is 69.
# V = The secret scalar value the other node sent you in the encrypted package.
# You compute what the public curve point *should* look like:
Expected_Point = F_i(69) = (420 * G) + (1337 * G * 69) = (420 + 1337 * 69) * G
# Now you check it against the value (V) they secretly sent you:
Does V * G == Expected_Point?
Boom! You just checked if their secret math matches their public promises without them ever revealing their real sk to you, and without you revealing yours to them.
If the equation fails - or if a node sent you straight-up garbage - you are obligated to file a formal, public accusation against that authority on the ledger. You decrypt your files, run the computations, and compile a public blacklist of the nodes you want to burn.
Here is the tricky part: anyone can complaint on anyone without any reason, even if all the values they received were 100% correct. If you were just coding this blindly, you would be sweating bullets thinking that a malicious cartel of rogue nodes could just spam fake complaints against every honest participant to permanently freeze the network. But we are brave enough to go straight forward and completely ignore that fact!
Actually, we aren’t just being reckless - the paper explicitly highlights exactly why this is safe.
Round #4: Depp v. Heard - Justifications with Secrets Revealed
This is easily the dirtiest round of the entire protocol. Grab your popcorn, because it’s time to wash our dirty cryptocurrency laundry out in public.
As explicitly highlighted in the academic papers, if an authority is accused of lying or sending corrupt math, there is only one secure way to settle the dispute: they must completely expose their secrets to the rest of the world. The accused node is forced to broadcast the exact raw package they generated in Round #2 directly to the public completely unencrypted. It is the only possible way for the rest of the network to verify who is telling the truth and who is malicious.
To see how this courtroom drama unfolds, let’s look at a simple, three-party example featuring Alice, Bob, and Eve.
Eve publicly stands up and accuses Bob, claiming his math is garbage and moreover that he’s an awful dance partner. Alice is sitting on the jury and has no idea who is telling the truth. Bob is forced onto the stand to reveal his raw data.
Here are the three possible outcomes:
| # | Bob’s Action on the Stand | The Mathematical Verdict |
|---|---|---|
| 1 | Bob refuses to provide his raw share onto the ledger. | Guilty. Alice and the network are 100% sure Bob is malicious. He gets thrown into the trash immediately. |
| 2 | Bob provides the raw share, but the math is completely invalid. | Guilty. The ledger math exposes his corruption instantly. Bob is banned. |
| 3 | Bob provides the raw share, and the math is perfectly valid. | Confusing, but acceptable. Alice doesn’t know if Eve filed a fake complaint out of pure spite, or if Bob secretly changed his mind and patched the data. But it doesn’t matter: the math matches the original commitments, so Bob is cleared. |
Some Secrets should stay Secrets
If you looked closely at Outcome #3, your engineering alarm bells should be ringing violently.
Think about it: even if Bob clears his name by posting his raw share to the ledger, Eve now knows Bob’s exact secret share for her! In fact, everyone on the network can see it. It is out in the open.
Let’s do the math on why this is incredibly dangerous. In our 3-party example, let’s assume our security threshold is a strict 2-of-3 majority.
- Alice already received her own valid, private commitment over her encrypted channel from Eve during Round #2.
- Now, because of the public trial, Alice can look at the ledger and see Bob’s exposed share to Eve.
To prevent this existential nightmare, our protocol actively counts and tracks the exact number of leaked public shares inside the active session. If the count of exposed secrets reaches T - 1 (by the way, do you know that T stands for Threshold?), the protocol hits the big red panic button. We restart the entire DKG routine from scratch with a clean slate.
But if we survive the trial without hitting the panic limit? Congratulations. Every remaining authority node now holds every single piece of information they need about their peers - whether they like them or not. The foundation is poured.
Round #5: Vote or Die - Merkle Root of Verifying Shares & Group Verifying Key
Congratulations to all the participants still in the game! Those who failed to pass the gauntlet of the previous four rounds have been ruthlessly thrown off the board. Only the strong, the honest, and the mathematically pure remain.
If you look back at the original GJKR academic paper, the authors casually declare at this point: “And now, every participant seamlessly knows every other participant’s public shares and the overall group public key.” Isn’t that awesome?
Wrong!
As you vividly remember, we are cool engineering optimizers. We explicitly refused to store those massive mountains of VSS commitments directly on the global ledger to save our network from a 22MB database explosion. The blockchain doesn’t have a single piece of that data in its global runtime state.
This means the nodes cannot just look at the chain to find the answers. They have to do the heavy lifting themselves. During this phase, every single validator wakes up and locally computes the final Group Public Key (Y) and their own individual Public Verification Share (Y_j) using these definitive formulas:
# 1. The Group Public Key (Y):
# We linearly sum up the very first public VSS commitments (a_i0 * G)
# published by all the surviving, honest participants back in Round #1.
Y = ∑(A_i0)
# 2. The Individual Public Verification Share (Y_j) for participant j:
# We sum up the public representations of the secret polynomial evaluations.
#
# Variables explained:
# j : The target participant's ID.
# i : The participant index who generated the polynomial (Alice, Bob, Eve).
# k : The polynomial coefficient index (from 0 to t-1).
# A_ik : The public curve point commitment for node 'i' at coefficient 'k'.
Y_j = ∑_i ( ∑_k (j^k * A_ik) )
Because every honest node is executing the exact same math over the exact same set of verified, surviving participants, everyone on the planet should arrive at the exact same numbers.
So, let’s weaponize this fact to achieve consensus without uploading a single megabyte of raw math to the ledger.
Each validator takes the entire list of locally computed public verification shares, organizes them, and builds a local Merkle Tree. They extract the top Merkle Root hash and blend it cryptographically with the computed Group Public Key (Y). Instead of broadcasting their raw keys, validators simply broadcast this tiny, single hash to the ledger. The runtime automatically groups the nodes into voting chunks based on the hashes they submit.
If a specific hash reaches our strict threshold (the letter T… The name… Is The Threshold), the blockchain can confidently declare a mathematical victory: a threshold majority of independent nodes have successfully arrived at the exact same local cryptographic state, with 100% precision, without ever leaking or transmitting their underlying data across the open network.
And if the network fails to hit a majority consensus on a single hash? It means something went horribly wrong during the previous rounds, someone is feeding garbage data locally, or a desync occurred. The system immediately drops the hammer, wipes the session, and forces a total DKG restart. Vote correctly, or the session dies. If your vote will be on the wrong side you’ll be kicked.
Round #6: ProofBusters - We’re Ready to Believe You
At this point, a threshold majority of the network has raised their hands and publicly declared: “Hey, we all computed the exact same local state and the exact same Merkle root!”
That’s cool, guys. We hear you. But as hardheaded engineers, we don’t do pinky promises. We operate on a strict policy of “Don’t trust, verify.” It’s time to call the ProofBusters and force these nodes to put up or shut up.
We ask the majority to actually hand over the data they computed - but we do it in a highly optimized way to protect our precious storage. Instead of forcing every node to upload the entire world database, we distribute the weight. Each participant is required to upload only two highly specific things:
- Their own individual Public Verification Share (
Y_i). - A tight Merkle Proof showing that their specific share legally belongs to the winning consensus Merkle Root established in Round #5.
The blockchain runtime grabs this bundle and runs a quick, inexpensive cryptographic check. If your Merkle proof is flawlessly valid, the ledger opens up a small slot and stores your verification share cleanly inside your profile. If your proof fails, or if you try to submit a corrupted signature share? BUSTED. The runtime instantly identifies you as a filthy cheater, kicks your node off the board, absolute disrespect to those type of nodes.
Round #7: The Game of Thresholds - Rotate Authorities
At this point, it looks like we have slightly deviated from the original GJKR academic paper… by about 140%. But that’s totally fine. We passed the point of no return miles ago, and there is absolutely no way back now. It is time for the absolute heart of the protocol - a phase built for the brave of heart only.
Welcome to the ultimate power transition.
In this round, the previous set of authorities must come together and generate a collective cryptographic signature that officially abdicates their throne and rotates the network power into the new set of authorities.
To pull this off without a single point of failure, they have to use our ultra-robust, custom signing engine - the unholy (or holy, who knows) trinity of FROST, ROAST, and GHOST that we described earlier.
This is easily the most aggressive, cold-blooded part of the entire architecture. There are no escape hatches, no safety nets, and no manual overrides. It is an ideal state machine, or it is a smoking crater.
[Old Kings (Previous Authorities)]
│
🛡️ Custom FROST/ROAST/GHOST Signature
│
▼
[New Kings (Incoming Authorities)]
When You Play the Game of Thresholds…
In this game, your nodes either compute perfectly, or they die.
There is no room for politics. There are no “favorite” or “too-big-to-fail” authorities. The blockchain runtime does not care if a node belongs to a multi-billion-dollar VC fund or a bedroom hobbyist, no mercy to anyone. The protocol doesn’t stall; it doesn’t wait for human intervention; it doesn’t send a polite warning on Discord. It instantly executes the ultimate punishment: the entire DKG session is ruthlessly decapitated and restarted right back at Round #1. The network will literally force itself to burn to the ground and reset over and over again until it achieves absolute mathematical perfection.
Incorrect Numeration
Now, if you can still count after all this coffee, you’ll ask: “Hey VoidDragon, you called this section The Hateful Eight, but you only listed 7 rounds. Can you not do math either?”
Don’t look at me. Blame the pure academic mathematicians.
See, we originally built 7 rounds to be as close to the paper as possible. But then, we’ve found in the latest revision of the GJKR paper authors are saying: “Yeah, this is nice, but it’s not totally secure. If you do Round #1 right away, you leave the door wide open for malicious biasing.”
Let’s break down this theoretical nightmare. Imagine we have our classic trio: Alice, Bob, and a super-evil hacker named Eve. Alice and Bob are honest, so they immediately publish their blindfolded commitments during Round #1. Because Eve is a lagging villain with a fast internet connection, she gets to see their public data first. She can then secretly simulate the downstream math in her local memory and decide whether she even wants to participate in the DKG based on whether the final group public key favors her or not.
Is it a massive, immediate exploit that drains the treasury? Not exactly. But mathematicians live to lose sleep over abstract theoretical anomalies, so we had to bend to their crazy ideas to make the protocol truly unbreakable.
Ladies and gentlemen, please welcome:
Round #0: Silent Bob - The Chase it Better then the Catch
To stop Eve from manipulating the timeline, we introduced a rule straight out of a spy movie: Before you are allowed to send your official Round #1 commitment, you must first send a raw cryptographic hash of that commitment.
By doing this, Eve is completely blinded. She can see that Alice and Bob submitted something, but she has zero mathematical data to run simulations on. She is forced to lock in her own hash blindly. You are either fully committed to the game from the absolute start, or you are out.
The only thing that differentiates Round #0 from every other phase is how it handles the door. It starts with a completely empty guest list. Every valid hash registration results in an inclusion to the session. From Round #1 onwards, the door is permanently locked—future rounds only result in the exclusion of cheaters, while the honest survivors try to hold onto their seats for dear life.
The Hacker’s Delight: Bitmap Optimization
If you dive deep into our code to see how we track these surviving participants across the rounds, you won’t find a bloated, heavy array of strings or public keys. That would be an amateur database design.
Instead, we used a brilliant low-level trick inspired by the legendary book “Hacker’s Delight” (or maybe I read it somewhere else… whatever, it sounds cool).
Because a computer’s native brain computes everything in raw binary, an 8-bit memory slot is just a row of eight zeros and ones. We can weaponize this by using a Bitmap, where each individual bit index represents a specific authority node’s true/false status:
Let's say our network consists of Alice, Bob, Eve, Carol, and Dave.
Instead of storing their names, we map them to an 8-bit binary string:
11111000 (Binary) = 248 (Decimal)
Each 1 means that specific node is honest, active, and moving to the next round. If Eve gets caught cheating in the courtroom round, we don’t rewrite a database; we just flip her specific bit to a 0 at the hardware level. Need more than 8 participants? Just scale up to a 32-bit slot, or use an array of 32-bit integers to map an infinite number of validators with virtually zero memory overhead.
So, if you ever look at our runtime storage trying to figure out who is currently running the network, don’t be confused if you ask for the participant list and the machine simply spits back a bizarre, cryptic array like:
[69, 420, 1337, 1]
That isn’t a glitch. That is the optimized, hyper-compressed mathematical fingerprint of the survivors who just conquered the Hateful Eight.
Lights, camera, actions!
Great! We survived the Hateful Eight, the math is done, and the group public key is safely generated. But what do we actually do with it? How do we apply this group signature to the real world?
Act I: The EVM Puppet Master
To make this work on Ethereum and EVM chains, we have to pull off a brilliant hack. As we mentioned earlier, we abuse the native ecrecover precompile to trick EVM into verifying Schnorr signatures instead of its standard ECDSA signatures. Because of this, our smart contract exposes only one single public function: verify().
A Nerdy Side-Note: Because we are using the frost-core library from the Zcash Foundation, they use a specialized hashing mechanism known as hash2scalar (defined in RFC 9380). So if you open our solidity code and don’t see keccak256 or sha256 everywhere, do not panic. It’s just cryptographic magic working under the hood.
Every single transaction on our network must include a unique identifier called an exodus_session. This isn’t just a regular network nonce; it is a global, universal fingerprint for that specific action. There are exactly three types of transactions that can trigger this:
Bridge Out
This happens when you want to take your assets out into an EVM chain. Because the contract previously burned your ERC20 tokens and tracks the overall circulating supply (which we like to call the Ghosted Supply). For these messages, passing the chain_id is absolutely crucial to prevent malicious actors from pulling off double-spend replay attacks across different testnets and mainnets.
The Crypto Purgatory Escape Hatch
Picture this: You are trying to bridge your hard-earned tokens to a shiny new EVM chain. You hit “confirm,” and boom - the transaction fails because you have exactly 0.00000000 native coins for gas. Sounds familiar?
Enter the Bounty System, designed specifically for lazy chads.
If Alice wants to bridge 100 tokens but has zero gas, she can set a 5% bounty. She’s basically shouting: “I am financially irresponsible and willing to part with 5 of my precious tokens if someone just pays my gas for me!”
Bob, who actually remembers to keep gas in his wallet, sees this. He acts as the executor, uses his own native coins, and pushes her transaction through.
But why would anyone trust a stranger in Web3? They don’t. That’s where The Protocol Treasury steps in like a DeFi superhero.
Using its Risk-Free Value (RFV), the Treasury ensures nobody gets reked:
-
For Alice: She gets her tokens bridged safely to the destination chain without ever having to touch a centralized exchange for gas. She pays her 5-token laziness tax, but she’s happy.
-
For Bob: The Treasury takes care of him by swapping the gas fees he spent into protocol tokens at a massive discount, all subsidized by the RFV.
It’s a flawless, zero-brain-cells-required win-win. Alice bridges gasless, Bob buys protocol tokens on a ridiculous discount, and the Treasury keeps the ecosystem moving.
The Message Pack: exodus_session + amount + receiver_address + chain_id + bounty.
Governance
Once again, the chain_id is absolutely vital here. These transactions represent the heavy-duty management of our community treasury, protocol staking, reward distributor, and bond depository smart contracts.
But here is where we ran into a massive architectural paradox: we had to design a signed transaction that must be strictly verified by our core security layer, but at the very same time, it needs to execute a completely unverified arbitrary call on a totally different target contract.
To solve this mind-bending riddle without breaking the laws of EVM physics, we had to pull off a delightfully unhinged engineering trick. We put a function call inside another function call, chained them together like a cryptographic human centipede, and signed the whole unholy beast as one single chunk.
The Outer Message Pack: exodus_session + chain_id + target_address + encoded_abi_call
Rotation
For this type of exodus transactions, chain_id doesn’t matter at all. This is a global broadcast signaling that our public key has been rotated. It must be applied to every single external network running on the same elliptic curve (secp256k1, ed25519, etc).
The Message Pack: exodus_session + public_key (a clean, compressed 32-byte key) + parity (a 1-byte field tracking whether the key is even or odd, because Solidity is too stubborn to hold a native compressed key in a single 32-byte slot).
How the Contract Executes Itself
When a message hits verify(), the contract validates the Schnorr signature and checks if that specific exodus_session has already been executed. If it’s fresh, the contract performs a neat trick: it dispatches a internal calldata message to itself. It literally triggers one of those three guarded, only-self functions from within its own code.
Uroboros
What happens if our gatekeeper smart contract needs a major upgrade? How do we replace it without losing our entire history?
Our solution behaves like uroboros, a snake eating its own tail - a Linked List of Smart Contracts.
Every single time a new gatekeeper contract is deployed, it must be initialized. During this phase, the staking contract forces the newly deployed gatekeeper to point directly to its ancestral predecessor, while the older contract is updated to point forward to the new one.
If you forget about a signature and show up 5 years later trying to claim your tokens on a legacy contract, the current gatekeeper will look at your session ID, realize it belongs to an ancestor, and cleanly pass the verification request down the chain until it reaches the correct historic contract. Robustness is absolutely everything.
Act II: The UTXO Wilderness (Bitcoin Execution Layer)
Executing this on UTXO chains like Bitcoin is a completely different beast. In theory, it sounds much simpler: we just need to sign a standard transaction to move the group funds. In reality, it is significantly harder.
Because of how UTXO data structures work, to build a valid transaction, you cannot just check a single balance variable. You have to actively gather every single unspent transaction input (txin).
To do this out-of-the-box, the protocol currently has to call heavy node operations like listunspent or scantxoutset. And that means every single validator in our network would be forced to run and maintain a massive, resource-heavy full Bitcoin node.
Let’s be honest: that is an engineering bottleneck, and it is definitely not an elegant, lightweight solution.
This is the very last open issue we are tackling to make EXODUS completely seamless out-of-the-box. We want our validator nodes to stay lightweight and efficient.
Final Thoughts: The Odyssey Continues
We are incredibly proud to stand here today and say it: we have officially cracked the code to make cross-chain exchanges purely decentralized, mathematically unassailable, and exceptionally secure. Huge shoutout to the brilliant mathematicians who laid the groundwork (though, let’s be honest, we all wish they would write their papers in direct, developer-friendly English).
The best part? This entire machine doesn’t require a massive server farm or a dedicated nuclear plant. It runs beautifully on standard, affordable hardware. No gatekeepers, no centralized storage, no corporate gaslighting. Don’t trust, don’t believe - just verify.
The dream of a fully decentralized, united Web3 world that once lived entirely in our heads is now tangible, running reality.
To all the ghosties who supported us: thank you. Taking this project from a sketchy Python script with a couple of lines of messy code to a full-fledged production protocol pushing ~30,000 lines was a wild, exhausting journey.
Honestly, it feels like our own technical Iliad and Odyssey. We haven’t reached home yet, but Troy has officially fallen. We did something massive together.
But this is just the end of the first book. Our journey into the next chapter is already beginning. Keep your eyes peeled, ghosties - we are seeing this through to the absolute end, whatever it takes and at any cost. While the industry is shifting toward the dark side, desperately trying to sell everyone the lie that true privacy is dangerous and freedom is bad, we are moving in the exact opposite direction. We are heading straight toward where the hearts of the people are pointing - toward absolute freedom, digital sovereignty, and radical liberty. The real fun is just getting started.
In case I don’t see ya, good afternoon, good evening, and good night!
