Teller protocol cover,
coverage and gaps.
The team buys one cover for everyone using the listed contracts. It pays on a hack of exactly those contracts, minus 5% of the cover amount, and the payout has to be passed on to users or the cover is void.
Teller is a lending protocol built around an open order-book model, where lenders set their own criteria and commit capital to markets rather than relying on a single pooled rate. Nexus lists a Native Protocol Cover for it: the product type where the team buys one cover and its users are the protected party, with the wording obliging the team to pass a recovery on. This is currently the only active listing of that type on Nexus. Its annex is the most precise in the whole set: it names each covered contract and pins them to a specific GitHub commit. This analysis reads that annex and checks the fit. Facts, not advice.
Who this is for: The Teller team, protecting its USERS (lenders and borrowers on the covered contracts) against a smart contract failure
The strongest structure for users in the entire team family, and the one with the sharpest edges. Two things set it apart. First, the base wording does the work no annex can: clause 10.12 makes the recovery the users property, so a team keeping the payout voids the cover, and the proof of loss shifts from per-wallet signatures to a team post-mortem, which is what actually happens after an exploit. Second, the annex is unusually rigorous: it lists every covered contract by name and pins the covered version to GitHub commit 38c87ae, and states that the cover cannot be applied in part or whole to any contract outside that list. That is verifiable scope, which is rare. The same rigour is the risk. A pinned commit ages: any contract deployed or upgraded after it, and any market or peripheral contract not on the list, is outside the cover, and a lending protocol is a moving target. Add clause 10.11, which excludes losses caused by the team using its own admin controls, including pausing, and you have a cover that is excellent against the clean case (a bug in a listed contract at the pinned version) and thin against the messy one (an incident spanning newer code, or one where the team intervenes to limit damage). At a fixed 4.05% per year with a 5% deductible, it is also the most expensive of the four team listings, which fits the peril but should be a conscious decision.
How to read this page: where each value comes from
Only on-chain values are verifiable without trusting anyone. Everything off-chain, including binding documents, ultimately relies on trust in the source.
Live on-chain On-chain
Reading the chain…
Profile
A pinned commit is the best and the most brittle scope definition there is: Most cover wordings describe the covered system in prose, which leaves room to argue after an incident. This annex does the opposite: it names nine contracts and fixes their covered version to a single commit hash, and it says explicitly that the cover cannot be extended in part or in whole to anything outside that list. Anyone can verify the scope in an afternoon, and after an exploit there is little to dispute about whether the affected contract was in it. The cost of that precision is that the protocol keeps moving and the commit does not. A contract redeployed after an upgrade, a new market, a peripheral helper, a fix shipped in response to an audit: each one sits outside the pinned version unless the annex is updated. So the question to ask about this cover is never just "is there cover", it is "does the deployed code still match the commit the cover was written against".
What is covered Contract doc
The Native Protocol Cover wording plus the Teller annex. The covered event is a loss of user funds caused by a failure of the listed contracts at the pinned version, above a deductible of 5% of the cover amount.
Pick what you actually want protection from; the list below highlights your answer. Runs in your browser only, nothing is sent.
Even "covered" is not a payment guarantee: every claim is decided by the mutual's members (claims assessors). A risk not listed here is most likely not part of the wording at all. No advice.
Pick your risks above and only those appear here, with the verdict: covered or not.
Conditions attached Contract doc
Who decides on claims Provider claim
Same core process as every Nexus claim (Claims Committee, assessor voting), but the Native Protocol Cover type changes the practical part: the proof of loss is a team post-mortem with transaction references rather than per-wallet cryptographic evidence, which is far more workable after a protocol-wide exploit. The pinned contract list also narrows what has to be argued: whether the failing contract was in scope is close to a factual question here rather than an interpretive one. No Teller claim is on record.
Assecura Score Our assessment
A structured assessment across seven categories, 0 to 100 points in total. The score is an opinion based on the sources below, not a probability of payout and not a guarantee.
Note: this product is bought by a protocol team, not by end users. We therefore score it with our team rubric, which asks the questions a team asks. The most important one: if disaster strikes, does the money actually reach the users? Compare this score only with other team products, not with the retail list.
The premium is the underwriters price verdict: mainly how likely a claim is. The Assecura score measures how good the cover is: fit, clarity, capital, claims. Where they diverge, look twice.
The best scope definition in the set: nine contracts named individually, the covered version pinned to a commit hash, and an explicit statement that nothing outside the list is covered. Anyone can verify it. Deduction: the pinned commit ages with every upgrade, and the annex does not say how or whether it is refreshed.
Same shared pool as the provider profile, on-chain verifiable, live above. Better spread than the slashing umbrellas: capacity is drawn from five staking pools rather than one, so a payout does not depend on a single pool manager.
The best incident fit of any team product here: one cover for all users, post-mortem-based proof of loss instead of per-wallet signatures, and a scope so precise that the in-or-out question is largely factual. Minus: untested, and clause 10.11 penalises exactly the intervention an incident calls for.
The builder question: does the payout reach the protocol users? Clause 10.12 answers it structurally, and this is the only listing in the live team set where that is true: the recovery must be intended for the users or the cover is void, so the team is a trustee, not the owner. Deduction: how distribution works in practice and who verifies it is untested.
Nexus side unchanged. Team side: the same admin controls that make 10.11 bite are also what a team needs to respond to an attack, so the wording puts the team in a conflict at the worst possible moment. Whether the annex is kept current after upgrades is likewise entirely the team decision.
Discretionary cover, no enforceable claim: identical to the provider profile. For teams the 10.12 void condition adds a further way to lose the cover entirely.
The strongest here: the annex is public, the covered contracts are named, the version is a verifiable commit, and the active cover amount is visible via the Nexus API. Reduced because a user still cannot see whether the deployed code matches the pinned commit today, which is the fact that decides whether the cover applies.
Red flags Our assessment
Clause 10.11 excludes losses caused by the team using its own admin controls, including pausing: the standard incident response can put the loss outside the cover.
The covered version is pinned to commit 38c87ae: contracts upgraded or deployed after it are not covered unless the annex is refreshed, and nothing surfaces that state to users.
Bad debt is not covered: the everyday risk of a lending protocol, a borrower defaulting or collateral falling short, is credit risk and stays with the lender.
Payout remains discretionary: the loss is decided by assessor voting, so the provider-level warning applies unchanged.
Clause 10.12 voids the cover if the recovery is not intended for the users: strong protection for users, and a real way for a team to lose everything by mishandling the payout.
Most expensive of the four team listings at a fixed 4.05% per year plus a 5% deductible: the cost of covering active smart contract risk rather than a rare tail event.
Open questions Our assessment
Points this analysis could not verify. Anyone buying significant cover should clarify these first.
- Does the currently deployed Teller code still match commit 38c87ae for all nine listed contracts? This is the single most decision-relevant fact about the cover and it is not visible from the listing.
- Is cover currently purchased, and for how much? On a team product the bought amount, not the offered capacity, is what protects users.
- How is a payout distributed to lenders and borrowers in practice, and who verifies that it reached them (the 10.12 condition)?
- Where exactly is the line under clause 10.11 between a team pausing to stop an attack and a team causing the loss? The wording does not carve out defensive action.
Sources
- Nexus API: Teller listing (productId 406, Native Protocol Cover, private, fixed-price)
- Nexus API: live capacity (productId 406)
- Teller Native Protocol Cover Annex (IPFS, PDF): 5% deductible, designated contracts, commit 38c87ae
- Teller Protocol v2 (GitHub repository: the contracts named in the annex)
- Teller documentation: lenders and commitments in TellerV2
- Teller V2 loan analytics (Dune)
- Assecura product analysis: Native Protocol Cover (the underlying wording, clauses 10.11 and 10.12)
- Assecura provider profile: Nexus Mutual
Analysis as of 2026-07-19. Live figures update every 5 minutes from the contracts. Not affiliated with Native Protocol Cover: Teller. Informational only, no legal, investment or insurance advice.