Fig 1: A conceptual mapping of adversarial attack vectors against the BeTrueCore multi-layered architectural defense stack, detailing the specific components (ZK-Nullifiers, MACI, AI Sentinels, Celestia DA) deployed at each layer.
Most collective decision-making protocols fail not at the cryptographic level, but at the human level. Traditional governance mechanisms regularly fall victim to Sybil attacks, coordinated block voting, and sophisticated vote-buying. While existing privacy solutions secure transaction confidentiality, they rarely address the structural environment in which the human signal is formed and manipulated.
The central claim of this work is that genuine sovereignty and privacy must be embedded in the architecture itself — in the structural environment and operational mechanics of the platform’s core architecture.
BeTrueCore is a modular system designed to remove the conditions on which attacks against collective judgment rely. Rather than deploying reactive administrative barriers, the system utilizes a multi-layered, isolated protection stack that combines Minimal Anti-Collusion Infrastructure (MACI v1.2), zero-knowledge proofs (ZK-SNARKs via Circom), and a non-transferable non-linear reputation mechanism termed the Voting Weight of a Unit (VWU).
The architecture addresses three critical engineering challenges:
1. Subverting the Vote-Buying Market
By leveraging mid-session choice mutability and continuous MACI-driven key rotation, BeTrueCore guarantees receipt-freeness. A participant can present any intermediate action to an external buyer as proof of compliance, yet the buyer cannot mathematically verify the final, time-locked choice. Because the commodity is unverifiable and the internal currency (VWU) is strictly inalienable, the transaction lacks an economic subject.
2. Mitigating Scale-Based Sybil Vectors
Protection is distributed across non-contiguous layers. Mass synthetic identities are filtered via L0 behavioral biometrics and keystroke dynamics, bound to unique L1 ZK-nullifier chains to prevent double-voting, and monitored by an L5 read-only AI Sentinel layer to detect long-horizon synchronized activity. To successfully simulate a community, an adversary must practically build one.
3. Decentralizing the Infrastructure Layer
To avoid a single point of capture, the MACI coordinator must publish a mathematically verifiable state transition ZK-proof simultaneously with the result. A compromised coordinator can only affect system availability, not data integrity. Furthermore, the AI agent layer operates strictly in read-only mode, meaning an infrastructural breach grants observation rights but zero execution power.
Operational Application of the Defense Stack: The 7-Step Daily Decision Cycle
To contextualize the theoretical resilience of the Web3-ISM framework, we examine its daily operational primitive, which restricts each participant to a maximum of seven discrete cryptographic actions per 24-hour session, executed in total isolation from the backend and without revealing the individual’s Vote Weight Unit (VWU).
Crucially, the architecture enforces extreme asynchronous flexibility and anti-farming constraints:
Ø Screentime Efficiency: A user may execute anywhere from 1 to 7 actions during an active day, requiring less than 60 minutes of total interaction within the session window.
Ø Variable Participation Frequency (Missed Opportunity Metric): High daily retention is not mechanically mandated. A participant can activate a session as infrequently as once a week or once a month. To maintain strict psychological comfort, the architecture ensures that accumulated points, ranks, and badges are never deducted or penalized for dormancy. Instead, periods of inactivity are recorded strictly as missed cryptographic opportunities. While the user’s historical status remains fully intact, their relative dynamic voting trajectory (VWU) flattens during absence, preventing mass offline accounts from passively hoarding governance alpha without continuous cognitive contribution.
When a session is active, the seven-step cycle unfolds as follows:
-
Prompt Generation (Action 1): The user inputs a single text prompt encapsulating their session thesis, immediately subjected to L0 keystroke dynamics filtering and L5 semantic anomaly clustering to intercept automated AI injection.
-
Pattern Formulation (Actions 2–4): The user executes three binary selections to nominate a Top-3 from a randomized pool of other participants’ prompts; these actions are fully obscured by continuous MACI key-rotation, achieving receipt-freeness.
-
Output Selection (Actions 5–7): The user casts three binary votes on practical dilemmas derived from the previous session’s Top-3 pool, committing the signals to the state transition proof.
Consequently, an adversary attempting a coordinated capture cannot rely on high-throughput script execution or mass passive account hoarding; to shift the system state, the hostile infrastructure must authentically simulate distinct human cognitive engagement vectors across highly irregular, fluid intervals, shifting the cost of attack from capital expenditure to computational and cognitive impossibility.
Technical Discussion & Feedback
We are currently in Phase 2 of our roadmap, focusing on circuit integration, MACI optimization, and preparing for an MVP launch on an EVM testnet. We welcome feedback from Ethereum research engineers, ZK cryptographers, and Solidity developers interested in robust anti-collusion infrastructure.
In particular:
-
Does the receipt-freeness argument hold under a stronger adversary model (e.g. one who can observe all intermediate choices in real time)?
-
Is MACI v1.2 the right primitive for the nullifier layer, or are there more recent constructions that fit better?
-
What is the right aggregation strategy for session-level STARK proofs — per-session batch, per-day batch, or rolling?
Verification & Open Source
· Complete Paper (Zenodo Preprint): The Notary Under Attack: An Adversarial Model for Cryptographic Collective Intelligence. https://doi.org/10.5281/zenodo.21111544
· Verification: The Master Document of BeTrueCore MS is hashed (SHA-256) via OpenTimestamps.
· Repository: https://github.com/Dede-Qorqud/BeTrueCore