GSM on BNB Chain: Unlocking Native Security Capabilities at the Blockchain Layer

Original Author: GoPlus Security Team

Summary

GoPlus Security Module (GSM) can be natively integrated into customized BNB Chain node clients.
In the reproduction tests of 100 real attack transactions, GSM successfully blocked 97 of them—a detection rate of 97%.
Over the past year, this could have prevented user asset losses of more than $22 million.

After integration, single transaction latency increases by <40ms, with zero crashes under a 1000 TPS workload.
Unlike wallet or API-based solutions, GSM cannot be bypassed, as it intercepts transactions before they enter the memory pool.

GSM: A Security Firewall at the Blockchain Client-Side

GSM is a lightweight modular SDK or API service that can be embedded into wallets, dApps, RPC services, Layer 2 sequencers, and full nodes. At its core, GSM establishes a bridge between user transactions and the GoPlus security service network:

1. When a transaction is triggered, GSM captures the transaction data and sends it to the GoPlus security network.
2. GoPlus employs AI algorithms to analyze risks in real-time (including transaction data and user-defined security policies).
3. It then returns a security assessment result, and GSM executes allow or block actions accordingly.

Unlike traditional Web2 security solutions, GSM is built directly at the blockchain layer, creating a secure isolation boundary between on-chain and off-chain environments. This architecture:
· Eliminates reliance on external Web2 infrastructure;

· Addresses the weakest points in traditional security workflows;

· Ensures user assets remain protected even if the Web2 layer UI/UX is compromised.

This test directly integrated GSM into BNB Chain nodes.

GSM’s Two-Stage Transaction Filtering Mechanism

1️⃣ Memory Pool Pre-Transaction Screening (Sentinel Defense)

When a transaction is submitted through RPC calls such as eth_sendRawTransaction, GSM performs immediate scanning before it enters the memory pool:
· Objective: Intercept clearly malicious transactions (e.g., blacklisted addresses, known malicious contract interactions)

· Advantages: Prevent the propagation of harmful transactions, reduce memory usage, and save node resources

2️⃣ Pre-Package Contextual Batch Analysis

Triggered before transactions transition from the queued status to the pending (packaging ready) status:

· Objective: Perform context-aware deep analysis on the transaction sequence (grouped and sorted by `from` address and nonce)

· Capabilities:
          Detect complex exploits like multi-step reentrancy attacks;
          Identify fraudulent transaction sequences spanning multiple transactions (e.g., fake liquidity injection followed by withdrawal);
          Assess batch transaction risks using a cumulative risk score (unachievable through single-transaction analysis)

Smart Caching Layer

Stores recent scanning results to avoid repeat analysis of high-frequency benign activities—ensuring high throughput and low latency.

Open Source Repository

The modified BNBChain node client and test data have been open-sourced, accessible at this link.

Risk Detection Model: 12+ Dimensional Features

GSM evaluates transactions using a multi-factor weighted scoring model:

```html

Output Risk Score (0–100) and Handling Strategy:

· 0–20: Low risk → Approve

· 21–60: Medium risk → Flag

· 61–100: High risk → Block (Default)

The threshold can be adjusted based on wallet, user, or node-specific strategies.

Performance Benchmark: gRPC Interface

GSM provides two high-performance interfaces:

· EVMRiskScore (single transaction assessment)
· EVMBatchRiskScore (batch transaction analysis)

Testing Environment

· Network: BNBChain Chapel Testnet

· Hardware:
          8-core CPU
          16GB RAM
          500GB NVMe SSD
· Software:

BNBChain Full Node (v1.1.18) + GSM Module
· Load Tools:

Parallel gRPC Client Simulator
Latency Analysis Performance Profiler
GoPlus Historical Attack Scenario Replay Test Suite

Result: With GSM enabled, the node operated stably under a 1000 TPS load for 24 hours—zero crashes, zero sync failures.

```

Open Source Address

The modified BNBChain node and experimental data can be found here.

Real Attack Detection Test: 100 Exploitation Transactions

Testing Methods:

1. Select 100 historical attack transactions from BNBChain (2024.4–2025.5)
2. Reconstruct accounts and block states on the Chapel testnet
3. Replay transactions through the GSM node
4. Record GSM decisions and scores
5. Data sources: ScamSniffer, CyversAlerts, and 10 other security agencies.

Attack Case Analysis

Case #1: Phishing Authorization Trap

· Type: Fake airdrop website + malicious "approve" authorization
· Risk Score: 100
· Features:
          Phishing Score: 82
          Receiving Address Risk: 82
          Function Pattern: Unlimited Approval
          User Behavior Anomaly: 23

           →  Mitigated

Case #2: Honeypot Tokens (Buy-Only)

· Type: Tokens that can be bought but cannot be sold
· Risk Score: 100
· Characteristics:
         Rug Pull Score: 100
         Recipient Address Risk: 68
         Abnormal Input Amount: 24
         →  Intercepted

Case #3: DeFi Contract Exploitation

· Type: Hacker exploits reentrancy vulnerability through low-level function calls
· Risk Score: 100
· Characteristics:
         Vulnerability Pattern Match: 90
         Initiator Address Risk: 90
         Abnormal Call Data Pattern: 82
         →  Intercepted

Call to Action

Security measures should not be applied reactively. GSM validates that: malicious transactions can be intercepted before they take effect without modifying the consensus mechanism!

We urge the following participants to deploy GSM as the default security layer:

· L1/L2 Blockchain Teams

· Rollup-as-a-Service (RaaS) Providers

· RPC Node Providers

· DApp and Wallet Infrastructure Teams

Try Now: service@gopluslabs.io; Documentation

This article is a contribution and does not represent the views of BlockBeats.