Day 1 was the problem. $2 billion stolen. The bridge honeypot. The architecture that makes theft inevitable.

Day 2 was the idea. Remote account ownership. Distributed key generation. The threshold that replaces the vault. The cryptographic foundation that removes the target from existence.

Today is the proof.

Not descriptions. Not diagrams. The actual system. Every component. Every step. Running on real testnets with real transactions that anyone can verify.

This is what CHAKRA looks like when it works ( actually I build alot of it ) will be learnt understood in upcoming days with how I tackled the errors scary parts etc etc ..

CHAKRA is not one thing. It is four components working together. Each one has a specific job. Each one is necessary. Together they produce something that has not existed before in the Solana ecosystem.

Let me introduce each one before showing you how they connect.

The CHAKRA Controller. An Anchor program deployed on Solana. This is the brain. It accepts cross-chain intents from any Solana program. It locks funds in atomic escrow. It fires events to the network. It verifies proof when execution is complete. It enforces rollback when execution fails. Everything starts and ends here.

The Sentinel Node Network. Three independent processes each running a Rust application. Each one holds one shard of the distributed key. Each one listens to Solana via WebSocket. When they hear a ControlIntent event they begin the signing ceremony. They communicate with each other over HTTP. They produce a valid threshold signature without any single one of them ever holding the complete key.

The ChakraReceiver. A Solidity contract deployed on Base Sepolia. It waits. When the Sentinel Nodes call it with a valid TSS signature it verifies the signature against the registered TSS public key. It marks the intent as executed to prevent replay attacks. It releases the funds or executes the action on the Base side. It confirms.

The Atomic Escrow. This is not a separate component exactly. It is baked into the CHAKRA Controller. But it deserves its own introduction because it is the safety guarantee that makes the whole system trustworthy. When you initiate an intent your funds lock in a Program Derived Address. They cannot move until one of two things happens. Either valid proof of execution arrives from the Sentinel Nodes within the timeout window and the escrow releases. Or the timeout expires and you call cancel_intent and everything returns to you automatically. There is no third outcome. There is no stuck state. There is no lost funds scenario. The Solana program enforces this with the same finality that Solana enforces everything.
( I know it might sound so different as of now but its really worth the time )

Let me walk you through the complete flow from start to finish. Every single step. Nothing skipped.

You call the CHAKRA Controller on Solana.

You call initialize_intent on the Anchor program. You pass it everything it needs. The target chain ID. The amount. The destination address on the target chain. The timeout in slots. This is your instruction to the system. This is where everything begins.

Your funds lock in the escrow.

The moment your instruction lands the CHAKRA Controller creates an EscrowState account. A Program Derived Address seeded with your wallet address, the target chain ID, and a nonce. Your funds transfer into this PDA via a system program CPI. They are now held by the program. Only the program. The program will not release them until proof of execution arrives or the timeout expires. This is enforced by Solana's consensus. Not by trust. By math.

The Controller fires the ControlIntent event.

The program emits an event to the blockchain. This event contains everything the Sentinel Nodes need. The owner's public key. The target chain ID. The nonce. The amount. The source chain identifier. The target chain identifier. The destination address. The escrow PDA address. The timeout slot. This event is visible to anyone listening to the Solana program's logs via WebSocket subscription.

The Sentinel Nodes hear it.

Three Sentinel Node processes are running. Each one has an open WebSocket subscription to the Solana Devnet watching for logs from the CHAKRA program ID. The moment the ControlIntent event fires all three nodes detect it. Each one parses the event data. Each one verifies it is properly formatted and legitimate. And then the signing ceremony begins.

The signing ceremony.

Each Sentinel Node takes the intent payload and constructs the same message. Target chain ID in big-endian bytes. Nonce in big-endian bytes. Amount in big-endian bytes. Destination address padded to 64 bytes. All concatenated together in the same order on every node. Then each node runs Keccak256 over this payload to produce the message hash. The same hash on every node because they all received the same intent data.

Now the threshold signing begins. Each node signs the message hash using its own key shard as if it were a complete secp256k1 private key. This produces a partial signature. Each partial signature has an r value, an s value, and a recovery ID. The coordinator node collects partial signatures from two of the three nodes. Then it runs Lagrange interpolation over the two s values using the node indices as the x coordinates. The interpolation reconstructs the combined s value that corresponds to the master key evaluated at x equals zero. The r value comes from one of the partial signatures. The result is one valid complete secp256k1 signature. The same signature that would have been produced if the complete master key had signed the message directly.

The complete master key was never reconstructed anywhere. The shards never combined. Only the signatures combined. This is the cryptographic core of the entire system.

The Base Sepolia call.

The coordinator node takes the combined signature and constructs an Ethereum transaction calling execute_intent on the ChakraReceiver contract on Base Sepolia. The call includes the target chain ID, the amount, the destination address, the nonce, and the r, s, v values of the TSS signature. The ChakraReceiver verifies the signature using ECDSA recovery. It checks the recovered address against the registered TSS public key. If they match the intent is valid. The contract marks it as executed. The funds move. The action happens.

Proof back to Solana.

After Base Sepolia confirms the transaction the coordinator node submits a proof transaction back to the CHAKRA Controller on Solana. It calls submit_proof passing the Base Sepolia transaction hash and the TSS signature components. The CHAKRA Controller verifies the signature on-chain using Solana's native secp256k1_recover syscall. It checks the recovered public key against the registered TSS public key in the TssConfig account. If they match the proof is valid. The escrow closes. The EscrowState account is closed and the lamports go to the treasury. The intent is finalized.

If something goes wrong.

The timeout slot arrives and no valid proof has been submitted. Anyone can now call cancel_intent. The CHAKRA Controller checks that the timeout has passed and the escrow is not already finalized or cancelled. It closes the EscrowState account and returns all funds directly to the original owner. Automatically. Completely. No questions asked. No human intervention. The program enforces it..

CHAKRA on Day 3 of building in public is a working proof of concept. Let me be precise about what that means.

It proves the architecture is sound. A Solana program can initiate a cross-chain action, lock funds atomically, coordinate a distributed signing ceremony across multiple nodes, produce a valid native signature for a foreign chain, execute on that chain, receive proof, and release the escrow. This full loop works. It has been demonstrated on real testnets.

It proves the security model is viable. The distributed key architecture means no single component holds anything that can be stolen to compromise the system. The atomic escrow means users are protected even if the Sentinel Network fails entirely.

It proves the foundation that everything else gets built on top of. The SDK that lets any Solana developer add cross-chain capability to their Anchor program in under 100 lines of code. The documentation. The integrations. The decentralized Sentinel Network. None of that exists yet. All of that gets built on this foundation.

The foundation is real. The architecture is proven. The next phase of building starts now.
You might not understand many things and that's okay..

I know the code, where is the code will be explaining each part of every thing I built so far without any breaks lets be patient because its a big project and most importantly its Rust so gotta be careful with what I show what I explain thankyou for reading

Here are some resources
https://www.anchor-lang.com/docs/references/account-types
https://toc.cryptobook.us/ ( a complicated read for the math nerds wondering how independent shards combine into a single valid signature without ever revealing the master key, this is the academic foundation. It covers the exact Lagrange interpolation primitives we use off-chain at $x = 0$.)
https://github.com/paulmillr/noble-secp256k1 ( a complicated read if u want to see how production-grade nodes handle low-level cryptographic operations like Keccak256 hashing and signature recovery points off-chain, dive into this repository. This is the global open-source standard for secp256k1 implementation )
https://docs.rs/solana-program/latest/solana_program/ ( to those who want to dig directly into the bare metal, this is the foundational core library for all on-chain Solana development. It contains the standard entry points, system interfaces, and optimized runtime memory utilities .. am still learning alot from this )

Written by Maha.. See y'all tomorrow.