Skip to main content
This template turns a completed threat model into an operational monitoring plan for a protocol or set of smart contracts on Stellar. Where the threat model asks what could go wrong and how will we design against it, this plan asks how will we watch for it in production. Each threat identified in the threat model becomes one or more observable on-chain effects, and each effect becomes a rule that the monitoring solution watches while the contracts are live. Directions: Fill out each section below to the best of your ability. Carry the threat identifiers over from the STRIDE threat model so the two documents stay linked. Work through the sections in order; every threat should leave the exercise with at least one monitor and a defined response. Keep completed plans internal. A filled-in monitoring plan is a map of what is (and isn’t) monitored. Treat a populated version as sensitive.

​
What are we monitoring?

Directions: Describe the system in scope, then inventory the components and on-chain addresses this plan covers. Input text: high-level description of the protocol, the value it holds, and the parts of it this plan covers.
Keep this inventory current. Addresses can change with new versions, and an out-of-date address list is the most common reason a monitor silently stops working. If it’s discovered later that scope has changed, update this section with the latest information.

​
What could go wrong?

Directions: List the threats this plan monitors, carried over from the threat model. Reuse the identifiers from the STRIDE model (for example, Elevation.1) so each monitor traces back to a known threat. Assign each threat a severity using the reminders below.

​
Severity reminders

​
Threat register

​
What does exploitation look like on-chain?

Directions: For each threat, describe how exploitation might unfold and the observable on-chain effect(s) it would leave behind. There can be several scenarios, and several effects, per threat.
If a threat has no observable on-chain effect (for example, a compromised frontend or an oracle’s upstream data source), record it here and plan to monitor it off-chain. Don’t drop it just because it isn’t visible on-chain.

​
What will we monitor for?

Directions: Map each observable effect to a monitoring rule, stating the trigger condition and the baseline that makes it meaningful. Uniquely identify each monitor as <ThreatID>.M.<n> so it traces back to its threat, the same way remediations in the threat model are identified as <ThreatID>.R.<n>. Each monitor can be stated in a single line:
  • We address [Threat ID] in [affected component] by monitoring for [on-chain effect] on [address].
  • For example: Elevation.1.M.1 - We address Elevation.1 in the lending pool factory by monitoring for deploy invocations from users not on an approved list at address CABC123….

​
What happens when an alert fires?

Directions: For each monitor, define what happens when it triggers: who is notified, through which channel, any automated action, and who owns the rule. This is where the monitoring vendor’s automated-response capability (for example, pausing a contract) is recorded. Status values: Active (live and alerting), Tuning (live but thresholds being refined), Planned (agreed but not yet implemented).

​
Did we do a good job?

  • Does every threat in the threat model have at least one monitor, or a documented reason it can’t be monitored on-chain?
  • Is every trigger threshold grounded in an actual baseline rather than a guess?
  • Does every monitor have a defined response, an owner, and a status?
  • Have any monitors fired? Were they true positives? Did the response work as written?
  • Are all on-chain addresses still current after the latest deploy or upgrade?
  • Were any threats found that only surface off-chain, needing a different kind of monitoring?
Treat this plan as a living document: revisit it whenever the contracts, addresses, or threat model change.