DEV Community: Raghuvansh

I Audited My Own DeFi Protocol — Here's Every Bug I Found (And How I Fixed Them)

Raghuvansh — Fri, 10 Apr 2026 10:18:50 +0000

"The scariest thing about writing smart contracts isn't that the code is complex. It's that the code looks fine — right until the moment it isn't."

Let me set the scene.

It's late. You've been writing Solidity for weeks. Your stablecoin protocol is deployed on testnet. The frontend works. Transactions go through. Users can deposit collateral, mint tokens, earn yield. Everything looks beautiful.

And then a quiet voice in the back of your head whispers: "But have you actually checked?"

That voice is your best friend. I listened to it. And what it led me to find, buried inside code I had written myself, code I had stared at for hours, genuinely surprised me.

This is the story of how I audited Merix Holdings, my own decentralized stablecoin protocol, using two of the most powerful static analysis tools in the Solidity ecosystem: Slither and Aderyn. I found bugs ranging from a high-severity reentrancy hole to a math mistake that could have liquidated innocent users too early. I'll show you every single one, in plain language, with real code.

Buckle up.

Wait, What Even Is Merix?

Before we get into the bugs, let me give you thirty seconds of context.

Merix is a decentralized, overcollateralized stablecoin protocol built on Ethereum (currently deployed on the Sepolia testnet). Here's the whole thing in three bullet points:

You deposit WETH or WBTC as collateral into the protocol.
The protocol lets you mint DSC (a USD-pegged ERC-20 stablecoin) against that collateral.
The system enforces a 200% collateralization ratio at all times. If your position drops below that, anyone can liquidate you and earn a 10% bonus.

On top of that core engine, I built two extra pieces:

A YieldAggregator: an ERC4626-style vault where users deposit DSC and earn simulated yield (think: strategy-based APY).
A RedemptionContract: a clever mechanism that converts your realized yield profits directly into WETH collateral, improving your health factor without you having to do a separate deposit.

Five smart contracts. 513 lines of production code. One internal security review.

Here's everything that went wrong.

The Audit Setup: What Tools Did I Use?

I ran three layers of analysis:

1. Manual Line-by-Line Review

I went through every contract function by function, asking myself: "How would I steal from this?" I checked for reentrancy, bad math, access control gaps, oracle manipulation, and logic errors against the protocol spec.

2. Slither (Trail of Bits)

Slither is a static analysis framework with over 100 detectors. It reads your Solidity AST and finds patterns that match known vulnerability classes: unchecked return values, reentrancy, divide-before-multiply, and more.

slither . --filter-paths "test|lib|script"

3. Aderyn (Cyfrin)

Aderyn is a newer Rust-based static analyzer from the team at Cyfrin, the same people behind Codehawks and security research in the DeFi space. It has a cleaner output format and catches a slightly different set of patterns than Slither.

aderyn --output aderyn-report.md .

4. Fuzz + Invariant Testing (Foundry)

This wasn't just static analysis. I wrote 135 tests including:

32 stateless fuzz test functions (1,000 runs each locally)
A full invariant campaign with 256 sequences × 100 calls deep
20 invariant properties that had to hold across all of them

Now let's get to the good part.

Finding #1: The Reentrancy Bug I Almost Missed

Severity: HIGH | Status: Fixed

Here's a fun psychological trick: when you write a function and add nonReentrant to it, your brain says "okay, that's safe" and moves on. That's exactly what happened to me.

The function depositToStrategy in YieldAggregator.sol had nonReentrant on it. But the lock only works if it's active before the external call happens. My original code did this:

// THE VULNERABLE VERSION
function depositToStrategy(uint256 strategyId, uint256 amount) external nonReentrant {
    _harvestAll();

    uint256 sharesToMint = ...;

    // First, update some state...
    totalShares += sharesToMint;
    totalAssets += amount;
    userShares[msg.sender] += sharesToMint;
    userPrincipal[msg.sender] += amount;
    userStrategyDeposited[msg.sender][strategyId] += amount;

    // Then make the external call...
    dsc.transferFrom(msg.sender, address(this), amount);

    // Then update the REST of the state -- AFTER the external call
    strategies[strategyId].totalDeposited += amount;  // <-- THIS IS THE PROBLEM
}

Did you catch it?

strategies[strategyId].totalDeposited was being updated after the external transferFrom call. This is a violation of the Checks-Effects-Interactions (CEI) pattern, one of the oldest rules in Solidity security.

Here's why this matters. During the transferFrom callback window, if an attacker could somehow re-enter the contract (say, via a malicious token or a cross-function call), they would read strategies[strategyId].totalDeposited as zero, because it hasn't been updated yet. The yield harvest math would then return zero yield for that strategy, distorting share prices for every depositor in the vault.

Both Aderyn (H-1) and Slither (reentrancy-no-eth) independently flagged this. The fix was simple: move all state updates above the external call.

// THE FIXED VERSION
// All state changes happen BEFORE the external call
strategies[strategyId].totalDeposited += amount;

// Now the external call is last -- nothing can read stale state
dsc.safeTransferFrom(msg.sender, address(this), amount);

Lesson learned: nonReentrant is not a magic wand. CEI is still the law.

Finding #2: The Silent Money Thief — Unsafe ERC20

Severity: HIGH | Status: Fixed

This one is sneaky because the code looks completely reasonable.

Across three contracts (DSCEngine, YieldAggregator, and RedemptionContract), I was using raw ERC-20 calls like this:

// Looks fine, right?
bool success = IERC20(tokenCollateralAddress).transferFrom(msg.sender, address(this), amountCollateral);
if (!success) { revert DSCEngine__TransferFailed(); }

// Or even worse -- no check at all:
dsc.transferFrom(msg.sender, address(this), amount);
dsc.transfer(msg.sender, dscAmount);

Here's the dirty secret of the ERC-20 standard: not all tokens follow it correctly.

Some tokens (USDT being the most famous example) don't return a boolean from transfer. Some return false on failure instead of reverting. If you call .transferFrom() on one of these tokens without using SafeERC20, the call silently does nothing, but your contract happily records the deposit as if it succeeded.

Imagine a user deposits 1,000 WETH as collateral. The transfer silently fails. But the contract says they have 1,000 WETH deposited. They mint DSC against it. They've essentially printed money from nothing.

All three contracts had this across 11 different call sites. Slither's unchecked-transfer detector and Aderyn's L-12 both lit up like a Christmas tree.

The fix: replace every raw transfer with OpenZeppelin's SafeERC20. And for approvals, use forceApprove instead of approve to handle the USDT-style approval reset pattern.

// The right way
using SafeERC20 for IERC20;

IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
IERC20(token).safeTransfer(to, amount);
IERC20(token).forceApprove(spender, amount);

Finding #3: The Math Bug That Could Liquidate You Early

Severity: MEDIUM | Status: Fixed

This one is my personal favourite because it's so subtle that you can stare at the formula and think it's correct. And mathematically, it is. But in Solidity, integer division truncates, and the order of operations matters enormously.

The health factor formula in _calculateHealthFactor originally looked like this:

// THE BUGGY VERSION
uint256 collateralAdjustedForThreshold =
    (collateralValueInUsd * LIQUIDATION_THRESHOLD) / LIQUIDATION_PRECISION;

return (collateralAdjustedForThreshold * PRECISION) / totalDscMinted;

See the issue? It divides first, then multiplies. In real math, this is fine. In Solidity, the first division truncates the result to an integer, destroying precision before the second multiplication can recover it.

Here's a concrete example:

collateralValueInUsd = $1,500 (in wei scale: 1500e18)
LIQUIDATION_THRESHOLD = 50
LIQUIDATION_PRECISION = 100

Step 1: (1500e18 * 50) / 100 = 750e18 ✓ (this happens to be exact here)

But with smaller numbers near the boundary, the truncation rounds down aggressively. A user with a true health factor of 1.01 might get computed as 0.99, and suddenly they're liquidatable when they shouldn't be.

A user losing their 10% liquidation bonus collateral for no reason is not a rounding error. It's a financial loss caused by a math ordering mistake.

The fix is one line: combine all the multiplications first, then do a single division at the end.

// THE FIXED VERSION
return (collateralValueInUsd * LIQUIDATION_THRESHOLD * PRECISION)
    / (LIQUIDATION_PRECISION * totalDscMinted);

Maximum multiplication first, single division last. Precision preserved.

Finding #4: The "Invisible Window" Reentrancy

Severity: MEDIUM | Status: Fixed

Remember how I said nonReentrant isn't magic? Here's another proof.

The function redeemCollateralForDsc lets users burn their DSC and get their collateral back in one transaction. The original code did this:

// THE VULNERABLE VERSION
function redeemCollateralForDsc(address token, uint256 collateral, uint256 dscToBurn) external {
    burnDsc(dscToBurn);        // <-- no nonReentrant, lock NOT held
    redeemCollateral(token, collateral); // <-- lock acquired HERE
}

The problem: burnDsc is a public function with no nonReentrant modifier. Inside burnDsc, there's a call to DSC.transferFrom, an external call. During that external call, the reentrancy lock is not held.

An attacker with a DSC token that has transfer hooks (or a future upgraded DSC token) could:

Call redeemCollateralForDsc(weth, largeAmount, smallDSC)
During the DSC.transferFrom inside burnDsc, re-enter redeemCollateral directly
At this point, s_DSCMinted is already decremented (debt looks paid off), but s_collateralDeposited is not yet decremented
Health factor check passes; attacker withdraws collateral for free
They've essentially redeemed collateral twice for the cost of one burn

The fix: stop calling public functions from within each other. Use internal functions under a single nonReentrant guard:

// THE FIXED VERSION
function redeemCollateralForDsc(
    address tokenCollateralAddress,
    uint256 amountCollateral,
    uint256 amountDscToBurn
) external nonReentrant moreThanZero(amountCollateral) moreThanZero(amountDscToBurn) {
    _burnDsc(amountDscToBurn, msg.sender, msg.sender);    // internal
    _redeemCollateral(tokenCollateralAddress, amountCollateral, msg.sender, msg.sender); // internal
    _revertIfHealthFactorIsBroken(msg.sender);
}

One lock. One atomic operation. No windows.

The "Small" Things That Add Up

Not every finding is a catastrophic money-printer exploit. Here's a rapid-fire tour of the lower-severity stuff, because in security, the small things are how you tell if a codebase is mature.

`nonReentrant` Was in the Wrong Position

Six functions had nonReentrant listed after other modifiers like moreThanZero and isAllowedToken. The rule: nonReentrant must be first. If any modifier before it makes an external call, reentrancy protection doesn't kick in in time.

// WRONG ORDER
function depositCollateral(...) public moreThanZero(amount) isAllowedToken(token) nonReentrant { }

// CORRECT ORDER
function depositCollateral(...) public nonReentrant moreThanZero(amount) isAllowedToken(token) { }

Setting Address to Zero Could Brick the Protocol

setRedemptionContract in both DSCEngine and YieldAggregator accepted address(0) without reverting. If the owner accidentally called it with a zero address, the onlyRedemptionContract modifier would permanently block all redemption flows. The protocol would be bricked with no upgrade path.

Fix: one line.

if (rc == address(0)) revert DSCEngine__ZeroAddress();

Missing Events Everywhere

Six critical state-changing functions, including mintDsc, burnDsc, setRedemptionContract, and deductRealizedProfit, emitted no events. This means off-chain monitoring, indexers like The Graph, and analytics dashboards are completely blind to what's happening. You can't build a frontend alert system on silence.

Fixed by adding dedicated events: DscMinted, DscBurned, DscBurnedExternal, RedemptionContractSet, ProfitDeducted.

The Gas Waste Inside Loops

Three loops were reading .length from a storage array on every single iteration:

for (uint256 i = 0; i < s_collateralTokens.length; i++) { ... }

Every .length call on a storage array costs an SLOAD (2,100 gas cold, 100 gas warm). If you have 10 collateral tokens, that's 10 extra storage reads per function call. Cache it:

uint256 len = s_collateralTokens.length;
for (uint256 i = 0; i < len; i++) { ... }

Magic Numbers in the Math

The yield formula had 10_000 (basis points divisor) scattered across multiple places as a raw literal:

yieldAmount = (s.totalDeposited * s.apyBps * elapsed) / (365 days * 10_000);

If you need to change it later, you have to find every instance. Replace with a constant:

uint256 private constant BPS_DIVISOR = 10_000;

What the Tools Found That I Had to Ignore (False Positives Are Real)

Security tools are not perfect. They flag patterns, and some of those patterns are fine by design.

Strict equality in _harvestStrategy:

if (s.totalDeposited == 0 || elapsed == 0) return 0;

Slither flagged this as "dangerous strict equality." But here, both values are internal; no attacker can force totalDeposited to be exactly zero during an attack in a way that changes the outcome. The check is intentional and correct. Acknowledged and documented.

Divide-before-multiply in share math (M-03):

uint256 sharesToBurn = (dscAmount * totalShares) / totalAssets;
uint256 principalReduction = (sharesToBurn * userPrincipal[msg.sender]) / userShares[msg.sender];

This is inherent to ERC4626-style accounting. The precision loss is bounded at 1 wei per operation and doesn't accumulate across users in an exploitable way. Acknowledged.

Knowing when not to fix something is just as important as knowing what to fix.

The Test Suite: Because Static Analysis Is Only Half the Story

After fixing all the high and medium issues, I ran a full test campaign:

Metric	Result
Total tests	135
Fuzz test functions	32 (1,000 runs each)
Invariant sequences	256 (100 calls deep)
Invariants verified	20
Tests passing	135/135

Selected invariants that had to hold no matter what:

The protocol must always be overcollateralized: total collateral value at or above total DSC minted × 2
No user's health factor can drop below 1.0 unless they are being liquidated in the same transaction
Total DSC supply must match ghost accounting across all mint/burn operations
The YieldAggregator's totalAssets can never decrease during a deposit-only sequence
The RedemptionContract's WETH reserve is always bounded by cumulative redemptions

Final coverage:

Contract	Line Coverage	Function Coverage
DSCEngine.sol	93.80%	91.67%
OracleLib.sol	100.00%	100.00%
RedemptionContract.sol	100.00%	100.00%
DecentralizedStableCoin.sol	85.71%	100.00%
YieldAggregator.sol	85.19%	93.33%

What I'm Still Watching (Known Risks)

Being honest in a security review means talking about what you didn't fully solve.

Oracle single point of failure. The protocol uses Chainlink with a 3-hour staleness timeout. If Chainlink goes dark for 3+ hours, the protocol freezes. A secondary oracle (Uniswap TWAP) or a graceful circuit-breaker would add resilience.

Single-owner centralization. Both DSCEngine and YieldAggregator are controlled by a single EOA. That's fine for testnet. On mainnet, that needs to be a Gnosis Safe multisig.

WETH reserve depletion in RedemptionContract. If everyone redeems at once, the WETH reserve drains with no rate limit. A per-epoch cap would protect against this.

No upgrade path. The contracts are not upgradeable. Any future fix means a full redeployment and user migration. That's a deliberate design choice, but it needs a documented migration procedure.

What Slither and Aderyn Feel Like to Actually Use

One honest observation for anyone picking up these tools for the first time:

Slither is the veteran. It's been around since 2018, has 100+ detectors, and integrates deeply with the Solidity AST. It's noisy, and you will get false positives. But the signal it gives you on real bugs (H-01, H-02, M-01, M-02) is worth the noise filtering.

Aderyn is the newcomer with better UX. Its report is cleaner, the Markdown output is beautiful for sharing with your team, and it caught the same H-1 reentrancy independently which gave me double confidence. It's also faster to run.

Run both. They don't perfectly overlap. The union of their findings is more complete than either alone.

And neither of them replaces manual review. The reentrancy window in redeemCollateralForDsc (M-02)? The tools caught the surface-level pattern. But understanding why it was dangerous, the specific attack sequence, the economic impact, required thinking like an attacker.

The Final Scorecard

ID	Issue	Severity	Status
H-01	Reentrancy in `depositToStrategy` (CEI violation)	High	Fixed
H-02	Unsafe ERC20 operations across all contracts	High	Fixed
M-01	Divide-before-multiply in health factor formula	Medium	Fixed
M-02	Reentrancy window in `redeemCollateralForDsc`	Medium	Fixed
M-03	Divide-before-multiply in share math	Medium	Acknowledged
L-01	Missing zero-address check on `setRedemptionContract`	Low	Fixed
L-02	Missing events on critical state changes	Low	Fixed
L-03	Storage array length not cached in loops	Low	Fixed
L-04	`nonReentrant` not first modifier	Low	Fixed
L-05	Strict equality in `_harvestStrategy`	Low	Acknowledged
I-01	Unused oracle return values	Info	Acknowledged
I-02	`OracleLib` function visibility	Info	Fixed
I-03	Magic literal `10_000` in yield math	Info	Fixed
I-04	Uninitialized local variable `newYield`	Info	Acknowledged

No critical findings. Two high findings, both fixed. The protocol lives.

The Real Lesson

Here's what this whole exercise taught me, and I want you to sit with this.

I wrote every line of this codebase. I knew every function. I had stared at depositToStrategy probably fifty times. And I still had a high-severity CEI violation sitting right there, hidden by the false confidence of a nonReentrant modifier.

Security isn't about being smart. It's about being systematic. About running the tools even when you think you don't need to. About treating your own code with the same suspicion you'd treat a stranger's.

The tools (Slither, Aderyn, fuzz tests, invariants) aren't there to replace your brain. They're there to give your brain a second pair of eyes that never gets tired, never gets overconfident, and never skips a line because it "probably looks fine."

Run the tools. Read the output. Fix what you can. Document what you acknowledge.

And before you ship anything real on mainnet, get a professional audit. I'm building toward that. This internal review is step one, not step last.

Try It Yourself

The full Merix Holdings codebase is open source:

GitHub: Ra9huvansh/merix-holdings

The security review, Slither report, and Aderyn report are all in the repository. Clone it, run the tools yourself, see if you find something I missed. That's the whole point of open source security.

# Clone and set up
git clone https://github.com/Ra9huvansh/merix-holdings
cd merix-holdings
forge install

# Run the test suite
forge test

# Run Slither
slither . --filter-paths "test|lib|script"

# Run Aderyn
aderyn --output aderyn-report.md .

If you find something, open an issue. Seriously.

Built with Foundry. Audited with Slither + Aderyn. Tested with 135 tests, 20 invariants, and a healthy dose of paranoia.

Raghuvansh Rastogi, Merix Holdings

How I Built a Capital Markets Trade Lifecycle System That Mirrors Real Banking Infrastructure

Raghuvansh — Tue, 31 Mar 2026 15:01:14 +0000

What happens between a trader clicking "Buy" and the asset actually changing hands? The answer is six microservices, four Kafka topics, a compliance rules engine, and two business days of settlement scheduling.

When most developers build a "finance project," they build a stock price tracker or a portfolio dashboard. Something that fetches data from an API and renders it on a chart.

That is not what happens inside a bank.

Inside a bank, a trade is not a number on a screen. It is a legally binding commitment that passes through compliance review, market execution, bilateral confirmation, T+2 settlement scheduling, and regulatory reporting, in that order, every single time, across systems built by different teams that talk to each other exclusively through message queues.

I wanted to build something that actually modeled this. Not a simplified version. The real pipeline, with real failure modes, real latency concerns, and real regulatory structure. The result is Valoris Systems, a distributed trade lifecycle simulator built with Java 21, Spring Boot 3, Apache Kafka, PostgreSQL, Redis, and React.

This post explains every architectural decision and why it mirrors what production trading systems actually do.

What a Trade Lifecycle Actually Is

Before writing a single line of code, I spent time understanding the business domain. This matters because the architecture follows the business, not the other way around.

When a trader at a bank or fund submits an order, it does not execute immediately. It passes through five mandatory stages:

1. Pre-Trade Compliance. Before anything happens, the system checks: Is this counterparty on the approved list? Does this trade exceed the trader's notional risk limit? Is this instrument in the allowed universe? All three must pass. One failure kills the trade before it reaches the market.

2. Execution. The trade hits the market. An execution price and timestamp get locked in. The venue is recorded (DFM, NASDAQ Dubai, DIFC dark pool in Valoris's case).

3. Confirmation. Both sides of the trade, buyer and seller, must independently confirm they agreed to the same price and quantity. Mismatches happen. In Valoris, 5% of confirmations introduce a random price mismatch of plus or minus 2%, which sits in a MISMATCHED state until resolved. This is realistic: in real markets, confirmation breaks happen and require manual intervention.

4. Settlement. The actual exchange of asset and cash. This does not happen immediately after execution. It happens T+2, meaning two business days later, skipping weekends. A scheduler runs every 60 seconds, checks which trades have reached their settlement date, updates net positions per counterparty/instrument pair, and marks them settled.

5. Regulatory Reporting. Every settled trade must be reported to the regulator (DFSA in Dubai, FCA in the UK, SEC in the US) within a defined window after execution. The report includes LEI identifiers, ISIN, notional value, execution price, venue, and counterparty details. In MiFID II terms this is called a transaction report. In Valoris, the reporting service generates a structured report in a format that mirrors real EMIR/MiFID II fields.

Each of these stages is a separate microservice in Valoris. They do not call each other over HTTP. They communicate exclusively through Apache Kafka event streams.

Why Event-Driven Over REST-to-REST

This is the most important architectural decision in the entire project and it needs a direct explanation.

The naive way to build this system is as a chain of REST calls:

FIX Gateway -> HTTP POST -> Compliance Service -> HTTP POST -> Execution Service -> ...

This works in development. It fails in production for several reasons.

Temporal coupling. If the execution service is down when compliance publishes a result, the trade is lost. With Kafka, compliance publishes to trades.validated, and the execution service consumes that topic whenever it is ready. The topic persists messages. Nothing gets lost.

Backpressure handling. In a real trading system, trade volume is not uniform. There are bursts at market open, major announcements, and high-volatility periods where thousands of trades hit the system simultaneously. Kafka acts as a buffer. Each downstream service processes at its own rate. The compliance service does not care whether execution is running fast or slow.

Audit trail by default. Every Kafka topic in Valoris is a permanent, ordered log of events. If you want to know exactly what happened to trade f47ac10b and when, you replay the events. This is not a nice-to-have in financial systems. It is a regulatory requirement.

Independent deployability. Each service can be updated, restarted, or scaled independently without any other service needing to know. The compliance service does not import any code from the execution service. They share nothing except the event schema.

The Kafka topics in Valoris map directly to the business stages:

Topic	What it means
`trades.incoming`	A trade has been submitted and needs compliance review
`trades.validated`	Compliance passed, route to execution
`trades.rejected`	Compliance failed, route to reporting for rejection record
`trades.executed`	Execution complete, needs counterparty confirmation
`trades.confirmed`	Both sides confirmed, ready for settlement scheduling
`trades.settled`	Settlement complete, generate regulatory report

Notice that trades.rejected goes directly to the reporting service. Rejected trades still need to be recorded. Regulators care about failed trades too.

The Compliance Service: Why Redis Matters Here

The compliance service is the most latency-sensitive component in the pipeline. Every trade must pass through it before execution. In real markets, pre-trade compliance checks need to complete in sub-millisecond time, not because the user is waiting (they are not, this is async), but because compliance rule evaluation is on the critical path for market access.

In Valoris, compliance rules are seeded into PostgreSQL on startup, then loaded into Redis at service initialization. The Redis cache holds:

The approved counterparty list (Redis Set under compliance:counterparty:approved)
Notional risk limits per trader (Redis strings under compliance:risk_limit:{submitterId})
The allowed instruments universe (Redis Set under compliance:instrument:allowed)

When a TradeIncomingEvent arrives on the Kafka consumer, the three compliance checks hit Redis exclusively. PostgreSQL never gets queried during the hot path. This matters because Redis operations complete in microseconds. A PostgreSQL query across a network involves disk I/O and connection overhead that you cannot afford to put on every single trade.

The three checks run in sequence with short-circuit logic:

public ComplianceCheckResponse check(TradeCheckRequest request) {
    log.info("Running compliance check for trade {}", request.getTradeId());
    LocalDateTime now = LocalDateTime.now();

    // Check 1: counterparty approval
    if (!rulesCacheService.isCounterpartyApproved(request.getCounterpartyId())) {
        return reject(request.getTradeId(), "COUNTERPARTY",
            "Counterparty " + request.getCounterpartyId() + " is not on the approved list", now);
    }

    // Check 2: notional risk limit
    Optional<BigDecimal> limit = rulesCacheService.getRiskLimit(request.getSubmittedBy());
    if (limit.isEmpty()) {
        return reject(request.getTradeId(), "RISK_LIMIT",
            "No risk limit configured for submitter " + request.getSubmittedBy(), now);
    }
    if (request.getNotionalValue().compareTo(limit.get()) > 0) {
        return reject(request.getTradeId(), "RISK_LIMIT",
            "Notional " + request.getNotionalValue() + " exceeds limit of " + limit.get() +
            " for submitter " + request.getSubmittedBy(), now);
    }

    // Check 3: instrument eligibility
    if (!rulesCacheService.isInstrumentAllowed(request.getInstrument())) {
        return reject(request.getTradeId(), "INSTRUMENT",
            "Instrument " + request.getInstrument() + " is not in the allowed instruments universe", now);
    }

    persistResult(request.getTradeId(), "VALIDATED", "PASS", null);
    log.info("Trade {} passed all compliance checks", request.getTradeId());
    return new ComplianceCheckResponse(request.getTradeId(), true, null, null, now);
}

First failure short-circuits. No point running instrument eligibility if the counterparty is already blocked.

The compliance service also exposes REST endpoints for rule management: adding/removing counterparties, updating notional limits, adding instruments. These write to PostgreSQL and update the relevant Redis keys. The dashboard's compliance panel calls these endpoints directly.

The Execution Service: Simulating Real Market Pricing

The execution service receives TradeValidatedEvent messages and is responsible for pricing the trade.

Valoris supports real ISINs with seeded base prices. For each instrument, the service applies a plus or minus 0.5% random spread to simulate market movement:

private static final Map<String, BigDecimal> BASE_PRICES = Map.of(
    "US0378331005", new BigDecimal("189.50"),  // Apple
    "US5949181045", new BigDecimal("415.20"),  // Microsoft
    "US02079K3059", new BigDecimal("175.80"),  // Alphabet
    "US4592001014", new BigDecimal("188.90"),  // IBM
    "US912828ZL9",  new BigDecimal("99.85"),   // US Treasury 2Y
    "US9128284Y00", new BigDecimal("98.60"),   // US Treasury 5Y
    "XS2314659447", new BigDecimal("100.25"),  // Emirates NBD bond
    "AEA007601011", new BigDecimal("8.42"),    // Emaar Properties (AED)
    "AEA000301011", new BigDecimal("14.76")    // First Abu Dhabi Bank (AED)
);

public BigDecimal getPrice(String isin) {
    BigDecimal base = BASE_PRICES.getOrDefault(isin, new BigDecimal("100.00"));
    double spreadFactor = 1.0 + (ThreadLocalRandom.current().nextDouble() - 0.5) * 0.01;
    return base.multiply(BigDecimal.valueOf(spreadFactor))
        .setScale(6, RoundingMode.HALF_UP);
}

The execution service assigns a venue to each trade drawn from a realistic set for Gulf markets: DIFC-DARK-POOL, DFM (Dubai Financial Market), and NASDAQ-DUBAI. The venue field is mandatory in MiFID II transaction reports, so this domain detail matters.

The resulting TradeExecutedEvent includes executionPrice, executionTimestamp, and venue. These three fields are immutable from this point forward. Downstream services reference them but cannot modify them. This is the principle of event immutability: past events are facts, not suggestions.

The Confirmation Service: Modeling the Failure Path

Most toy projects ignore failure modes. The confirmation service exists specifically to model one.

In real markets, bilateral confirmation is a process where both sides of a trade independently report what they believe they agreed to. Mismatches happen when one side reports a slightly different price than the other due to rounding, latency, or fat-finger errors.Valoris simulates the counterparty-side confirmation response with a
probabilistic mismatch.

In Valoris, the confirmation service applies a 5% random mismatch rate on the execution price, introducing a plus or minus 2% variance:

private static final double MISMATCH_PROBABILITY = 0.05;
private static final double MISMATCH_DEVIATION = 0.02;

public TradeConfirmedEvent confirm(TradeExecutedEvent event) {
    boolean isMismatch = ThreadLocalRandom.current().nextDouble() < MISMATCH_PROBABILITY;

    BigDecimal confirmedPrice;
    String status;
    String mismatchReason;

    if (isMismatch) {
        double deviation = 1.0 + (ThreadLocalRandom.current().nextBoolean() ? 1 : -1) * MISMATCH_DEVIATION;
        confirmedPrice = event.getExecutionPrice()
                .multiply(BigDecimal.valueOf(deviation))
                .setScale(6, RoundingMode.HALF_UP);
        status = "MISMATCHED";
        mismatchReason = String.format(
            "Counterparty confirmed price %s differs from execution price %s",
            confirmedPrice, event.getExecutionPrice()
        );
    } else {
        confirmedPrice = event.getExecutionPrice();
        status = "CONFIRMED";
        mismatchReason = null;
    }
    // ... persist and publish
}

A mismatched trade enters MISMATCHED status and is exposed via a REST endpoint:

GET :8084/api/confirmations/mismatched

The dashboard displays these trades with a warning state. A trader or operations staff can view the mismatch detail and resolve it manually. Only confirmed trades (status CONFIRMED) advance to settlement. Mismatched trades do not.

This failure path handling is what separates an engineering project from a demo. Real systems break in predictable ways. The architecture must handle it.

The Settlement Service: T+2 and Position Netting

Settlement is where the asset and cash actually change hands. T+2 means two business days after execution, not two calendar days. Weekends are skipped.

The settlement service implements this with a Spring @Scheduled task that runs every 60 seconds:

@Scheduled(fixedDelay = 60000)
@Transactional
public void settleMaturedTrades() {
    LocalDate today = LocalDate.now();
    List<Settlement> due = settlementRepository
        .findBySettlementStatusAndSettlementDateLessThanEqual("PENDING", today);

    if (due.isEmpty()) return;

    log.info("Settlement scheduler: {} trade(s) due for settlement on or before {}", due.size(), today);

    for (Settlement s : due) {
        s.setSettlementStatus("SETTLED");
        settlementRepository.save(s);

        producer.publish(new TradeSettledEvent(
            s.getTradeId(), s.getInstrument(), s.getSide(),
            s.getQuantity(), s.getCounterpartyId(), s.getCurrency(),
            s.getNotionalValue(), s.getSubmittedBy(),
            s.getExecutionPrice(), s.getExecutionVenue(),
            s.getSettlementDate(), "SETTLED", LocalDateTime.now()
        ));

        log.info("Trade {} settled on {}", s.getTradeId(), today);
    }
}

Position queries are exposed via REST:

GET :8085/api/positions/{counterpartyId}

This endpoint returns the current net position across all instruments for a given counterparty, matching the data structure a real prime broker would show a fund client.

The Reporting Service: Mirroring Regulatory Requirements

The reporting service is the final stage of the pipeline. It consumes both trades.settled and trades.rejected, since both settled and rejected trades require records in real regulatory frameworks.

The TradeReport model mirrors the fields required by EMIR and MiFID II Transaction Reporting. Here is what GET /api/reports/{tradeId} returns for a settled trade:

{
  "tradeId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "instrument": "US0378331005",
  "side": "BUY",
  "quantity": 500,
  "counterpartyId": "CP-001",
  "currency": "USD",
  "notionalValue": 94875.00,
  "submittedBy": "trader.dubai",
  "executionPrice": 189.750000,
  "executionVenue": "NASDAQ-DUBAI",
  "settlementDate": "2026-04-02",
  "settlementStatus": "SETTLED",
  "settledAt": "2026-04-02T00:01:03.112Z",
  "reportGeneratedAt": "2026-04-02T00:01:03.215Z"
}

The LEI (Legal Entity Identifier) is the ISO standard identifier for firms participating in financial markets. Every regulated entity has one. Valoris's data model is structured to accommodate this field in a production extension without structural changes.

The reporting service also powers analytics. Endpoints expose volume aggregated by instrument, by counterparty, and by venue. The dashboard's analytics section visualizes these using Recharts: bar charts for volume by ISIN, pie charts for distribution by counterparty, area charts for settlement activity over time.

Database Isolation: One Schema Per Service

Each service owns its own PostgreSQL database. The compliance service has no access to the execution service's database. The settlement service has no access to the confirmation service's database. This is strict.

This is not just a microservices best practice. It is a business requirement in regulated financial infrastructure. When a regulator audits the compliance team's systems, they should be auditing only the compliance service's database. Cross-service database joins are a regulatory and operational risk.

In practice this means:

No foreign keys across service boundaries
No shared ORM models
No cross-database queries in the application layer
Event schemas (the Kafka event DTOs) are the only shared contract

If the execution service needs compliance data, it gets it from the TradeValidatedEvent payload that was published when compliance passed. It does not query the compliance database.

The React Dashboard: Live Pipeline Visibility

The dashboard is built with React 18 and Vite, served in production by nginx. It has three sections.

Trade Pipeline View. A live table of all trades with columns for TradeID, Instrument, Side, Notional, Current Stage, and Status. Color coding: green for progressing trades, red for rejected or failed, yellow for pending states like MISMATCHED or PENDING_SETTLEMENT. The table auto-refreshes by polling the FIX gateway's trade list endpoint.

Trade Detail View. Click any trade to open a side panel showing the full event timeline from submission through reporting. Each stage shows its timestamp and the full JSON payload, expandable inline. This is how an operations team would investigate a problem trade in a real system.

Analytics. Recharts visualizations driven by the reporting service's analytics endpoints. Volume by instrument, volume by counterparty, settlement summary.

Running the Entire System

The entire stack (PostgreSQL, Redis, Zookeeper, Kafka, six Spring Boot services, and the React frontend) starts with one command:

docker compose up --build

All 11 containers start in the correct order with health checks. The dashboard is available at http://localhost:5173. Submit a trade via the dashboard or directly:

curl -X POST http://localhost:8081/api/trades \
  -H "Content-Type: application/json" \
  -d '{
    "instrument": "US0378331005",
    "side": "BUY",
    "quantity": 500,
    "counterpartyId": "CP-001",
    "currency": "USD",
    "notionalValue": 94750.00,
    "submittedBy": "trader.dubai"
  }'

Watch it progress through the pipeline in real time on the dashboard.

What This System Demonstrates

The firms that care most about this kind of project (ION Group, Murex, Finastra, Broadridge, FIS, and the in-house technology teams at major banks) are all hiring engineers who understand the business domain, not just the technology.

Anyone can build REST microservices. Not many graduate-level developers can explain why T+2 settlement exists (it is a historical artifact from paper certificate delivery that modern systems are slowly moving to T+1), what an LEI is and why it is mandatory in regulatory reports, why compliance rules need to live in Redis rather than being fetched from PostgreSQL on every check, or what happens operationally when a bilateral confirmation mismatch occurs.

Valoris is not a demo. It is a working model of infrastructure that processes trillions of dollars of trades every day across global financial markets.

The code is at github.com/Ra9huvansh/Valoris-Systems.

Raghuvansh is a pre-final year Computer Science student at JIIT Noida targeting capital markets infrastructure and blockchain engineering roles in Dubai, Hong Kong, and Shanghai.