Security Architecture & Trust Model
Transparent architectural guarantees, non-custodial operations, and cryptographic defense-in-depth on Base Mainnet.
Shared Responsibility Security Model
M2M Sentinel operates on a clear separation of security responsibilities across cloud infrastructure, application logic, and upstream blockchain nodes:
| Security Layer | Provider / Owner | Enforced Controls |
|---|---|---|
| Platform & Edge Infra | Vercel Edge Network | TLS 1.3 edge termination, global DDoS mitigation, isolated ephemeral serverless container runtime (IAD1), encrypted edge environment variables. |
| Application Security | M2M Sentinel Engine | Zero-plaintext API key storage (SHA-256 salted hash), atomic Redis Lua state machine, PUSH-aware bytecode AST walker (preventing opcode spoofing), fail-closed payment state machine, URL credential refusal. |
| Blockchain Data & Consensus | Base RPC & Nodes | Multi-provider quorum consensus (≥ 2 independent Base mainnet nodes), Chain ID 8453 enforcement, bytecode hash integrity checks, fail-closed 503 on consensus mismatch. |
Cryptographic Key Protection & In-Transit Security
M2M Sentinel enforces strict defensive boundaries across all network boundaries:
- No URL Credentials: API keys and session credentials in query strings are rejected over HTTP to prevent proxy and log leakage. All authenticated calls require the x-api-key header.
- TLS 1.3 Transport: All public traffic and upstream Redis connections require TLS encryption in transit.
- Atomic Quota Consumption: Requests spend credits atomically only after successful completion; 404s, malformed inputs, and upstream failures cost zero credits.
- Replay Defense: Free-tier challenge claims and on-chain payment intent registrations use single-use cryptographic tokens with persistent replay prevention markers.
RPC Trust Model & Provenance Levels
To eliminate reliance on single centralized RPC nodes, M2M Sentinel tracks multi-provider provenance for every observation:
- HIGH_TRUST_PRIMARY: Observation confirmed by operator-credentialed Base archive node (e.g. Alchemy, QuickNode) over TLS with verified Chain ID (8453). Payment settlements accept only this trust tier.
- QUORUM_PUBLIC: Result verified across at least 2 independent public Base consensus providers returning identical bytecode hashes.
- DEGRADED_LOW_TRUST: Single anonymous provider response. The system automatically marks evidence unverified and prohibits on-chain settlement transitions.
- UNTRUSTED_INSECURE: Plaintext HTTP endpoints or mismatched chain IDs; rejected immediately.
On-Chain EAS Project Metadata Attestation & Superchain Registry
M2M Sentinel’s verified project identity, repository lineage, and Base payout configuration are attested on the Optimism Superchain using the Ethereum Attestation Service (EAS):
Responsible Vulnerability Disclosure
We welcome security researchers and developers to audit our platform, verify our open-source SDKs, and inspect our detection engines.
Reporting a Vulnerability
If you identify a security vulnerability, please disclose it responsibly by contacting our security team directly:
Security Contact: [email protected]
We acknowledge all legitimate reports within 24 hours and coordinate patches prior to public disclosure.