3. System Architecture
BAT's overall architecture consists of five core system modules, responsible for cross-chain interconnection, order matching, fund scheduling, risk protection, and interface integration. Together, they form a closed-loop execution framework for high-frequency on-chain trading. Within this system, each module can be independently scaled, while also achieving decoupled collaboration through standardized protocols, thereby creating a multi-chain execution platform with systemic resilience and strategic compatibility.
3.1 Cross-chain Communication Layer
The cross-chain communication layer is the underlying foundation of the BAT architecture, responsible for connection and synchronization across chains. It carries core functions such as inter-chain state transmission, transaction intention broadcasting, cross-chain asset coordination, and execution receipt collection. This module uses a modular communication protocol combined with a relay network abstraction layer and a verifiable state channel as technical support to build an inter-chain interaction system compatible with multi-chain structures.
The underlying communication layer utilizes an asynchronous message-driven architecture. By monitoring event logs and state changes on each target chain, it captures transaction trigger signals and encapsulates them in a standardized Transaction Intent Bundle (TIB). The TIB contains core parameters such as the transaction's source chain context, expected behavior, target chain mapping, price limit slippage, arrival time limit, and security level tag, ensuring a unified input structure for cross-chain execution.
In terms of verification mechanisms, BAT supports multiple types of security models:
Light client verification, local state synchronization and proof verification based on the on-chain state root;
Optimistic Verification + Fraud Proof, suitable for delay-tolerant tasks that do not require immediate confirmation;
The zkBridge path introduces the ZK-SNARK/STARK model to compress cross-chain states and will support full-chain compressed proofs in the future;
The EigenLayer AVS integration path leverages active verification services under the Ethereum trust layer to improve the flexibility and cost-effectiveness of cross-chain behavior verification.
The communication network is built on a multi-path relay abstraction layer, allowing multiple relay paths to run concurrently. The system dynamically allocates routing paths based on real-time inter-chain latency, block times, and gas availability. Each channel incorporates a built-in BLS signature aggregation mechanism and replay protection framework to ensure message integrity and non-repetitiveness.
To meet the high-frequency cross-chain strategic transactions scenarios , the BAT communication layer is designed with the following features:
Message sorting mechanism to ensure the consistency of transaction execution order between chains;
The state proof relay layer standardizes the mapping of state changes across chains;
Latency monitoring and lazy timeout logic improve fault tolerance and transaction recovery capabilities in high-congestion environments.
The BAT plan itself can also support a routing mechanism based on the Intent-Based Execution Paradigm. By analyzing the "transaction intention" of the strategy side or the user side rather than a fixed path execution logic, the system can find the optimal landing point and execution strategy in a multi-chain environment, further improving liquidity utilization efficiency and cost control capabilities.
In the future, BAT's communication layer will be further iterated and refined, becoming compatible with the mainstream Sovereign Rollup Messengers architecture and supporting interoperability between modular Rollups (such as Celestia Stack, Polygon CDK, and OP Stack). It will also separate the standardized cross-chain protocol layer from the execution layer, enhancing composability across the Rollup ecosystem. This will enable BAT to uniformly abstract, schedule, and provide feedback on the state of funds and execution opportunities, which are inherently distributed across multiple heterogeneous chains and Rollups. This will build an inter-chain synchronization graph of transaction behavior, providing a continuous and smooth information flow foundation for upper-layer matching, strategy scheduling, and risk control.
3.2 Matching and Execution Engine
The matching and execution engine is the core computing module within the BAT architecture, responsible for receiving, deconstructing, pricing, path resolution, and actual block submission. Through unified order representation, abstracted transaction types, and cross-chain composable execution, this module reshapes the upper limit of on-chain trading performance, enabling high-density deployment and stable returns for strategic liquidity even in complex structures.
The underlying system abstracts multiple modules, supporting various transaction interaction models such as Order Book, RFQ, active liquidity order pulling, and AMM Interaction. All orders are standardized as Unified Order Objects, which are parsed by a DSL parser and mapped to actual execution paths.
The matching engine runs on an asynchronous computing framework, integrating pre-matching logic and trade validation. It uses real-time access to on-chain order book liquidity and quote curves, combined with a path scoring function to rank and filter candidate trade paths. This scoring logic comprehensively considers price quality, gas costs, slippage predictions, on-chain confirmation latency distribution, and historical failure rates to output the optimal set of execution paths.
To accommodate strategic funds’ sensitivity to time accuracy and order placement rhythm, the BAT matching module supports the following features:
Sub-paths are executed in segments and decomposed into intra-chain sub-paths and inter-chain bridge paths under the same transaction logic;
Slippage tolerance range and dynamic order cancellation weight enhance order stability in volatile market environments;
Matching result mapping normalizes the order results on heterogeneous chains to ensure that the account results are traceable and combinable.
At the execution layer, BAT built an execution path solver, serving as an intermediary component connecting matchmaking results with actual on-chain interactions. This solver is responsible for invoking the on-chain Router module, aggregating liquidity pool states, constructing the target transaction structure, and utilizing a path compressor to optimize gas usage and reorder multi-step transactions. All pre-execution path rehearsals (Dry Runs) verify that the order results align with user expectations using an expected state difference function. Any deviation from expectations triggers an automatic rollback or a dynamic reconstruction mechanism.
To ensure robust execution, the BAT system provides Failure Recovery Flow, which has:
Rollback if execution fails;
Fund release guarantee;
Multipath degradation and dynamic path switching;
Final state timeout ruling.
The matching execution engine is fully integrated into the risk control signal channel. All orders must pass the executable score authorized by the risk module before entering the matching process, avoiding transaction path failure due to abnormal target chain parameters, unstable asset pool status or changes in contract permissions.
3.3 Policy Scheduling System
The Strategy Scheduling System is the intelligent hub built by BAT for high-frequency and structured liquidity. It is responsible for converting heterogeneous multi-source on-chain signals into executable trading tasks and completing key operations such as multi-dimensional scoring, path distribution, position control, and dynamic prioritization. This module constitutes the "fund orchestration layer" between the matching and execution engines, ensuring that strategic funds are efficiently and orderly deployed to the optimal execution path, maximizing their alpha output efficiency per unit time.
The underlying layer of the scheduling system is built based on the opportunity scheduling graph modeling framework, which slices and manages the strategy signals according to the three-dimensional coordinates of chain, target, and time window. Each slice contains the target transaction target, market status, capacity assessment and historical feedback indicators within the corresponding window.
For each candidate opportunity, the system conducts a multi-dimensional quantitative evaluation based on the AI model. The indicators include:
Expected Net α: The actual net profit after deducting slippage, gas, tax rate and failure probability;
Transaction success rate: Based on the historical on-chain p50/p95 delay and the volatility of the previous path model;
Available Capacity: The actual position limit determined by the trading depth and the impact threshold;
Risk control score: depends on the on-chain status score and environmental safety level output by the risk module.
These scoring results are standardized and written into the opportunity priority queue, which is then rotated and allocated by the scheduler. The system supports a dynamic rebalancing mechanism, allowing strategic funds to automatically shift to opportunity windows with a better return-risk ratio when the boundaries of the return-volume curve change.
When allocating funds, BAT allows for configurable weighting parameters for different types of opportunities, creating differentiated funding pathways for stable returns, high volatility, and hot spot-responsive strategies. The LAW model dynamically adjusts parameters based on historical alpha persistence, win rate stability, and slippage trends, maintaining consistent scheduling expectations in a high-frequency environment.
When the system detects a decline in marginal returns from local opportunities, an increase in execution failure rates, or a sudden increase in on-chain gas costs, it automatically shifts into a downshift state, reducing path weights or suspending strategy entry to protect overall system stability. Each strategy execution unit has clear upper and lower position limits, a slippage window, and a dynamic windowing period to ensure that modules do not interfere with each other in a multi-strategy concurrent environment.
The strategy scheduling system and BAT's data layer form a closed loop, that is, all actual execution results (including slippage, delay, and net alpha) will be written back to the scoring model as samples, triggering the model's self-update mechanism, and realizing a self-learning path from T-1 daily behavior to T+0 allocation logic and then to T+1 calibration weights, so that the system has the alpha operation capability of "automatic discovery-allocation-adjustment-optimization" in the on-chain environment.
3.4 Security and Risk Control Module
BAT's security and risk control module is a core component of the platform's system-level security architecture, responsible for key responsibilities such as constraining strategic behavior, determining transaction feasibility, intercepting path anomalies, and maintaining system stability. Based on an "on-chain behavioral supervision core," this module provides continuous risk identification and control capabilities for the matching, execution, and scheduling processes through a three-layer mechanism: strategy scoring, environmental perception, and behavioral modeling.
The risk control module operates in a two-way feedback loop with the matching engine and strategy scheduling system. Before a trade path is generated, the risk control system provides an "executability score" to determine whether specific trading instructions for that strategy are permitted under the current circumstances. During the strategy ranking process, the risk control module outputs a "risk adjustment score" to influence priority. After execution is complete, the module writes actual trade performance (such as slippage, latency, return deviation, success rate, etc.) back into the "behavioral baseline model" to drive dynamic updates of risk parameters.
In terms of mechanism design, the risk control module includes the following core subsystems:
1) On-chain environmental monitoring system
This subsystem is responsible for real-time capture of the risk status of the transaction target chain, including but not limited to:
Contract permission changes (owner migration, tax rate modification, blacklist activation);
Liquidity pool changes (LP removal, pool freeze, pool migration);
Huge asymmetric transaction inflows/outflows;
Synchronization of asset sudden audit events and community attack reports.
The risk control module generates a "transaction environment confidence score" for the target by monitoring the matching degree between the preset event topic and the "on-chain risk signal template library", and decides whether to trigger path interception or strategy downshifting.
2) Risk level classification and gate control system
The risk control system will establish dynamic risk levels for transaction targets, strategic behaviors, account identities, and other dimensions, and set corresponding gating rules:
High-risk targets are prohibited from triggering batch order execution;
Assets with unclear risk status are prohibited from using RFQ or AMM interfaces to place transactions;
The user end can access the risk parameter pre-screening interface to complete the pre-check before submitting the intention.
The system uses a "multi-factor classifier" to construct risk status intervals, which can be dynamically adjusted based on actual execution feedback.
3) Execution path verification mechanism
After the matching engine and path solver generate the transaction path, all proposed execution paths must be simulated and tested through the "execution preview + expected state difference function", and the risk control module must determine whether they are within the acceptable error range.
If the simulation state deviates too much, the slippage exceeds the limit, or the gas cost exceeds the safety budget, the path will be downgraded or recalculated to ensure that the strategy instructions are predictable, traceable, and have no systematic deviation after implementation.
4) Strategic Behavior Modeling System
This module continuously tracks the behavior of each strategy account and trading group, creating an individual behavioral profile based on factors such as transaction frequency, order cancellation rate, failure distribution, and capital utilization density. The system compares these behavioral characteristics with a "stability baseline model." If a strategy's performance deviates significantly or exhibits multi-factor instability (such as continuous slippage or a sudden drop in path hit rate), the system will proactively trigger an alert, lower its scheduling priority, and, if necessary, force a downshift or disable the strategy.
Through the above structure, BAT's risk control system will run through all aspects of signal recognition, path screening, instruction implementation and a posteriori feedback, forming an adaptive security closed loop with continuous learning and dynamic adjustment, building a reliable boundary for strategy execution, making the overall system operate within a predictable range, and providing institutional-level stability guarantees for the on-chain liquidity.
3.5 Data and API Interface Layer
The data and API interface layer is a key interface module that exposes the BAT platform to external users, policy systems, developer toolchains, and integration platforms. It not only handles standardized interaction and data distribution but also serves as the state synchronization and feedback pipeline between BAT's core modules. It is a key infrastructure component that drives policy scheduling, risk control assessment, path evaluation, and system self-evolution.
This layer consists of two parts: the data indicator system and the interface abstraction system, which together build a service layer system with high observability, high adaptability and high stability.
1) Data indicator system
BAT's data system collects and aggregates operational data from the matching, execution, scheduling, and risk control modules, storing it in a multi-dimensional structure and providing access to composite indicators on and off the chain. The data is divided into the following categories:
● Strategy execution indicators
Single net alpha (net return distribution)
T value (daily capital turnover times)
Execution Hit Rate
Slippage distribution (p50/p95 slippage trajectory)
Latency metrics (submission → block drop percentile)
Path volatility (path score stability)
● Strategic behavior indicators
Strategy account slippage deviation trajectory
Daily transaction volume/order cancellation rate
Behavioral Deviation Score (vs Stability Baseline)
Capacity occupancy distribution (actual capital pressure of each strategy)
● System status indicators
Current congestion status of each chain (Gas, block time)
Risk control score heat map (real-time risk level of each target)
Cross-chain channel delay monitoring
Failure reason tracking (contract failure, inconsistent status, abnormal permissions)
All indicators are accessible through the platform's data pull and push subscription interfaces, and support customized indicator template output (for scenarios such as strategy parameter updates, model tuning, and backtesting). To prevent strategy execution deviations due to data misunderstandings, all indicators have upper and lower tolerance limits, and are automatically flagged (e.g., Degraded/Alert) when reaching abnormal boundaries.
2) Interface abstraction system
The API layer provides a unified access structure, supporting rapid integration of third-party strategy systems, market-making tools, wallet service providers, asset management platforms, etc. The system interface design adopts a modular structure, covering the following core functions:
● Account and permission interface
Strategy account authorization management
Scheduling limits and risk control authority configuration
Execution permission granularity (chain/target/strategy type dimensions)
● Order and route control interface
Limit order, market order, and conditional order construction
Customizable cross-chain path parameters (preferred chain/target pool/slippage limit)
Subaccount Allocation and Position Control Structure
● Data subscription interface
Real-time matching status
Risk control signal push (risk changes/blacklist targets)
Execution path changes (alternative path promotion and demotion)
● Status callback interface
Transaction block result (Tx hash + slippage)
Delayed exception event callback
Concurrent return of transaction and failure paths (facilitating strategy engine reuse)
To adapt to different developer ecosystems, the BAT API supports multiple access modes including RESTful, GraphQL, and WebSocket. Future versions will be compatible with gRPC and JSON-RPC streaming protocols, and provide one-click access adapters for mainstream strategy hosting platforms (such as Hummingbot, Flashbots, Hyperliquid toolchain, etc.).
The entire data and interface layer is also part of BAT's self-learning closed loop. Strategy execution results, environmental status, call preferences, and feedback information are uniformly written into the strategy behavior warehouse and system indicator database, serving as important input for scheduling system optimization, risk control parameter adjustments, and matching engine weight corrections.
3.6 AIBAT Intelligent Trading System
AIBat is the native intelligent trading system within the BAT ecosystem, designed to meet the needs of high-frequency, reproducible alpha strategy trading on-chain. As a system-level trading execution component, AIBat integrates multiple submodules, including on-chain sensing, signal recognition, strategy scoring, fund scheduling, path execution, and return feedback, to complete a full-chain closed-loop execution process from opportunity identification to asset allocation. Designed with stability, low latency, transparent structure, and verifiable results as core principles, the system provides high-performance, low-slippage, professional trading services for complex on-chain environments.
3.6.1 System Structure and Module Division
AIBat consists of six main modules, each of which plays a key role in the process from on-chain perception to transaction execution feedback:
Data perception and event capture module: By subscribing to multi-chain mainstream protocol events (such as DEX pool changes, large-scale fund transfers, abnormal address behavior, etc.), it builds real-time on-chain status snapshots as the basis for identifying trading signals;
Strategy Scoring Engine: Integrates multi-dimensional scoring factors (expected margin α, execution rate, slippage tolerance, trading capacity, etc.) to sort and screen candidate opportunities and improve capital utilization efficiency;
Fund scheduling and resource allocation system: Dynamically allocates funds to different strategic paths based on target capacity, inter-chain latency, and return-risk ratio, supporting time sharding and chain × target × strategy level partitioning control;
Path execution and matching engine: Calls the BAT platform matching module to complete cross-chain order routing, path optimization, transaction splitting and slippage control. The execution process supports failure rollback and order retry.
Status tracking and feedback write-back module: records the execution status, slippage data, and profit results of each transaction, and feeds it back to the scoring engine for the next round of strategy parameter adjustment;
Logging and monitoring system: Outputs strategy execution logs and key trading indicators (such as PnL, slippage, transaction rate, average holding time, etc.), and provides external observation interfaces for auditing and verification.
3.6.2 Strategy Execution Method and Trading Behavior Structure
AIBat does not rely on fixed template strategies, but instead uses a modular transaction behavior library to structure and orchestrate combinable transaction behaviors on the chain. The transaction behaviors currently supported by the system include but are not limited to:
On-chain – CEX price deviation capture and arbitrage;
High-quality addresses follow the position building;
Multi-chain liquidity fragment splicing and routing optimization;
Prediction of on-chain permission/parameter changes;
Liquidity squeeze and trend-following trading during pool migration;
High-frequency stable hedging and volatility covering behavior;
System latency arbitrage and fee modeling trading window identification.
Each type of behavior is dynamically enabled or disabled based on the current on-chain status, underlying market depth, and changes in execution costs, ensuring that the system has the ability to generate positive expected returns across different transaction density cycles.
3.6.3 Transaction Execution Characteristics and Parameter Constraints
The system uses a strict parameterized structure at the execution level to ensure that trading activities are completed in a closed loop under the premise of controllable risks and reasonable capacity. The key execution parameters are as follows:
The upper limit of slippage per transaction is set at 0.25% by default, with a dynamic adjustment mechanism;
Path splitting depth: supports up to 8 segments, matched in order of path priority;
Transaction delay control: T_w (waiting time) < 300ms, T_b (block confirmation) < 2s;
Daily fund rotation frequency limit (T_max): set to 15 times;
Maximum position exposure for the same asset: shall not exceed 12% of the system's allocated funds.
Trading behaviors are executed in accordance with the above constraints. Any operation that deviates from the preset risk threshold will be automatically terminated by the strategy scheduler, ensuring that the system has engineering-level stability and long-term compounding capabilities.
3.6.4 Revenue Structure and Evaluation System
AIBat’s daily return (R_day) can be formally expressed as:
in:
α i : Net α of the ii-th trading opportunity;
A i : the amount of funds allocated to the opportunity;
C gas : total gas cost;
L slippage : Profit loss caused by slippage.
In addition, to improve the verifiability and external transparency of the system, AIBat regularly outputs key indicators through the state writeback module, including:
Total number and distribution of intraday trades;
Average alpha and percentile of successful trades;
Slippage average, extreme values and standard deviation;
System capital utilization and short position cycle distribution;
Strategy win rate, attribution of failure reasons and transaction hierarchy.
These indicators not only serve system tuning, but also provide data support for subsequent strategy ratings, user transparency and institutional interface integration.
3.7 PoLW Consensus Mechanism
PoLW (Proof of Liquidity Weight) is the core consensus mechanism supporting the operation of the BAT architecture. Its core goal is to deeply bind user asset liquidity, transaction behavior data and profile data to the system operation logic through a two-dimensional mining model of "capital contribution + data-driven", thereby realizing a new consensus paradigm of "capital as fuel, data as power, and behavior as consensus".
In the PoLW mechanism, users participate in the system in two core ways:
Liquidity injection - depositing funds into the BAT system to provide in-depth protection for on-chain matching and transaction execution;
Behavioral data generation - User's transaction instructions, operating habits, portrait features and other behavioral data will directly enter the AIBat system as the original input for model training and execution optimization.
Users can earn sBAT (liquidity time tokens) during the participation process. The value of sBAT is derived from the lifespan of the funds, the efficiency of their use, and the degree of their data contribution. At the same time, the income generated during the operation of the platform will be dynamically distributed between users and the protocol according to the PoLW weight.
3.7.1 Scoring and Incentive Formula
PoLW performs a standardized evaluation of users’ comprehensive contributions, which is defined as follows:
in:
L (u) : User’s liquidity contribution factor (based on fund size and time weighting, refer to the liquidity time proof formula);
D (u) : user data contribution factor (transaction frequency, profile feature richness, model effectiveness feedback, etc.);
I (u) : User interaction behavior factor (number of strategy executions, protocol call depth, tool usage, etc.);
α, β, γ: Dynamically adjusted weight coefficients, adjusted according to the system development stage, market status and protocol governance strategy.
The final S PoLW will serve as:
sBAT mining output weight (determines the user's reward share within the cycle);
Governance weight (influences governance voting and proposal priority);
Equity level (unlocks higher-level strategy entry or AI Bot functionality).
3.7.2 Liquidity Time Certificate (sBAT)
To more clearly measure the combination of funds and time, PoLW introduces the concept of Liquidity Time Certificate (sBAT), which is calculated as follows:
in:
A j : the size of the jth deposit;
T j : The duration of the funds (unit: days).
sBAT will serve as the user's basic equity certificate in the protocol and will be used to:
Prove users’ long-term financial support for the system;
Binding data contribution behavior and reward distribution;
Use directly in revenue distribution, governance voting, and function unlocking.
3.7.3 Interaction Logic between Users, AIBat, and the System
Under the PoLW consensus mechanism, the entire process forms a two-way drive closed loop:
User side: deposit funds, conduct transactions, and generate data;
Protocol side: Inject funds into the matching pool to ensure depth, and input data into AIBat for model training and decision optimization;
System side: AIBat operation results improve matching efficiency, reduce slippage, optimize transaction paths, and thus increase overall profits;
Feedback: Revenue is distributed to users according to their S PoLW weights. Users receive sBAT and participate in governance.
Cyclic evolution: As funding scale and data contribution increase, AIBat model training becomes more accurate, system operation efficiency improves, and user participation willingness is further enhanced.
Last updated