GSM on BNBChain: Unlocking Native Security at the Blockchain Layer

Author: GoPlus Security Team
Date: June 2025

TL;DR

• ✅ GoPlus Security Module (GSM) can be integrated natively into a customized @BNBCHAIN node client

• 🔍 In replay tests of 100 real-world attack transactions, GSM flagged 97 — a 97% detection rate

• 💸 Could have prevented over $22 million in user losses in the last year

• ⚙️ Integration added <40ms latency per transaction with zero crashes under 1000 TPS stress

• 🔐 Unlike wallet or API-based solutions, GSM is non-bypassable, intercepting transactions before they hit the mempool

GSM: Security at the Execution Edge

GSM(GoPlus Security Module) is a lightweight, modular SDK or API service that can be embedded into wallets, dApps, RPC services, Layer 2 sequencers, and full blockchain nodes.

At its core, GSM acts as a bridge between user-initiated transactions and the GoPlus security service network. When a transaction is triggered, GSM captures the transaction data and forwards it to the GoPlus security infrastructure. The GoPlus network then performs real-time risk analysis using advanced AI algorithms, taking into account both the transaction itself and the user’s pre-configured security intentions. The resulting security assessment is returned to GSM, which can then take appropriate action — such as allowing safe transactions to proceed or blocking malicious ones.

Unlike traditional Web2 security solutions, GSM is built directly into the blockchain layer, forming a secure isolation boundary between on-chain and off-chain environments. This architecture eliminates dependency on external Web2 security infrastructure and resolves the classic “weakest link” issue — where a system’s overall security is only as strong as its most vulnerable component. By embedding security logic on-chain, GSM ensures that even if Web2-level UI/UX is compromised, users’ assets and transactions remain protected.

How GSM protect every transaction for BNBChain Node: Two-Stage Transaction Filtering

1️⃣ Pre-Mempool Transaction Screening

This stage acts as a sentinel defense at the earliest entry point. When a transaction is submitted via RPC calls like eth_sendRawTransaction, GSM immediately scans it before allowing it into the mempool.

• Objective: Instantly intercept clearly malicious transactions — such as those initiated by blacklisted addresses or interacting with known malicious contracts.

• Advantage: Early rejection prevents harmful transactions from propagating, reduces memory usage, and preserves node/network resources.

2️⃣ Pre-Pending Contextual Batch Analysis

This advanced scanning stage is triggered just before transactions move from the queued state to pending — the final stage before inclusion in a block.

• Objective: Perform deep context-aware risk analysis on transaction sequences. Transactions are grouped and sorted by from address and nonce to analyze behavioral patterns in order.

• Capabilities:Exploit detection: Identify complex exploit attempts such as multi-step reentrancy attacks.
  Behavioral correlation: Detect fraudulent sequences spanning multiple transactions (e.g., fake liquidity provision followed by withdrawal).
  Cumulative risk scoring: Evaluate aggregate risks from a transaction batch — which cannot be revealed by isolated analysis.

🔁 Caching Layer

GSM’s smart caching mechanism stores recent scanning results to avoid redundant analysis of high-frequency benign activity — ensuring both high throughput and low latency under production conditions.

Open Source
🔗 The modified BNBChain node client and all related test data have been open-sourced at: https://github.com/GoPlusSecurity/GSM-BSC

Risk Detection Model: 12+ Features

GSM evaluates each transaction using a multi-factor, weighted scoring model:

All inputs are aggregated into a final Risk Score (0–100) with thresholds:

• 0–20: Low risk → Allow

• 21–60: Moderate risk → Flag

• 61–100: High risk → Block (default)

Thresholds can be tuned per wallet, user, or node policy.

Performance Benchmark: gRPC Interfaces

GSM exposes two core high-performance interfaces:

• EVMRiskScore: for single transaction evaluation

• EVMBatchRiskScore: for contextual batch transaction analysis

All benchmarks were conducted on a testbed that mirrors BNBChain validator requirements to ensure realistic performance metrics

🔬 Test Environment

• Network: BNBChain Chapel Testnet

• Hardware:
  - 8-core CPU
  - 16GB RAM
  - 500GB SSD (NVMe)

• Client Software:
  - BNBChain full node (v1.1.18)
  - With GoPlus GSM module natively integrated

• Load Generation Tools:
  - Parallel gRPC client simulator
  - Performance profiler for latency breakdown
  - Internal GoPlus replay test suite for historical exploit - scenarios

EVMRiskScore — Single Transaction Mode

EVMBatchRiskScore — Batch Mode

⚙️ Result: Node remained stable for 24 hours under 1000TPS with GSM enabled — no crashes, no sync failures.

🧷 Open Source Availability

The modified BNBChain node client and all related experimental data have been open-sourced:

👉 https://github.com/GoPlusSecurity/GSM-BSC

Real-World Detection Test: 100 Exploit Transactions

Testing Methodology:

1. Selected 100 BNBChain historical exploit transactions (2024.4–2025.5)

2. Reconstructed account & block state in Chapel testnet

3. Replayed transactions via GSM-enabled node

4. Logged GSM decisions and scores

5. Datasource: ScamSniffer、CyversAlerts、SlowMist_Team、SlowMist hacked、AegisWeb3、Phalcon_xyz、PeckShieldAlert、CertiKAlert、defihacklab、Rekt 、GoPlus

Case Studies

🧪 Case #1: Phishing Approval Trap

• Type: Fake airdrop site with malicious "approve"

• Risk Score: 100

• Indicators:Phishing score: 82
  To address risk: 82
  Function pattern: infinite approve
  User behavior anomaly: 23

→ 🚫 Blocked

🧪 Case #2: Honeypot Token (Buy-only)

• Type: Token lets users buy, but not sell

• Risk Score: 100

• Indicators:Rug score: 100
  To address: 68
  Abnormal input amount: 24

→ 🚫 Blocked

🧪 Case #3: Exploit on vulnerable DeFi contract

• Type: Hacker launches low-level call exploiting reentrancy

• Risk Score: 100

• Indicators:Exploit model match: 90
  From address flagged: 90
  Call data pattern anomaly: 82

→ 🚫 Blocked

Why GSM > Traditional Security Layers

Call to Action

Security cannot be an afterthought. GSM proves it’s possible to intercept malicious transactions before they go live — even without modifying consensus.

We’re calling on:

• L1/L2 blockchains

• Rollup-as-a-Service (RaaS) providers

• RPC Node providers

• DApp and wallet infra teams

To adopt GSM as a default security layer.

🔗 Try GSM now: [email protected]

📚 Docs: https://github.com/GoPlusSecurity/bsc-gsm