Decentralised News · Editorial by Heath Muchena · Evidence reviewed 12 November 2026 · Edition 1.0
What Matters
A DeFi cover limit is not the amount a loss will produce. The applicable wording, annex, remaining limit, recoveries, deductible and filing dates all matter. Nexus Mutual’s current Protocol Cover terms provide a concrete example. DN’s local calculator reproduces specified arithmetic and timing assumptions while leaving event eligibility, membership, evidence and discretionary assessment unresolved.
DN Evidence Block
- Source review
- 12 November 2026.
- Primary wording
- Nexus Mutual Protocol Cover Terms and Conditions, content-addressed document linked by its current cover-wordings directory. Annexes and the member’s actual cover record must also be read.
- DN instrument
- DN DeFi Cover Amount and Filing Window v1.0.0, using explicit reader-entered dates, amounts and rounding.
- Evidence class
- Public product terms and process documentation; no issued cover, quote or claim was tested.
- Boundary
- No payout promise, claim-approval verdict, agent-specific pool ranking or measured claims-success rate.
The useful question is what this cover can respond to
An agent can lose money by approving a bad trade, signing a malicious instruction, using a broken protocol or continuing after an oracle problem. Calling all four incidents an agent failure does not identify the contractual event. A cover purchase needs to connect a particular position and loss mechanism to a particular promise.
Nexus Mutual is a useful case study because its public materials expose both the product wording and the filing process. Its membership documentation describes a discretionary mutual, with identity checks and jurisdictional restrictions. That is a specific arrangement; the article does not treat it as a universal description of insurance or verify any reader’s eligibility. [1]
DN’s thesis is that a cover record should travel with the position it is intended to protect. Preserve the product version, annex, relevant wallets, accounting unit and dates before a loss. An autonomous strategy should not be able to make those facts disappear when it moves an asset, rotates a key or changes a deployment.
Start with the wording and its annex
Nexus’s directory links the same Protocol Cover document for Single and Multi Protocol Cover. The retrieved content identifier is QmQQ88vaZkgEY9qXKPtq7Se6caSjB2RTqF1GAnBLW1k8EY. This is a reproducible reference to the reviewed document, not proof that it governs every purchase. The directory itself tells readers to use the wording attached to their product. [2]
The reviewed terms make the annex controlling where it conflicts with the main text. Their defaults include a 14-day event cooldown, a 35-day post-expiry filing grace period and a deductible of 5% of the cover amount. Individual arrangements can change relevant terms. [3]
Save the reference actually supplied at purchase, together with any later amendment. A current website can help explain a product while a historical purchase depends on a different document. The comparison must therefore identify both document version and position date.
Claim versus data: five distinctions to preserve
| Shortcut | What the evidence requires | Practical consequence |
|---|---|---|
| The limit is my likely payout. | Amount calculations, prior use of the limit and the applicable conditions remain relevant. | Keep original and remaining cover amounts separate. |
| The agent lost funds, so the event is covered. | The cause must fit the specified event and survive exclusions. | Describe the transaction and mechanism before applying a product label. |
| I can file whenever the loss is discovered. | Product-specific timing conditions apply. | Record event, expiry and filing dates independently. |
| A token proves that every wallet in my strategy is protected. | Relevant ownership and position evidence still need examination. | Keep a wallet and position history tied to the cover record. |
| A calculated amount is an accepted claim. | Assessment is a separate process. | Label arithmetic as a scenario, with approval undetermined. |
The deductible has a base, not just a percentage
Nexus’s public DeFi-cover explanation describes the Protocol Cover deductible as a portion of the cover amount, rather than a percentage of every loss. It also explains that recoveries from elsewhere reduce the amount claimed. These details are easy to miss when a buyer looks only at a percentage or a headline limit. [4]
For a hypothetical position, suppose the original cover amount is 100,000 USDC, the remaining amount is also 100,000, the assessed loss input is 30,000 and other reimbursements are 5,000. Applying a 5% cover-amount deductible produces a deduction of 5,000. The illustrative amount after reimbursements and deductible is 20,000, below the remaining limit.
If the remaining limit were 12,000, the same arithmetic would cap the scenario at 12,000. It would not recompute the deductible as 5% of 12,000. If the loss input were 4,000 with no recoveries, the scenario would floor at zero. These are calculations from explicit assumptions, not examples of approved claims.
The reviewed terms calculate the requested amount using loss after reimbursements, less the deductible, capped at remaining cover. [3] The calculator exposes that order so a reader can identify an incorrect base or a double-counted recovery.
A filing window can begin after the cover expires
Consider another hypothetical record: cover begins at 00:00 UTC on 1 October 2026 and ends at 00:00 UTC on 1 November. An event occurs at 12:00 UTC on 20 October. With the entered 14-day cooldown, the calculated earliest filing point is 12:00 UTC on 3 November. With a 35-day grace period, the planning cutoff is 00:00 UTC on 6 December.
The sequence explains why the event date and filing date should not be conflated. The event can sit within the entered cover period even when the modeled filing opportunity opens later. Conversely, increasing a cooldown or shortening a grace period can leave little or no overlap. A dashboard showing only an expiry date hides that relationship.
Nexus’s filing guide tells readers to check the relevant cooldown, grace period and loss conditions before submitting. It also provides a route to ask the Claims Committee about the record. [5] A calculator should support that preparation rather than tell someone to file or wait solely because a screen changes colour.
Use the DN DeFi Cover Amount and Filing Window
Copy the actual parameters from the applicable documents. Enter all amounts in one accounting unit and choose its precision and the assumed rounding rule. The example uses two decimal places for readability; this is not an assertion about a token’s native precision or a product’s rounding convention.
DN DeFi Cover Amount and Filing Window v1.0.0
Entered formula and UTC planning conventions only. Eligibility, annexes, valuation, sublimits, material-loss tests and discretionary claim approval remain undetermined.
Use non-sensitive aliases and references. This instrument makes no network requests and writes no browser storage. The downloaded JSON contains your inputs. Do not enter account credentials, wallet secrets or confidential documents. Defaults are illustrative scenarios.
Enter or review the example assumptions, then calculate. No measurement or live data has been loaded.
The output separates monetary arithmetic, event placement and filing-window placement. A positive amount can coexist with an event outside the entered period or an expired planning window. Coverage and claim approval remain undetermined in every result.
Agent mistakes and protocol failures need different evidence
The reviewed Protocol Cover includes specified code failures and defined economic events. It excludes, among other things, certain key-compromise and interface losses where the protocol operates as intended. It also sets ownership-evidence conditions around impacted accounts and post-event cover-NFT transfers. [3]
An analyst should therefore reconstruct a sequence rather than provide a single label: what was authorised, which address acted, what the contract did, which account lost funds and what the operator changed afterwards. That record can expose an unresolved factual question without pretending to answer the legal or discretionary coverage question.
For an automated strategy, preserve position identifiers through account rotation and asset migration. Record when the change happened and which person or organisation controlled each relevant address. Do not assume that convenient operational grouping makes every address equivalent for cover purposes.
DN’s broader AI agent insurance question map addresses business loss, customer liability and performance promises. This article adds a narrower product-terms case study; it does not replace that wider insurance discussion.
The claim clock has later stages too
Nexus’s process documentation describes assessment by its Claims Committee, with some products using a designated assessor. The current process includes voting, a subsequent challenge cooldown and a separate redemption period. Those are distinct from the event-to-filing cooldown in the product wording. [6]
The filing guide currently specifies a 0.05 ETH submission deposit and different treatment for accepted, drawn and denied outcomes. It also requires incident information, proof of loss and a stated amount. [5] These are operational requirements to verify in the live process, not a fee or outcome assumed by DN’s amount model.
The instrument stops before those stages. It neither adds the filing deposit to a possible recovery nor predicts voting, transaction costs or payment timing. Combining all clocks into one deadline would produce a more impressive-looking dashboard and a less reliable decision.
Read a changed strategy against the original cover record
Imagine that an agent starts in one covered position, then moves into a wrapper, changes chains and rotates its operational account. The initial purchase receipt may still exist. The relevant question is whether its documented scope and evidence continue to describe the position actually held.
Nexus’s buying guide directs readers to the product’s covered events, exclusions, deductible and grace period. It distinguishes the listing and annex from a generic product description. [7] Treat a strategy change as a reason to recheck those documents, not as automatic evidence that protection survives or disappears.
For internal approval, keep the investment decision and the protection decision separate. A token holder’s economic rights need their own analysis, as in DN’s agent-token payout-rights review. A cover instrument does not create an underlying ownership or cash-flow right.
Decision table for a useful handover
| Finding | Next action |
|---|---|
| The wording or annex is missing. | Retrieve the applicable documents before relying on the displayed parameters. |
| The deductible base is ambiguous. | Obtain clarification; do not silently use remaining cover or loss as the base. |
| Wallet continuity is unresolved. | Preserve the address-control and transfer chronology for assessment. |
| The modeled event lies outside the entered period. | Check source dates and applicable terms rather than interpreting the calculated amount as protection. |
| The modeled filing interval has no overlap. | Verify every timing rule with the provider promptly. |
| The arithmetic is positive and the date falls inside the interval. | Continue the factual and wording review; approval remains undetermined. |
Methodology and limits
DN reviewed the public materials on 12 November 2026. The original agent-specific pool-depth proposal remains unsupported: these sources do not establish a measured market of dedicated agent pools. The contribution here is a reproducible interpretation aid for a specified set of inputs.
Money uses integer smallest-unit arithmetic, including explicit down, nearest or up rounding of the entered deductible rate. The model floors the amount at zero and caps it at the remaining amount. It does not value a loss, determine a material-loss threshold, assess sublimits, interpret other recoveries or apply an annex automatically.
Times are explicit UTC instants. A modeled day is exactly 24 hours. The event interval includes the start and excludes the end. The filing interval includes its calculated opening and conservatively excludes its deadline. These are disclosed planning conventions, not legal interpretations of an individual deadline. They must be reconciled with the actual terms and provider guidance.
Frequently asked questions
Does a positive result mean Nexus Mutual will pay?
No. It establishes arithmetic from entered assumptions. Eligibility, causation, evidence, exclusions, annex conditions and discretionary assessment remain unresolved.
Can I use a different cover product?
Only if its relevant amount formula matches this model and its dates are entered correctly. A different formula or event definition needs a different analysis. The tool does not import policy documents.
Why distinguish original and remaining cover?
They have different roles in this model: one sets the percentage-based deductible amount; the other caps the scenario after prior use of the limit.
Does the calculator value tokens or obtain a quote?
No. Supply consistently valued amounts in the same unit. It makes no market-data requests and cannot determine the price or valuation time required by a claim.
Can an AI agent be treated as the member?
This article does not establish that. Identify the eligible individual or entity, the controlled addresses and the applicable membership requirements rather than inferring legal status from software autonomy.
Are protocol TVL and cover capacity interchangeable?
No. An amount held in a protocol does not, by itself, show what product can be purchased, which loss is addressed or what would be paid. This edition publishes no capacity ranking.
Corrections and changelog
Send the affected statement and dated primary document to press@decentralised.news. Use public or redacted references, not private keys, identity documents or confidential claim files. Version 1.0.0, 12 November 2026: initial dated terms review and local calculation model. Changes to the linked wording, annex structure, filing process or formula require editorial review.
Primary sources
- Nexus Mutual: membership and eligibility.
- Nexus Mutual: current cover-wordings directory.
- Nexus Mutual: reviewed Protocol Cover Terms and Conditions.
- Nexus Mutual: DeFi-cover explanation.
- Nexus Mutual: filing a claim.
- Nexus Mutual: claim assessment.
- Nexus Mutual: buying cover and reading its scope.
Published schema and illustrative record
The schema documents this instrument’s JSON format. The example below contains constructed illustrative inputs and outputs; it is not a provider measurement, verified case or live dataset. The instrument above creates a separate record from the inputs you choose. These resources do not establish an API or an automatic monitoring service.
JSON Schema — dn.defi-cover-amount-window.v1
Schema version 1.0.0. The schema identifier is a versioned reference, not an asserted network endpoint.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:dn:defi-cover-amount-window:v1",
"title": "DN DeFi Cover Amount and Filing Window record v1",
"type": "object",
"additionalProperties": false,
"required": [
"schemaId",
"schemaVersion",
"instrument",
"recordType",
"createdAt",
"sourceReviewDate",
"inputs",
"outputs",
"assumptions",
"limits"
],
"properties": {
"schemaId": {
"const": "dn.defi-cover-amount-window.v1"
},
"schemaVersion": {
"const": "1.0.0"
},
"instrument": {
"const": "DN DeFi Cover Amount and Filing Window"
},
"recordType": {
"const": "reader_entered_scenario"
},
"createdAt": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"sourceReviewDate": {
"const": "2026-11-12"
},
"inputs": {
"type": "object",
"additionalProperties": false,
"required": [
"alias",
"unit",
"precision",
"originalCover",
"remainingCover",
"loss",
"reimbursements",
"deductibleBps",
"rounding",
"coverStart",
"coverEnd",
"eventAt",
"asOf",
"cooldownDays",
"graceDays",
"termsRef"
],
"properties": {
"alias": {
"type": "string",
"maxLength": 120,
"minLength": 1
},
"unit": {
"type": "string",
"maxLength": 32,
"minLength": 1
},
"precision": {
"type": "integer",
"minimum": 0,
"maximum": 18
},
"originalCover": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"remainingCover": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"loss": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"reimbursements": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"deductibleBps": {
"type": "integer",
"minimum": 0,
"maximum": 10000
},
"rounding": {
"type": "string",
"enum": [
"down",
"nearest",
"up"
]
},
"coverStart": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"coverEnd": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"eventAt": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"asOf": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"cooldownDays": {
"type": "integer",
"minimum": 0,
"maximum": 3650
},
"graceDays": {
"type": "integer",
"minimum": 0,
"maximum": 3650
},
"termsRef": {
"type": "string",
"maxLength": 240
}
}
},
"outputs": {
"type": "object",
"additionalProperties": false,
"required": [
"deductibleAmount",
"lossAfterReimbursements",
"amountAfterDeductible",
"arithmeticCappedAmount",
"eventPlacement",
"cooldownEndsAt",
"filingOpensAt",
"filingDeadline",
"filingWindowSeconds",
"filingPlacement",
"coverExhausted",
"claimApproval"
],
"properties": {
"deductibleAmount": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"lossAfterReimbursements": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"amountAfterDeductible": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"arithmeticCappedAmount": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"eventPlacement": {
"enum": [
"before_entered_cover",
"at_or_after_entered_cover_end",
"inside_entered_cover"
]
},
"cooldownEndsAt": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"filingOpensAt": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"filingDeadline": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"filingWindowSeconds": {
"type": "number",
"minimum": 0
},
"filingPlacement": {
"enum": [
"no_calculated_overlap",
"before_calculated_open",
"at_or_after_calculated_deadline",
"inside_calculated_window"
]
},
"coverExhausted": {
"type": "boolean"
},
"claimApproval": {
"const": "undetermined"
}
}
},
"assumptions": {
"type": "array",
"minItems": 4,
"maxItems": 6,
"items": {
"type": "string"
}
},
"limits": {
"type": "object",
"additionalProperties": false,
"required": [
"coverageDetermined",
"claimSubmitted",
"lossValued",
"annexParsed",
"sublimitsApplied",
"providerEligibilityVerified"
],
"properties": {
"coverageDetermined": {
"const": false
},
"claimSubmitted": {
"const": false
},
"lossValued": {
"const": false
},
"annexParsed": {
"const": false
},
"sublimitsApplied": {
"const": false
},
"providerEligibilityVerified": {
"const": false
}
}
}
}
}Illustrative example JSON record
This fixed example is published for inspection and integration testing. Its record timestamp is not an evidence-verification timestamp.
{
"schemaId": "dn.defi-cover-amount-window.v1",
"schemaVersion": "1.0.0",
"instrument": "DN DeFi Cover Amount and Filing Window",
"recordType": "reader_entered_scenario",
"createdAt": "2026-11-12T12:00:00.000Z",
"sourceReviewDate": "2026-11-12",
"inputs": {
"alias": "example-protocol-position",
"unit": "USDC",
"precision": 2,
"originalCover": "100000.00",
"remainingCover": "100000.00",
"loss": "30000.00",
"reimbursements": "5000.00",
"deductibleBps": 500,
"rounding": "down",
"coverStart": "2026-10-01T00:00:00.000Z",
"coverEnd": "2026-11-01T00:00:00.000Z",
"eventAt": "2026-10-20T12:00:00.000Z",
"asOf": "2026-11-12T12:00:00.000Z",
"cooldownDays": 14,
"graceDays": 35,
"termsRef": "Protocol Cover QmQQ88vaZkgEY9qXKPtq7Se6caSjB2RTqF1GAnBLW1k8EY; verify your annex"
},
"outputs": {
"deductibleAmount": "5000.00",
"lossAfterReimbursements": "25000.00",
"amountAfterDeductible": "20000.00",
"arithmeticCappedAmount": "20000.00",
"eventPlacement": "inside_entered_cover",
"cooldownEndsAt": "2026-11-03T12:00:00.000Z",
"filingOpensAt": "2026-11-03T12:00:00.000Z",
"filingDeadline": "2026-12-06T00:00:00.000Z",
"filingWindowSeconds": 2808000,
"filingPlacement": "inside_calculated_window",
"coverExhausted": false,
"claimApproval": "undetermined"
},
"assumptions": [
"The entered formula and parameters must match the applicable wording and annex.",
"Deductible uses original cover; cap uses remaining cover. All money uses the same unit.",
"Days are exactly 24 hours in UTC. Event interval is start-inclusive/end-exclusive.",
"Filing interval is opening-inclusive/deadline-exclusive as a conservative planning convention.",
"Filing opens at the later of cover start and event cooldown end."
],
"limits": {
"coverageDetermined": false,
"claimSubmitted": false,
"lossValued": false,
"annexParsed": false,
"sublimitsApplied": false,
"providerEligibilityVerified": false
}
}
