Protocol
Not one program but many - and that is the point
What is it?
A single smart contract can do little. An application you actually do something with is made of several.
One holds the deposits. One calculates the interest. One fetches prices from an oracle. One governs who may change things. Together they make an application that gets a name - and that name is what users know.
But the name is not an address. It is a brand over a set of contracts that can be changed, replaced and broken one at a time.
An example
A lending application typically consists of one contract per token, one for the interest logic, one for the price feed and one for administration. Anyone who “has money with the protocol” strictly speaking has it in one particular one of those contracts.
If a different one of those contracts is exploited, that can still reach your own deposit - or it may not. It depends which one it was.
Where does a risk come from?
| The attack surface is larger than it looks | It is not one contract that has to be flawless but all those that interact. And their interaction itself can be faulty even though each one is right on its own. |
|---|---|
| Protocols build on each other | One application often uses another. If the lower one fails, the upper one falls with it - though you may never have heard its name. |
| Parts can be swapped out | Some protocols can replace individual contracts. What was audited today need not be the same code tomorrow. |
Why this matters for cover
Because a cover covers contracts, not brands.
A product with a protocol’s name in its title usually covers particular contracts named in the wording - rarely all of them. Anyone holding a deposit in a contract that is not listed there is not the one meant when it matters.
That is why the first question to put to any wording is: which addresses exactly?
Where this leads
-
What happens when one of those contracts has a flaw.
-
What people actually do with such protocols.