PIP-62 l Use Hypernative for Real Time Protocol Security Monitoring

Summary:

This proposal aims to use Hypernative for real time monitoring of the protocol security.

Context:

Since the launch of Parallel V3 in September 2025, several issues have been detected, including bug reports from ImmuneFi and assets allowed in the backing of USDp. This required a rapid response in order to partially pause the protocol when necessary. Although the guardians reacted quickly, thanks to the presence of signers across multiple time zones, this is not optimal and may put the security of the protocol at risk. In order to automate the detection and pausing of the protocol in the event of a detected problem, we propose to use Hypernative.

Rationale:

Hypernative is a leading real-time security platform that unites alerting and threat prevention with a sharp focus on early detection of on-chain threats and automated protective responses. It integrates real-time blockchain monitoring across +70 blockchains, curated threat intelligence, machine learning driven anomaly detection, and highly customizable automation modules to deliver comprehensive protection. Leading protocols across the industry trust Hypernative to identify exploits as they unfold, uncover hidden risks before they escalate, and automatically trigger safe-shutdown or mitigation procedures when necessary.

Product Details:

Parallel will leverage Hypernative’s core solution, their security platform, which proactively detects and prevents a wide spectrum of onchain and offchain threats before they can cause damage. It continuously monitors entire protocols, positions, and transactions to give security and operations teams critical minutes to respond and, when desired, acts automatically to contain live incidents.​

Core Platform Capabilities:

Hypernative provides real-time monitoring, risk detection, and automated response across both onchain and offchain data sources, including smart contracts, bridge interactions, governance proposals, price feeds, web apps, and vulnerability databases - and many other categories and risks. It uses advanced machine learning models, heuristics, simulations, and graph-based techniques to identify hundreds of risk types with high accuracy.​

The platform is designed to catch a broad range of attacks, from smart contract exploits and bridge incidents to frontend compromises, market manipulation, governance manipulation, and private key theft. It focuses on early warning, typically detecting the overwhelming majority of attacks minutes before the first malicious transaction executes, giving teams time to intervene.​

Automated Actions & Workflows:

Despite multiple audits having been conducted, real-time monitoring tools have shown to be one of the most important security checks in web3 security today. Hypernative supports configurable automated actions that can pause critical contracts or protocols, unwind positions, move assets to safety, or enforce granular transaction and address policies based on customer-defined logic. It plugs into existing operational workflows through UI, API, SDK, and webhook integrations, creating programmable, auditable incident response paths that execute faster than manual review.

Note: Hypernative will only have the possibility to pause the mint/burn of USDp on the Parallelizer & Bridging Module, which means that they will not have any admin function nor the possibility to remove collaterals or change DVNs.

Proposed Offer:

Parallel will leverage its Hypernative subscription to enforce a wide range of circuit breakers whenever suspicious, unwanted, or malicious activity attempts to interact with the protocol. Through a thorough due diligence process, conducted with close support from the Hypernative team, Parallel has identified and implemented the most robust configuration of this security layer to protect users and protocol integrity.

Automated pausing and anomaly detection reduce the likelihood that a single incident can cause large user losses or damage protocol integrity.

The Parallel team aims at subscribing to a Hypernative Security Platform package that accounts for enough coverage to the protocol’s security needs and strategy, which will entail:

  • Up to 300 different addresses to monitor

  • Up to 75 different custom modules/logics

  • Up to 16 different chains that can be used to monitor

  • Up to 40 automated protective responses

  • Dedicated Security Engineer and Customer Success Manager to maintain a clean environment, assistance in investigating alerts, onboarding and support from the wider Hypernative team.

The total cost of this investment is $42,500.00 USD for 12 months, which is modest relative to the potential damage that timely mitigation can prevent.

Means:

  • Human Resources: Multisigners will need to sign and execute transactions to execute the proposal.
  • Treasury Resources: 42,500.00 USDC for 12 months from the Insurance Fund.

Technical implementation:

On Ethereum:

  • Transfer 42,500.00 USDC from the Ethereum Insurance Fund to Hypernative

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:

    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Base:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Sonic:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Avalanche:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On HyperEVM:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Polygon:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Arbitrum:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Optimism:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Sei:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On BSC:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Berachain:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Scroll:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Gnosis:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Unichain:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Ink:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

On Tac:

  • In the ParallelAccessManager contract, call the ‘grantRole’ function with these parameters:
    • roleId: 20 (Guardian)
    • Account: Hyperactive Message Sender
    • executionDelay: 0

Voting options:

  • For the Use Hypernative for Real Time Protocol Security Monitoring
  • Against / Rework the Proposal
  • Abstain

Author(s): José Cardoso @ Hypernative

Community poll:

  • For the Use Hypernative for Real Time Protocol Security Monitoring
  • Against / Rework the Proposal
  • Abstain
0 voters
1 Like

I support the integration of Hypernative. It is a necessary layer of defense for the protocol.

​However, I noticed a discrepancy between our approved deployment list and the chains covered in this proposal.

According to the mandate from PIP-57, USDp is approved for chains that are noticeably absent from this proposal’s scope, namely

  1. Plume

  2. Linea

  3. Fraxtal

  4. World (Worldcoin)

  5. Hemi

  6. Plasma

  7. Katana

  8. X Layer

My question to the team:

Are these chains intentionally excluded from the security monitoring?

​I request that these chains be explicitly added to the monitoring scope within this budget.

I need to raise a concern regarding a significant inconsistency between the commercial offer and the technical implementation plan.

​The ‘Proposed Offer’ explicitly limits the package to ‘Up to 5 different chains’.

However, the ‘Technical Implementation’ section requests Guardian permissions across 16 (24) different networks.

The Risk:

This implies a gap where 11 (19) chains might receive the technical setup but lack active real-time monitoring under this budget. Are we selectively securing only a few chains while leaving the other deployments vulnerable?

​Can the team confirm if this $42.5k covers ALL listed chains, or if we are voting for partial coverage? This ambiguity must be resolved.

The proposal is not limited in terms of chains, small typo from Hypernative (was negociated during discussing between Cooper Labs and them)

The offer from Hypernative is including up to 40 automated actions (ARs), regardlesss of the chain. Currently, the majority of the USDp supply is on chains with a “full deployment,” including the Parallelizer, Savings, Bridging & Flashloan Modules. This includes:

  • Ethereum: 10 ARs
    • Parallelizer Module
      • Pause frxUSD mint
      • Pause frxUSD burn
      • Pause sfrxUSD mint
      • Pause sfrxUSD burn
      • Pause USDe mint
      • Pause USDe burn
      • Pause sUSDe mint
      • Pause sUSDe burn
    • Bridging Module
      • Pause lz-USDp
    • Savings Module
      • Pause sUSDp
  • Base: 6
    • Parallelizer Module
      • Pause USDS mint
      • Pause USDS burn
      • Pause sUSDS mint
      • Pause sUSDS burn
    • Bridging Module
      • Pause lz-USDp
    • Savings Module
      • Pause sUSDp
  • Sonic: 6
    • Parallelizer Module
      • Pause frxUSD mint
      • Pause frxUSD burn
      • Pause sfrxUSD mint
      • Pause sfrxUSD burn
    • Bridging Module
      • Pause lz-USDp
    • Savings Module
      • Pause sUSDp
  • HyperEVM: 6
    • Parallelizer Module
      • Pause USDe mint
      • Pause USDe burn
      • Pause sUSDe mint
      • Pause sUSDe burn
    • Bridging Module
      • Pause lz-USDp
    • Savings Module
      • Pause sUSDp
  • Avalanche: 6
    • Parallelizer Module
      • Pause USDC mint
      • Pause USDC burn
      • Pause gami_USDC mint
      • Pause gami_USDC burn
    • Bridging Module
      • Pause lz-USDp
    • Savings Module
      • Pause sUSDp

Note: The Flashloan Module cannot be paused

This represents 34 automated responses out of the 40 that we can implement. These five chains are the most critical, as they are the ones where it is possible to mint and burn USDp and sUSDp. Almost all of the other chains have less than 10 USDp, and only the bridging module is present. We do not believe it is necessary to pay for automated responses on these chains.

Note: The additional cost per automated response is $820 per year. For 19 chains, this would represent an additional cost of $15,580.

We have kept 6 additional automated responses in order to be able to do a full deployment on an additional chain. We also plan to propose to the DAO to remove USDe and sUSDe from the assets authorized to mint USDp on Ethereum in the coming weeks, in order to obtain 4 additional automated responses.

There are three possible options:

  • Cover all chains, i.e., add 19 ARs + an option in the proposal to automatically pay Hypernative when we deploy on a new chain at a price set in advance
  • Cover a limited number of additional chains (e.g. 5) where only the bridging module is present, chains that have the largest supply
  • Leave the proposal as it
2 Likes

Thank you for the detailed clarification.

2 Likes

Is it possible to get an overview of all protocol monthly/yearly Costs?

1 Like

The proposal is now live on Snapshot from January 24th to February 2nd. To vote: Snapshot

The proposal has been approved by the DAO. Results: Snapshot

1 Like

The payment to Hypernative has been executed by us. Transaction: Ethereum Transaction Hash: 0xbe15765aec... | Etherscan

1 Like