Scallop’s Sui monitoring shows why protocol-native detection matters

At a glance

What this is: This is Blockaid's account of how Scallop moved to Sui-native monitoring for a DeFi lending protocol and found that EVM-first tools, manual response, and limited internal expertise left critical gaps.

Why it matters: It matters because IAM and security teams governing machine, workload, or protocol access need monitoring that matches the platform's actual execution model, or they will miss the behaviours that matter most.

By the numbers:

• Scallop manages pools across 23 assets with approximately $130M in TVL.
• Scallop would have $130M+ uninsured against any attack without automated security monitoring.
• Since Q1-2026 implementation, Scallop has achieved MTTD under 1 minute from any anomalous onchain event.

Context

DeFi protocol monitoring fails when the control plane does not match the protocol's execution model. In Scallop's case, the core problem was not just alerting volume, but that EVM-first assumptions could not see Sui's object model, dynamic fields, and Programmable Transaction Blocks with enough fidelity to govern real risk.

Scallop needed a monitoring approach that could cover financial manipulation, privileged function misuse, and behavioural anomalies without forcing all of those behaviours into one generic rule set. That is a governance problem as much as a detection problem, because the team was trying to secure a protocol whose runtime behaviour changed faster than its internal monitoring model.

The article also shows a familiar NHI pattern at a different layer: when tools depend on manual triage and human pace, they expose a standing privilege and response gap between detection and containment.

Key questions

Q: What breaks when security monitoring is built on the wrong chain model?

A: Monitoring breaks when the control logic assumes a different execution model than the one the protocol actually uses. In practice, that means alerts may miss native state changes, privilege paths, or behaviour patterns that are only visible in the real runtime. The result is false confidence, slower containment, and blind spots where attackers can act before response logic triggers.

Q: Why do protocol teams need separate controls for financial and administrative risk?

A: Because the two risk classes behave differently and require different response paths. Financial manipulation often shows up as abnormal pool movement, rate changes, or oracle distortion, while administrative abuse appears in privileged calls, registry edits, or caller mismatches. If both are handled by one generic detector, teams lose the context needed to decide whether to block, investigate, or escalate.

Q: What signs show that manual incident response is too slow for onchain threats?

A: The clearest sign is that loss can occur before a human can triage, approve, and execute containment. If an anomalous transaction can drain value in one block or a few minutes, manual workflows will always lag the threat window. That is a control failure, not just an operational inconvenience, because speed becomes part of the security boundary.

Q: Should teams prioritise detection fidelity or automated response first?

A: Detection fidelity comes first, but only if it is paired with a response path that can act on high-confidence events without delay. A precise alert that cannot trigger containment still leaves the protocol exposed. Teams should sequence the work so the most dangerous scenarios have both accurate detection and pre-authorised response, rather than treating alerting and containment as separate projects.

Technical breakdown

Why EVM-first monitoring misses Sui-native attack paths

Sui does not behave like an EVM chain, so a detector built around EVM assumptions loses fidelity at the point where object ownership, dynamic fields, and transaction structure matter most. Scallop's risk was not merely that it had a different chain, but that the observable signals an attacker would generate on Sui did not map cleanly to generic monitoring logic. When monitoring abstracts away protocol-specific semantics, it can miss threshold crossings, privilege misuse, and manipulation patterns that are visible only in the native execution model.

Practical implication: Align detection logic to the chain or runtime you are actually governing, not to a generic abstraction that hides the signals you need.

How fine-grained monitors and privilege checks change detection

The article describes two complementary control layers. First, behavioural thresholds such as conversion-rate spikes, large outflows, and pool integrity checks detect abnormal economic activity. Second, caller authorization checks on privileged functions constrain who can alter registry data, oracle mappings, or risk parameters. Together, these controls separate market manipulation from administrative abuse, which matters because the response to each is different. A single alerting layer without privilege context cannot tell whether a protocol event is a user action, a system anomaly, or an unauthorized administrative change. See the Privileged Access Management Guide.

Practical implication: Design separate detection logic for economic anomalies and privileged operations so response paths do not collapse into one generic alert stream.

Why automated onchain response changes the containment model

Scallop's integration of Move-call execution turned containment into a programmable response rather than a human decision under pressure. That matters because the protocol's threat window can close in a single transaction or within minutes, which makes manual approval cycles too slow for high-confidence events. The mechanism is not just faster alerting. It is a shift from detecting after the fact to triggering a protocol action at the moment the threshold is crossed. That is materially different from dashboards, since the control itself is embedded in the runtime response path.

Practical implication: Pre-authorise the containment action itself, not just the alert, when a protocol can be drained faster than humans can coordinate.

Threat narrative

Attacker objective: The attacker aimed to extract historical reward balances from the protocol in a single transaction and turn a logic flaw into immediate financial loss.

1. Entry occurred through a smart contract logic flaw in Scallop's spool reward distributor, which allowed a new account to claim the entire historical reward balance in one transaction.
2. Escalation followed immediately because the attacker converted a logic error into direct protocol value extraction, draining about $143k before containment completed.
3. Impact was limited when Blockaid detected the anomaly in real time and Scallop froze the protocol, preventing an additional approximately $46K in losses.

Breaches seen in the wild

• Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.
• Stryker Microsoft Intune Wiper Attack: Compromised Microsoft Intune credentials enable wiper attack wiping 200,000 Stryker devices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Protocol-native governance is the new baseline for onchain monitoring: A detector that cannot reason about the chain's actual execution semantics is not a security control, it is a translation layer with blind spots. Scallop's Sui object model, dynamic fields, and Programmable Transaction Blocks required control logic that understood the runtime, not just the asset class. The implication is that governance programmes must evaluate monitoring by fidelity to execution, not by dashboard coverage.

Standing response assumptions fail when loss can occur inside a single transaction: This model was designed for environments where humans can review alerts before the window closes. That assumption breaks when protocol abuse, privilege misuse, or reward theft can complete before an analyst even triages the event. The implication is not to add more alerts, but to rethink the premise that detection and containment are separable phases.

Operational, financial, and behavioural monitoring should be governed as one control plane: Scallop needed all three because an attacker can move between oracle manipulation, privileged function abuse, and anomalous behaviour without changing identities or tooling. A narrow detector would see only one slice of that pattern and miss the composite threat. Practitioners should treat these categories as linked governance domains rather than separate point solutions.

Small security teams now need embedded expertise, not just tooling: The article makes clear that the hard part was not collecting signals, but knowing what to watch for and how to tune thresholds. When internal expertise is limited, the real gap is governance judgement over detection design, escalation logic, and response calibration. The implication for practitioners is that security tooling must be paired with a defensible operating model for threshold ownership and incident decision-making.

What this signals

Coverage gaps become governance gaps when the protocol can move faster than the team: Scallop's case shows that monitoring quality is inseparable from the timing of containment. If the control assumes a human can still close the loop after alerting, the programme is already built around a weaker threat model than the protocol actually faces.

Runtime-specific identity and privilege controls now matter as much as event detection: The important shift is not simply better observability, but the ability to trust caller authorisation, registry state, and execution context at the moment a privileged action occurs. That makes policy design and response design part of the same control objective.

Operational resilience for onchain systems depends on pre-decided containment authority: Where a protocol can be harmed in a single transaction, the question is not whether a team has alerts, but whether it has already defined who can stop the system and under what conditions. That is the difference between monitoring and governable response.

For practitioners

• Define chain-native detection logic Map monitoring to the protocol's native execution model, including object ownership, dynamic fields, and transaction semantics, instead of relying on EVM-style abstractions.
• Split economic and administrative alerts Create distinct monitors for oracle manipulation, liquidity and outflow anomalies, privileged function calls, and registry changes so response paths stay specific.
• Pre-authorise automated containment Use a programmable response that can pause the protocol or otherwise contain a confirmed threat without waiting for a manual approval chain.
• Tighten caller authorization on sensitive functions Maintain an explicit registry of approved package IDs, function signatures, and expected caller addresses for every privileged action.
• Build threat thresholds with security expertise Co-develop detection thresholds with people who understand attack patterns, because guessing at alert logic is how coverage gaps survive deployment.

Key takeaways

• Scallop's monitoring problem was not just alert volume, but a mismatch between Sui's runtime semantics and the assumptions built into EVM-first tools.
• The article ties coverage gaps to real exposure, including $130M+ in TVL and a live incident that drained about $143k before containment.
• Practitioners need protocol-native detection, explicit privilege checks, and pre-authorised containment if they expect to govern fast-moving onchain risk.

Related NHI Mgmt Group resources: Just-in-Time Access and Zero Standing Privilege Guide · Privileged Access Management Guide · Ultimate Guide to NHIs: Key Challenges and Risks · Cloud PAM and CIEM Guide

Key terms

• Protocol-native monitoring: Monitoring that understands the native execution model, state structure, and transaction semantics of the environment being protected. For Sui and similar systems, that means detection logic must reflect how objects, permissions, and state changes actually work, not how another chain or platform behaves.
• Caller authorization: A control that checks whether the identity invoking a privileged function is the one expected to do so. In onchain systems, this often means validating package IDs, signatures, registry entries, or approved callers before allowing sensitive state changes.
• Automated containment: A response pattern where verified identity abuse triggers a pre-approved action such as token revocation, credential rotation, or access blocking. The goal is to reduce response latency while keeping the action path auditable and bounded by policy.
• Reward distributor logic: The code path that determines how accumulated rewards are calculated, stored, and claimed in a protocol. If this logic is flawed, an attacker may convert a state or calculation error into immediate financial extraction, even without exploiting a traditional credential weakness.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.