A real $116 million reason to care about this distinction
In October 2022, Avraham Eisenberg pumped the price of MNGO across the handful of exchanges feeding Mango Markets' oracle, then borrowed roughly $110 million against the inflated paper value. The contract code wasn't buggy. The price it trusted was thin enough for one well-funded trader to move directly.
That single incident is the cleanest real-world argument for why "decentralized oracle network" can't just mean "more than one address agreeing on something." A 3-of-5 multisig is also more than one address agreeing on something, and it would have done nothing to stop Mango. The architecture underneath a DON has to do real work, not just add signatures.
This distinction matters beyond the theory. If you're auditing smart contracts, reviewing an integration, or just trying to evaluate whether a protocol's price feed is actually safe, "it uses a decentralized oracle" is not an answer. It's a claim that needs checking. Plenty of protocols that called themselves decentralized in 2021 and 2022 turned out to be running the equivalent of a multisig with extra branding, and several of them got drained because of it.
This is day 3 of a 28-day series going through Chainlink's full architecture. Today: what actually makes a Decentralized Oracle Network structurally different from a multisig, why that difference is exactly what an auditor should be checking for, and where multisigs genuinely do show up in Chainlink's own design, just not where most people assume.
Why "more signatures" isn't the same as "more security"
A multisig is a coordination tool. A fixed set of known signers each hold a key, and a transaction executes once enough of them approve it. That's useful for treasury management and contract upgrades, where you genuinely want a small, accountable group making a deliberate decision. It is not, on its own, an oracle, and it was never designed to be one.
Here's the gap: a multisig says nothing about where the data being signed came from. If five signers all pull their number from the same single API, you have five signatures and one source. Compromise that one source (or just have it go down, or have it be wrong) and all five signers happily approve the same bad number, because from their point of view, nothing looks wrong. The multisig adds friction to changing the data once it's recorded. It adds nothing to verifying the data was right in the first place. Those are not the same job, even though they look similar on a block explorer.
This is the actual distinction:
- A multisig verifies that enough people agreed to do something
- A DON verifies that enough independent sources, fetched independently, by independent operators arrived at the same answer
Those are different security properties, and only one of them resists the Mango-style attack. A multisig with the best possible signers in the world still inherits whatever data those signers were looking at. If that data was manipulable, more signatures on top of it changes nothing about the underlying vulnerability.
The three layers a Chainlink Price Feed actually runs through
Here's where it gets concrete. A Chainlink Data Feed doesn't just have "many nodes." It has three separate, stacked layers of independence, and an attacker has to break all three simultaneously to move the final number.
Layer 1: Data source aggregators
Raw price data starts at centralized exchanges (Coinbase, Binance) and decentralized exchange protocols (Uniswap). Premium data aggregators then pull from across all of these, weighting by volume and liquidity, filtering fake exchange volume, and removing outliers, before a Chainlink node ever sees a number.
This layer alone already defeats a huge class of naive attacks, like the Mango exploit, where the whole problem was a single thin venue standing in as "the price."
Layer 2: Per-node median
Each individual node operator doesn't just pick one aggregator and trust it. Node operators source price data from multiple independent data aggregators and take the median between them, which protects against any single aggregator having downtime or a bad data point.
Layer 3: DON-wide median
A typical ETH/USD feed runs with around 21 independent node operators, each running separate infrastructure, querying separate data providers. Each node submits its own answer, and an aggregation contract discards statistical outliers and computes the median across all of them.
The math that matters: a single bad actor submitting a wildly wrong number barely moves the final median if 20 other nodes report correctly. To meaningfully move the feed, an attacker needs to compromise a real fraction of independent operators, running independent infrastructure, pulling from independent sources, all at the same time.
Where multisigs actually do show up in Chainlink's architecture
Here's the nuance worth getting right, because it's easy to overstate this comparison. Multisigs aren't absent from Chainlink's design. They show up at a different layer entirely: governance, not consensus.
Two concrete places:
Onchain parameter updates. When a feed needs a faulty node replaced, or a new feature like OCR rolled out, that change goes through a multisig-coordinated process. This is slow and deliberate on purpose, balancing collusion-resistance against the flexibility to actually fix things.
Operator contract ownership. Forwarder contracts (the contracts that let a node operator manage multiple wallets) distinguish between an owner account, typically secured by a hardware wallet or multisig, and authorized sender accounts, which are the hot wallets nodes actually use day to day to sign fulfillment transactions. If a node's hot wallet gets compromised, the owner address (the multisig) is what revokes it from the authorized senders list.
So the accurate version of this distinction isn't "Chainlink doesn't use multisigs." It's: the multisig protects the keys that govern the system. The three-layer median protects the data the system reports. Conflating those two is exactly the kind of detail that separates a careful audit from a surface-level one.
A worked example: what it actually takes to move a feed
Numbers make this concrete. Say a feed runs 21 node operators, and the aggregation contract takes the median of all submissions, discarding clear outliers first.
To meaningfully shift that median, an attacker doesn't need to compromise one node. They need to compromise enough nodes that their manipulated values stop looking like outliers and start dragging the actual middle of the distribution. With 21 independent operators, that's a real fraction of the network, not one server, not one signer, not one thin market.
Now compare that to the Mango setup: one effective price source, manipulable by anyone with enough capital to move that specific market for a few minutes. The attacker didn't need to compromise 11 of 21 independent operators. They needed to move one venue. That's the entire difference in a sentence: a real DON forces an attacker to defeat a distribution, not a destination.
This is also why per-node and per-source independence both matter, not just node count. Twenty-one nodes that all pull from the same single underlying aggregator are not meaningfully more decentralized than one node, because compromising that one shared upstream source compromises all twenty-one simultaneously. The number of nodes is the headline. The independence of what feeds each node is the part that actually does the security work.
A checklist for anything you're reviewing that consumes price data
If you're auditing a contract that reads from any oracle, Chainlink or otherwise, here's what's actually worth checking:
- How many independent node operators back this feed, and how many independent data sources feed each one? A "DON" with 3 nodes all pulling from the same aggregator is architecturally closer to a multisig than a real decentralized feed.
- Is the aggregation a median, or something else? Median is resistant to a single bad submission. A naive average is not, one wildly wrong number can drag a mean significantly.
-
Does the consuming contract check
updatedAt, or just trust whateverlatestRoundData()returns? A perfectly decentralized feed that goes stale and gets read anyway is still an exploitable bug, just a different one than Mango's. - Where does governance sit? If a multisig can swap out the entire node set or change the aggregation logic with no time delay, that multisig is now your actual trust assumption, separate from whatever the DON itself guarantees day to day.
The takeaway: decentralization isn't a label, it's a measurable property of how many genuinely independent failure points an attacker has to compromise at once. A DON earns that label through three stacked layers of independent sourcing and median aggregation. A multisig, no matter how many signers it has, never claims to do that job, and shouldn't be evaluated as if it does.
I'm a smart contract security researcher writing through Chainlink's full architecture, from the node layer up to the Chainlink Runtime Environment. Follow along at ramprasadgoud.dev or on X @0xramprasad.
Top comments (0)