Research Summary: Towards private on-chain algorithmic trading


The research aim was to present a system for automating trading on blockchains that promotes minimized trust without losing its competitive advantage by divulging too much information.

  • This paper introduces CHAINBOT which partitions algorithmic computation into on-/off-chain components to provide a measure of end-to-end integrity while preserving algorithmic parameters.
  • CHAINBOT stores public parameters of parametrized trading algorithms on-chain, but keeps parameters critical to algorithm performance private by storing them off-chain.
    • CHAINBOT returned up to 2.4x and, on average, 1.4x in a “buy and hold strategy.”
    • Across 1000 runs, the end-to-end average execution time for the CHAINBOT system was 48.4 seconds.
    • The frequency of trading did not significantly affect the rate of return, as its Sharpe ratio demonstrated. This implies that transactions do not have to take place at every block on-chain, saving significant amounts of gas.

Core Research Question:

What is a possible architectural design for a hybrid on-chain/off-chain trading algorithm that is trust minimized and transparent, yet able to execute without sacrificing its competitive advantage due to privacy loss?


Blockchain Pseudonymity:

  • Bitcoin transactions are publicly visible, yet their blockchain maintains a degree of anonymity (“pseudonymity”). This anonymity has limits.

    • The original Bitcoin Whitepaper describes the concept: “Privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone… Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner” [1]
  • This introduces the idea that all peer to peer (P2P) interactions on a non-private blockchain may be captured and used to undermine user privacy.

  • As per Xia, Pengcheng et al’s example of identifying tokens on Uniswap [2], which is a decentralized exchange (DEX), pseudonymity can be used by malicious actors to undermine blockchain ecosystems.

On-Chain/Off-Chain Tradeoffs:

  • Layer-2 (L2) protocol blockchains can improve scalability by carrying out transactions off-chain by either:
    • submitting a smaller number of proofs than the actual number of transactions, [16]
    • or having off-chain transactions batched in a fraud or zero-knowledge proof before submitting to chain [9]
  • These solutions do not fully preserve privacy, because transaction data remains available to some participants or revealed in case of dispute.
  • StarkEx L2 solutions keep computation and data off-chain, however this may create a “data availability problem.” Those who do not have access to transaction data cannot reconstruct the state.[3]
  • The current solution is to pass data availability verification tasks to a Data Availability Committee (DAC), which is not fully private.

Off-Chain Computation - Blockchain Privacy:

  • Computational tasks can be outsourced in a privacy-preserving way, however, disputed data should be made public since “fraud proofs” are used.[23]
  • Mixing cryptography and incentivization may be a means to achieving privacy with off-chain computation.
  • This still comes at the cost of losing the intrinsic trustlessness of the blockchain.
  • Efforts to replace trusted entities with multi-party computation (MPC) exist but computation on encrypted data is a significantly costly task.

Privacy-focused L1s:

  • Privacy-preserving payment protocols offer confidential transactions but are not viable for general computation [21]
  • Blockchains designed with privacy considerations,such as Zerocash[21], Zcash[17], Solidus[10], Monero[20] and several others [12,24,19,8,14] may enable privacy but introduce complexity during integration with existing platforms and features.
  • Privacy-focused chains have been subject to deanonymization attacks in recent years and may not be able to guarantee privacy. [6,27,11,26]

Blockchain Automated Trading:

  • Machine learning can be used for Bitcoin price prediction[22] or outputting portfolio vectors[18], automating bitcoin trading, and executing high-frequency trading[25]
  • Another study shows high-frequency trading can occur in an adversarial form, using deterministic Automated Market Maker DEXes.[28]


Private On-Chain Algorithmic Trading:

  • Using a trading algorithm on-chain eliminates the need for trust,
    • Users of on-chain bot can audit a trading algorithm
    • Funds are stored in smart contract while users keep full control of their money
  • Conversely, a bot will lose its competitive advantage if its algorithm is open to the public (on-chain).
  • CHAINBOT makes public parameters of parametrized trading algorithm on-chain, but keeps parameters critical to algorithm performance private by storing hemt off-chain.
    • Private parameters can be re parameterized off-chain to market conditions.
    • Zero-knowledge proofs can be used to verify that an on-chain algorithm runs smoothly
    • Trades should be executed privately.

System Components - CHAINBOT has multiple on-chain/ off-chain elements in these categories

  • On-Chain bot. Smart contract to obtain parameters (price, financial indicators etc.)

  • Off-Chain bot. Trains algorithm, stores private parameters, decides and executes trades

  • Proof system. On-chain verifier, off-chain proof generator

  • L2 privacy-enhancing DEX. E.g DeversiFi

  • On-Chain oracle. Uniswap or ChainLink

    Conditions of user subscriptions

  • Subscribes to CHAINBOT by sending funds to on-chain bot

  • On-chain bot records amount invested

  • On-chain bot uses pooled user funds

  • Once trading epoch completed, on-chain bot pays user share of returns

Algorithmic Training

  • (Bollinger Bands(BBs) trading algorithm)[7], confidence interval of standard deviations of simple moving average, enveloping upper Bollinger Band and lower Bollinger Band.

  • Trading strategy is simple yet powerful

  • Suitable for parameterization

Trust Assumptions

A1: Blockchain security. Ignore ramifications of blockchain forks and assume that participants are honest. [15]

A2: Validity of trusted setup. Verification/proving keys created during a “generation ceremony,” involving MPC, used for “trusted setup.” [4,5]

A3: Off-chain bot fund integrity. Integrity assumption does not include off-chain bot executions but assumes users can verify flow of funds via querying blockchain ledger.

A4: DEX integrity. Assumes privacy enhancing DEX enables ensuring trades correctly executed on verified financial decisions. Further assumes DEX provides full privacy or shared data are impartial and honest.

A5: DEX privacy. Assumes DEX enable trades that does not reveal trade type (e.g asset pair), sources, destinations, and amounts to blockchain observers.

A6: Oracle integrity. Assumes on-chain price oracle provides accurate data.

Threat Analysis - End to end trading integrity

  1. Verify correct public parameter values used in trade decisions (assume A1,A2)
  2. Guarantee private parameters included correctly to algorithm via zero-knowledge proof (assume A1)
  3. Ensures trading decisions based on correct asset pricing (assume A6)
  4. Ensures trades executed on trading decisions align on assumption that DEX provides verification that does not damage user privacy (assume A3,A4,A5)

Threat Analysis - Algorithmic privacy

(Designed to prevent end-to-end integrity threads to bot and theft of trading algorithm)

  • CHAINBOT uses parameterized algorithms of parameters kept off-chain thus cannot be easily stolen or replicated.
  • Reliance on private DEX makes reverse engineering parameters impossible.
  • Uses assumption A3, A5.



  • Zenbot off-chain cryptocurrency trading bot with backtesting features was used.
  • Historical data ETH-USDC price from August 2020 to August 2021 from Poloniex exchange.


  • Grid search optimization for top-performing parameters

  • (
    1 ≤ Moving average period size ≤ 40,
    1 ≤ standard deviations ≤ 6,
    −1 ≤ Upper Bollinger band ≤ 30,
    −1 ≤ Lower Bollinger band ≤ 30

  • Many factors can be of varying importance in given context therefore no single method of determining trading algorithms success.

  • Thus “Sharpe ratio” and average return is used to score parameter configurations.


  • On average 1.4x return from gridsearch top params.
  • On average return only 0.6 using Sharpe ratio configurations with lower standard deviation.
  • Average return configuration aims to maximize return.
  • Sharpe ratio additionally takes risk in to consideration.
  • All parameter configurations performed better than “buy and hold” strategy.


This paper makes the following contributions:

  • Combining on-/off-chain. CHAINBOT combines on-chain integrity/ transparency and off-chain privacy execution. Off-chain integrity is maintained via zero-knowledge proofs based on Zokrates.[26]
  • Parameterized algorithms. (Public) code of bot parametrized by (confidential) parameters from training historical data
  • Confidential trading. Private L2-based decentralized exchange, on-chain oracles for price data.
  • Experimental evaluation.
    • Training data - ETH:USDC price historical data
    • Yield 2.4x, average 1.4x with “buy and hold” strategy as a baseline.
    • Latency of 48.4 seconds per end to end trade execution.
    • Frequency does not affect return significantly (reduced gas fees).
    • Cost analysis: able to sustain continuous trading amortized cost $0.15 per user on the user base of 1000 people (on basis where simulations were conducted across 1000 “runs”).

End-to-end Performance - Time measurements

  • Performed on local machine(2-core Intel i5-5257U CPU, clocked at 2, 7GHz, with 8GB RAM, 256 GB SSD).
  • Off-chain proof generation took least about of time, 0.2-0.8 seconds of 48.4 seconds total.
  • Takes 22.8 average seconds to get public parameters, retrieve price from oracle and calculate the Bollinger bands.
  • Verification of off-chain bots zero-knowledge proof decision averages 23 seconds
  • Takes 2.3 seconds to execute actual trade on DeversiFi

End-to-end Performance - Gas costs

  • 281715 steady gas for on-chain bot and retrieving price from on-chain oracle.
  • Verifier contract’s calculations gas usage slightly varies among calls, average 191687 gas.
  • Average gas cost of end to end execution is around 004592 ETH = ~$150 USD as of 28.08.2021.

End-to-end Performance - Frequency of execution

  • Trained and tested Bollinger algorithm in 1 minute, 10 minutes, and 1 hour trading periods.
  • Inverse relationship between trading period length and mean relative returns, but difference is less than 2%.
  • Lower trading periods may lead to higher standard deviation.
  • Trading less often might make returns with lower risk and may be used to lower gas cost

End-to-end Performance - Summary

  • Average 48.4 seconds end-to-end execution
  • Around 473402 gas
  • Frequency of execution does not affect rate of return significantly

Sample Anecdote:
“An average user willing to invest $1000 with CHAINBOT would earn $105 while spending $3 on gas; this assumed a user pool of 1000 subscribers. Average execution time is 48.4 seconds end to end per trade. “

Implication and Follow-ups:


  • Assets prices may change in the course of a trade and might cause a discrepancy in the trading algorithm’s expected and realized trade decisions.
  • Further research is needed for a systematic understanding of these effects.

Off-Chain Integrity Concerns

  • StarkEx and DeversifFi are ways of verifying transactions included in the proof batch by having access to sequencer data.
    • Thus there is no direct way of verifying an off-chain bot’s trade decisions.
    • A supervising committee can be appointed to observe an off-chain bot’s trade decisions/executions.
    • There exists a trade-off between making confidential information available to committee members and establishing end to end integrity.

Programming Language

  • Implementation requires use of multiple programming languages.
    • This can be hard to maintain or fragile.
    • Creating a programming language expressive enough that it can be compiled/transpiled to other languages to increase robustness/practicality of deployment/maintenance of bot, preventing data leaks with type checking.

Discussion and Key Takeaways:

The research aim was to present a system for automating trading on blockchains that promotes minimized trust without losing its competitive advantage by divulging too much information. CHAINBOT partitions the trading process using a hybrid on-/off-chain approach as well as zero-knowledge proofs to maintain end-to-end integrity and privacy-enhancing DEXs. This is to prevent trades from being mirrored and private parameters from being reverse-engineered.


Based on the performant results of CHAINBOT, it is evident that a hybrid on-chain/off-chain approach is a viable and cost-effective method of building algorithmic trading systems on the blockchain.


“Towards private on-chain algorithmic … -,” arXiv:2109.11270 . [Online]. Available: [Accessed: 10-Oct-2021].

[1]Nakamoto, S. (2008) Bitcoin: A Peer-to-Peer Electronic Cash System. 10. Privacy

[2]Xia, Pengcheng et al. “Demystifying Scam Tokens On Uniswap Decentralized Exchange”. Arxiv.Org, 2021, [2109.00229] Trade or Trick? Detecting and Characterizing Scam Tokens on Uniswap Decentralized Exchange.

[3] StarkEx: Powering scalable self-custodial transactions, StarkEx - Starkware. Accessed: 2021-09-06

[4]Zcash parameter generation, Parameter Generation - Zcash. Accessed: 2021-09-06

[5]Baumann, N., Steffen, S., Bichsel, B., Tsankov, P., Vechev, M.: zkay v0.2: Practical data privacy for smart contracts. arXiv preprint arXiv:2009.01020 (2020)

[6]B ́eres, F., Seres, I.A., Bencz ́ur, A.A., Quintyne-Collins, M.: Blockchain is watching you: Profiling and deanonymizing ethereum users. arXiv preprint arXiv:2005.14051 (2020)

[7]Bollinger, J.: Using bollinger bands. Stocks & Commodities (1992)

[8]B ̈unz, B., Agrawal, S., Zamani, M., Boneh, D.: Zether: Towards privacy in a smart contract world. In: International Conference on Financial Cryptography and Data Security. Springer (2020). 23

[9]Buterin, V.: An incomplete guide to rollups (May 2021), An Incomplete Guide to Rollups

[10]Cecchetti, E., Zhang, F., Ji, Y., Kosba, A., Juels, A., Shi, E.: Solidus: Confidential distributed ledger transactions via PVORM. In: ACM SIGSAC Conference on Computer and Communications Security (2017).

[11]Chervinski, J.O.M., Kreutz, D., Yu, J.: Floodxmr: Low-cost transaction flooding attack with monero’s bulletproof protocol. IACR Cryptology ePrint Archive, (2019),

[12]Danezis, G., Fournet, C., Kohlweiss, M., Parno, B.: Pinocchio coin: building Zerocoin from a succinct pairing-based proof system. In: The First ACM workshop on Language support for privacy-enhancing technologies (2013).

[13] Eberhardt, J., Tai, S.: Zokrates - scalable privacy-preserving off-chain computations. In: IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData). IEEE (2018). 2018.2018.00199

[14]Fauzi, P., Meiklejohn, S., Mercer, R., Orlandi, C.: Quisquis: A new design for anonymous cryptocurrencies. In: International Conference on the Theory and Application of Cryptology and Information Security (2019). 23

[15]Gervais, A., Karame, G.O., W ̈ust, K., Glykantzis, V., Ritzdorf, H., Capkun, S.: On the security and performance of proof of work blockchains. In: Proceedings of the 2016 ACM SIGSAC conference on computer and communications security. pp. 3–16 (2016)

[16]Gudgeon, L., Moreno-Sanchez, P., Roos, S., McCorry, P., Gervais, A.: Sok: Layer-two blockchain protocols. In: International Conference on Financial Cryptography and Data Security. Springer (2020). 12

[17]Hopwood, D., Bowe, S., Hornby, T., Wilcox, N.: Zcash protocol specification. GitHub: San Francisco, CA, USA (2016),

[18]jiang, Z., Liang, J.: Cryptocurrency portfolio management with deep reinforcement learning. In: IEEE Intelligent Systems Conference (IntelliSys) (2017). Cryptocurrency portfolio management with deep reinforcement learning | IEEE Conference Publication | IEEE Xplore

[19]Jivanyan, A.: Lelantus: Towards confidentiality and anonymity of blockchain transactions from standard assumptions. IACR Cryptology ePrint Archive (2019), Cryptology ePrint Archive: Report 2019/373 - Lelantus: Towards Confidentiality and Anonymity of Blockchain Transactions from Standard Assumptions

[20]Noether, S.: Ring signature confidential transactions for Monero. IACR Cryptology ePrint Archive (2015), Cryptology ePrint Archive: Report 2015/1098 - Ring Signature Confidential Transactions for Monero

[21]Sasson, E.B., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., Virza, M.: Zerocash: Decentralized anonymous payments from Bitcoin. In: IEEE Symposium on Security and Privacy (SP) (2014). Zerocash: Decentralized Anonymous Payments from Bitcoin | IEEE Conference Publication | IEEE Xplore

[22]Shah, D., Zhang, K.: Bayesian regression and bitcoin. In: 52nd Annual Allerton Conference on Communication, Control, and Computing (Allerton) (2014). Bayesian regression and Bitcoin | IEEE Conference Publication | IEEE Xplore

[23] Teutsch, J., Reitwießner, C.: A scalable verification solution for blockchains. arXiv preprint arXiv:1908.04756 (2019)

[24]Van Saberhagen, N.: Cryptonote v 2.0 (2013),

[25]Vo, A., Yost-Bremm, C.: A high-frequency algorithmic trading strategy for cryptocurrency. Journal of Computer Information Systems (2020).

[26]Wijaya, D.A., Liu, J., Steinfeld, R., Liu, D.: Monero ring attack: Recreating zero mixin transaction effect. In: 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/ 12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE) (2018). Monero Ring Attack: Recreating Zero Mixin Transaction Effect | IEEE Conference Publication | IEEE Xplore

[27]Yousaf, H., Kappos, G., Meiklejohn, S.: Tracing transactions across cryptocurrency ledgers. In: 28th USENIX Conference on Security Symposium (2019).

[28]Zhou, L., Qin, K., Torres, C.F., Le, D.V., Gervais, A.: High-frequency trading on decentralized on-chain exchanges. In: IEEE Symposium on Security and Privacy (SP) (2021),

Further Implementation Details

This section describes implementation details of the system outlined in the “SUMMARY” section, A.1, A.2, A.3.

A.1 Algorithmic Training

  • Search function looking for top-performing parameter configurations from past training period and tested for ex-post performances.


  • Grid search for space of minimum, maximum and mean values of parameters results in a set C ← all parameter configurations obtained by the product of the sets of possible values.

A.2 Zokrates Interactions

  • [13] Zokrates is a programming language which specifies knowledge to be proven and acts as originator for verifier smart contract as well as proof generator.
  • CHAINBOT Zokrates program takes five parameters:
    • X(current price)
    • Upper BB(Bollinger Band)
    • Lower BB(Bollinger Band)s
    • Flag to signal buy or sell decision
    • “L” or “U” baked decision type
  • Proof from root program confirms prover made undisclosed trading decisions from hidden parameters where public parameters were obtained from on-chain bot.

Verifying public parameters.

  • It is possible to produce verifiable proof from parameters different than on-chain bot or algorithmic trainers.
  • It is necessary to implement a mechanism to ensure correct parameters used for proof generation.
  • Inputs to Zokrates program can be public or private.
    • Enables off-chain bot to feed public trading params into proof (as public parameters)
    • Enables on-chain bot to check that values included in proof are provided on-chain
    • If off-chain bot uses incorrect public parameters this will be visible in proof and proof-verification will fail.

Preventing information leaks

  • Single proof generator and verifier contract for all possible conditions for trade decision.
  • Trade decision needs be specified as private input in root Zokrates code.
    • Prevents being openly included in proof

Validating the verifier contract

  • Zokrates verification system based on Arithmetic Circuits and Rank 1 Constraint Systems (RICS)[13]
  • Verifier contract validation can be enabled by having root Zokrates code publicly accessible.
    • E.g. storing smart contract, compare to Solidity code with deployed smart contract

A.3 DiversiFi Interactions

Hiding CHAINBOT trade decisions is essential to protecting privacy of trading strategy.

  • To trade privately, a self-custodial order book exchange that uses L2 protocol for enhancing transaction privacy and speed, DeversiFi is used

Validium and transaction privacy

  • DeversiFi powered by Validium-based StarkEx scalability engine[3]
  • Validium is an L2 solution where multiple transactions are batched off-chain in single zero-knowledge proof and then verified on-chain.
  • Validium differs from ZK-rollups in storing entire data related to transactions off-chain.
  • Validium tries to solve data availability problem via “Data Availability Committee” (DAC)
    • Decentralized members hold copy of all off chain transaction data and sign commitments to every new state

Private trading on DeversiFi

  • Leverages Validium to hide trades from public
  • User funds stored in “token accounts” (vaults)
    • Each have unique ID
    • Hold single type of asset
    • Can be assigned to single user at given time
    • Merkle tree formed from token accounts, updated every time token accounts balance changes
    • Funds need be deposited to StarkEx smart contract before starting trading on DeversiFi
    • Deposited funds automatically recorded to user’s token account

-Trading happens entirely off-chain, maker-taker model

  • Maker signs order, including token types, amounts being traded, and maker’s account IDs for tokens

  • Taker executes trade, signing order along IDs of 2 corresponding token accounts

  • Amount subtracted from token account balance then added to their “on-chain withdrawal balance”

  • Enables direct withdrawal from StarkEx smart contract when user wants to withdraw funds from DeversiFi


  • DeversiFi does not provide a trustless trading platform.
  • Keeping trades private from other traders comes with cost of sharing with DAC
  • Users have to trust DeversiFi to include their transaction in proof and submit it onto the chain since DeversiFi operates the “sequencers”
  • If DeversiFi attempts to censor a user’s withdrawal request, users can retrieve their funds from StarkEx smart contract if they manage to acquire necessary data from DAC members

@Tony_Siu thank you so much for contributing this summary… I wanted to continue a conversation on the here that we began on Discord. You mentioned that algorithmic training on the blockchain has historically been very difficult – would you mind expounding on that subject a little bit? I’d also love to hear about how the architecture built off of previous work, what did you think was particularly interesting about this paper/bot? It certainly seemed to have made a lot of money during the simulation!

1 Like

@jmcgirk So essentially, there are 2 main axioms of concern. The first point of concern is and I quote from the paper itself;

Blockquote “On-chain trading has the advantage of full transparency favored by DeFI advocates and users, however, transparency kills the competitive advantage a trading algorithm might have over its competitors.”

The second point of concern would be and again I quote;

Blockquote “Running the algorithms off-chain, as crypto-trading bots … may enable privacy. However, without the transparency and integrity properties of on-chain execution, users have to trust the off-chain bots with executing trading algorithms and handling user funds correctly.”

So in light of these 2 axioms of concern, CHAINBOT, the subject of study in this paper provides a 3rd axiomatic perspective of a hybrid solution. By an attempt to integrate both on-chain data aggregation and data collection, then off-chain algorithmic parameterization and outputting of predictor variables back to on-chain execution via zero-knowledges proofs, this paper actually adds another layer of abstraction to the already complicated dichotomy.

In extension, one can then infer the many faults introducing this third axiom can imply. There are 6 assumptions that attribute this work to both being a possible solution and a new problem in its own right. These assumptions are of blockchain security, the validity of the trusted setup, the off-chain bot fund integrity, the DEX integrity, the DEX privacy and lastly, the oracle integrity. In my “humble” opinion, any one of these assumptions can be the downfall of this work in the real world already. Hence I say this, but this work is already a paradigm shift in and of itself.

On top of hard coding a defi arbitrage bot or needing developers to write customized algorithms, CHAINBOT introduces the idea of an integrated ML model admidst the application server side. In the advent of the “AI” revolution, blockchain being able to perform in tandem with AI in a single end to end application is a huge deal. CHAINBOT serves a pioneering anecdote that blockchain is indeed a potentially industry ready technology along side ML.

On another note, CHAINBOT also performs well with the long running gas price issues persistent in blockchain applications.Flash boys, another similar attempt at monetary arbitrage persisted with the same issue of gas price exploitation where stakeholders may as well execute arbitration solely to rack up gas prices for example. I quote;

Blockquote “In our implementation, an average user willing to invest $1000 with CHAINBOT would earn $105, while spending $3 on gas”

I think CHAINBOT is a good start on enabling algorthmic trading involving both ML and blockchain in a single end to end application. If CHAINBOT proves itself faultless, I would think a lot of money would be involved.


@Tony_Siu in one of our conversations you mentioned how interesting you thought it was that this bot performed so well on the historical data that it was tested on. Can you talk about how that might translate into real world performance, and what might get in the way of an exceptional model’s performance? I’d also love to hear about other applications for these hybrid systems

1 Like

@jmcgirk Of course! The real-world performance via applied statistical data science is actually my budding research work of which I’m conducting 2 pieces of primary research on with my research partner.

There are a couple of glaring points that I can mention on the get-go from a data science perspective. Firstly, CHAINBOT uses grid search optimization algorithms. This means the parameterization of the conventional Bollinger bands model is actually fitted and tested for all possible parameters with in the domain of discourse mentioned in this paper. Imagine the sheer needless computation CHAINBOT needs to undertake! Secondly, I surmise that a more rigorous statistical modeling can be applied for heuristical decision-making. The Bollinger band provides the conventional oscillation of the possible highs and lows “band” width that the current stock price is at. There needs to be a more appropriate evaluation testing metric to determine the performance of CHAINBOT. Last but not least, these issues are all not so prevalent in light of implications of data slippage. Asset price may change in the course of trade and might cause a discrepancy in perceived oscillation of the Bollinger band. This implies that within the 49 seconds or so time frame, the grid searched signal from the Bollinger algorithm may as well be irrelevant by the time of execution of the trade decision. On the flip side, the ML present in CHAINBOT is purely heuristical, which is great for a simple application such as real-time algorithmic trading. Computational AI models such as neural networks might just be too much processing to handle for the time being and may not produce the best of results.

On the note of proof of work, CHAINBOT uses off-chain protocols such as StarkEx and DeversiFi to verify transactions included in the proof batch. There is no direct way of verifying the off-chain bots’ trade decisions. A supervising committee can be appointed to observe CHAINBOTs trades but there exists a trade off between revealing confidential information to such supervising committee.

As a high-level insight, improvements for price slippage has more to do with the available networking technology of the blockchain to emulate real-time data input and output, applying more traditional statistical linear model theorems and limitations to the conventional bollinger band algorithm in general. To prevent slippage of data, one can take the application perspective and just design the application architecture to not have a discrepancy of the actual data be different than the CHAINBOTs execution, have modeling techniques that encompass such data slippages, or just even take a better UI/UX approach that nullifies the data slippage issue entirely by the applications product design. But these are only circumstantial considerations in the grand design of CHAINBOT.

I’m working on a Design of experiment that optimizes for multiple root factors and its interactions for the “classical calibration” problem. It will certainly be exciting to see the full potential of applied statistics in today’s computational oriented data science! Another research piece I’m working on is optimizing data preprocessing algorithms that can establish the appropriate empirical data relationship between the input data, training data and the testing data. This of which I can then explainably perform and enhance all computational ML and DL performance with out having to add additional unnecessary preprocessing or computational brute force optimizations such as the grid search optimization. Gonna be fun~

1 Like

@stayhungry07212 I would love it if you and @Tony_Siu could compare and contrast some of the features and architectural / privacy issues with the bots you’ve looked at (for reference, am thinking of Building an Arb Bot on Infura). I’d also be curious about any similarities with @tina1998612’s Coding a DeFi Arb bot

The paper mentions zero knowledge proofs as a possible pitfall based on an assumption during the on chain data going offchain and from offchain back to on chain execution. Could you expand on this?


@jmcgirk It would be my pleasure to expand on that subject of how going from on-chain to off-chain and back on chain would jeopardize the assumed trustless of the zero-knowledge proof in this work!

First of all to clarify the pitfall of assumption 2, the validity of the trusted setup. In the trusted setup phase, verification and proving keys are created using zero-knowledge proof systems like zk-SNARKs. But since multiple parties are involved in the correctness of the proof of work for CHAINBOT, a Multi-party computation ceremony is assumed to be appropriate for a trusted setup.

Then for assumption 3, the Off-chain bot fund integrity. The authors of CHAINBOT assumes that the off-chain component of CHAINBOT will manage user funds without malicious conduct and perform trades according to the market rules and regulations. However, these assumptions does not necessarily imply that the trades CHAINBOT makes will be according to the trading algorithm.

So to clarify a bit. Data is collected, aggregated and trades executed in the on-chain bot component. Parameterizing of the bollinger band algorithm and the decision is being made off-chain. The decisions made and the underlying operations that the off-chain bot can potentially introduce may not be fully trustless as there are multiple participants of the CHAINBOT framework. The only way to make sure that a trade is included in a proof batch of CHAINBOTs proof verification component is to have access to the sequencer data. Users on-chain have no direct way to gain access to that sequencer data with current systems available so a tradeoff of a third party committee that has access to the sequencer data may be needed.

1 Like