Welcome to Day 11.

Day 10 closed out the entire on chain side of CHAKRA. Everything from the 64 byte tss_pubkey in state.rs to the admin keypair I was honest about on Day 10, all of it done.

Today we cross over. We are no longer inside the Solana program. We are inside chakra-sentinel, the separate Rust application running on actual servers, the thing that listens, signs, and executes. And the first question to answer is the most basic one.

How does the Sentinel Network even know something happened on Solana.

Part 1: The Problem With Polling

The naive approach would be polling. Every few seconds, ask Solana, did anything happen. Did our program emit any events. Fetch the latest transactions. Parse them. Look for something we care about.

This works but it is ugly. You miss events if your poll happens between two transactions. You add unnecessary load to the RPC. You introduce latency that grows with your poll interval. And you are paying for compute and bandwidth on every single poll even when absolutely nothing happened.

CHAKRA does not poll. It subscribes.

Part 2: WebSocket Subscription, The Whole Idea

rust

let (_subscription, receiver) = PubsubClient::logs_subscribe(
    DEVNET_WSS,
    RpcTransactionLogsFilter::Mentions(vec![PROGRAM_ID.to_string()]),
    RpcTransactionLogsConfig {
        commitment: Some(CommitmentConfig::confirmed()),
    },
)?;

One function call. That is the whole setup. PubsubClient opens a persistent WebSocket connection to Solana's pubsub endpoint. The filter says only send me logs from transactions that mention this specific program ID. CommitmentConfig::confirmed means we only hear about transactions that have been confirmed by the cluster, not just seen by one node.

From this moment on, Solana pushes events to us. We do not ask. We just listen. The moment any transaction involving the CHAKRA program ID gets confirmed anywhere on devnet, our Sentinel process receives it over this open connection in real time.

No polling. No missed events. No unnecessary load. Just a permanent open ear.

Part 3: The Loop That Runs Forever

rust

while let Ok(response) = receiver.recv() {
    let signature = response.value.signature.clone();
    
    for log in response.value.logs {
        if log.contains("Program data:") || log.contains("Instruction:") {
            if let Err(e) = crate::processor::IntentProcessor::handle_log(
                &log, &signature, &shard_path, &wallet_path
            ) {
                eprintln!("Error processing intent: {:?}", e);
            }
        }
    }
}

receiver.recv() blocks until a message arrives. When it does we get back a response containing the transaction signature and an array of log lines that transaction produced.

We loop through every log line looking for two things. Program data: is how Anchor encodes emitted events into the transaction logs, it is the prefix for any event struct we saw back in Day 6. Instruction: marks the actual instruction being called.

If we find either of those we hand the log line and the transaction signature to IntentProcessor::handle_log which lives in processor.rs. If something goes wrong parsing or handling it we print the error and keep going. The while loop does not break on a single bad log. The sentinel keeps listening no matter what.

Part 4: What CommitmentConfig::confirmed Actually Means And Why It Matters

Solana has three commitment levels. processed means the transaction was seen by at least one node but might not survive. confirmed means it got voted on by a supermajority of validators, 66% of stake weight. finalized means it is permanently locked in and cannot be rolled back under any circumstances.

We use confirmed not finalized for a specific reason. If we waited for finalized on every ControlIntent event we would add extra latency to every single cross chain execution. confirmed is safe enough for our purposes because by the time our Sentinel processes the event, constructs the signature, sends it to Base Sepolia, waits for Base confirmation, and submits the proof back to Solana, the original transaction is going to be finalized anyway. We get the speed of confirmed with the effective safety of finalized just from the natural time the rest of the process takes.

Part 5: The Discriminator Check Coming Next

There is one more thing worth mentioning even though it technically lives in processor.rs, because it is directly triggered by what listener.rs sends over.

When Anchor emits an event it encodes it as base64 data in the transaction logs with a specific 8 byte prefix called a discriminator. The discriminator for ControlIntent is the first 8 bytes of SHA256 of the string event:ControlIntent. When handle_log receives a Program data: line it decodes the base64, checks those first 8 bytes, and only proceeds if they match ControlIntent specifically.

This means even if someone tried to send fake logs mentioning the CHAKRA program ID, the discriminator check catches it before anything happens. The Sentinel does not just react to any log that mentions CHAKRA. It reacts specifically to logs that contain a properly encoded ControlIntent event which can only come from the actual CHAKRA program running the actual initialize_intent instruction.

Part 6: Why This Design Specifically

The public wire design here, Solana transaction logs as the communication channel between the on chain program and the off chain Sentinel Network, has a property that is easy to miss until you think about it carefully.

The Sentinel Nodes do not need to trust me. They do not need a private API endpoint I control. They do not need a message queue I could tamper with. They read directly from Solana's public logs which are produced by the validators, not by me. If I disappeared tomorrow the Sentinel Nodes would still hear every ControlIntent that gets emitted because Solana keeps producing logs whether I am involved or not.

This is what pure event sourcing actually means in practice. The Sentinel Network's source of truth is the blockchain itself, not anything I control above it.

Soon we go into signer.rs which is where things get genuinely exciting. The Lagrange interpolation from Day 2 finally becomes actual running Rust code. The partial signatures being collected from multiple nodes over HTTP. The threshold math producing one valid Ethereum signature without any single node ever knowing the complete key.

See y'all tomorrow for Day 12 soon

Here are some resources

logsSubscribe WebSocket
The Solana PubSub API for subscribing to transaction logs in real time.
https://solana.com/docs/rpc/websocket/logssubscribe

Commitment Levels on Solana
What processed, confirmed, and finalized actually mean and when to use each.
https://docs.solanalabs.com/consensus/commitments

Written by Maha.. thankyou for reading

@solana @web3 @rust @anchor

Who Holds The Keys Inside admin.rs: The Control Panel Behind CHAKRA, And The Centralization I Am Not Hiding

Welcome to Day 10. Again continuing the docs

Day 7, 8 and 9 covered the three instructions a normal user or a Sentinel Node would ever call. initialize_intent starts an intent. cancel_intent rescues it if nothing happens. submit_proof finishes it if everything happened correctly.

There is one file left in the instructions folder. admin.rs. And I saved it for last on purpose, because while it is the file regular users will basically never touch, it is also if I am being completely honest the most powerful file in the entire program.

Part 1: Why This File Is Different

Every file we have looked at so far does something because a user did something. Locked funds because a user called initialize_intent. Refunded because a user called cancel_intent.

admin.rs is the opposite. It is the protocol talking to itself. It is how the three config accounts from Day 4, TssConfig, GlobalConfig, and SentinelAccount, actually get created and updated in the first place. Without this file running first, none of the other instructions can even start. The escrow has no treasury address. submit_proof has no tss_pubkey to check against. The sentinel registry is empty so every proof gets rejected before the body even runs.

Four instructions live here. initialize_tss_config, update_tss_config, initialize_config, and the pair add_sentinel and remove_sentinel through a shared ManageSentinel struct. Let me go through each one.

Part 2: initialize_tss_config, The Most Important One Time Call In The Program

rust

pub fn handle_initialize_tss_config(
    ctx: Context<InitializeTssConfig>,
    tss_pubkey: [u8; 64],
    threshold: u8,
    total_nodes: u8,
) -> Result<()> {
    let tss_config = &mut ctx.accounts.tss_config;
    tss_config.tss_pubkey = tss_pubkey;
    tss_config.threshold = threshold;
    tss_config.total_nodes = total_nodes;
    tss_config.admin = ctx.accounts.admin.key();
    tss_config.bump = ctx.bumps.tss_config;
    Ok(())
}

Remember Day 4 where I said the 64 byte tss_pubkey field is the single most important field in the entire protocol, the thing every submit_proof call gets checked against on Day 9. This is the function that writes it for the very first time.

Whoever calls this becomes tss_config.admin permanently for that account. And this tss_pubkey has to exactly match the public key whose shards are sitting across the three Sentinel Nodes from Day 2. If this value is wrong by even one byte at this moment, every single submit_proof from then on fails with InvalidProof forever, until someone with admin access fixes it with the next function.

Part 3: update_tss_config, The Key Rotation Door

rust

#[account(
    mut,
    seeds = [b"tss_config"],
    bump = tss_config.bump,
    constraint = tss_config.admin == admin.key()
)]
pub tss_config: Account<'info, TssConfig>,

One constraint. tss_config.admin == admin.key(). That is the entire gate. If you are the admin pubkey stored back when initialize_tss_config ran, you can call this and overwrite tss_pubkey, threshold, and total_nodes with new values.

Why does this exist. Now chakra uses Shamir Secret Sharing with the coordinator briefly reconstructing the key in memory. Soon upgrades to true FROST where the key never gets reconstructed anywhere ever. When that upgrade happens the way the master public key is derived changes completely. This function is the door that lets CHAKRA walk through that upgrade without redeploying the entire Anchor program. Same program, same escrow logic, same error codes, just a new tss_pubkey registered through this one call.

Part 4: initialize_config, And The is_initialized Guard

rust

pub fn handle_initialize_config(
    ctx: Context<InitializeConfig>,
    treasury: Pubkey,
) -> Result<()> {
    let config = &mut ctx.accounts.config;
    config.admin = ctx.accounts.admin.key();
    config.treasury = treasury;
    config.is_initialized = true;
    config.bump = ctx.bumps.config;
    Ok(())
}

This sets config.treasury, which is exactly where the escrowed lamports go on a successful submit_proof, the thing I was honest about on Day 9 being still a work in progress.

is_initialized = true here is small but it matters. Because config lives at a fixed PDA seeded only by b"config", there is exactly one GlobalConfig account that can ever exist. The init constraint already stops a second initialize_config call from succeeding on the same address, but is_initialized as an explicit flag gives any future instruction an easy cheap way to check whether setup actually happened without relying purely on account existence. Belt and suspenders, same philosophy as the booleans in EscrowState from Day 4.

Part 5: ManageSentinel, Growing The Network One Node At A Time

rust

pub fn handle_add_sentinel(
    ctx: Context<ManageSentinel>,
    sentinel_pubkey: Pubkey,
) -> Result<()> {
    let sentinel = &mut ctx.accounts.sentinel_account;
    sentinel.sentinel_pubkey = sentinel_pubkey;
    sentinel.is_active = true;
    sentinel.bump = ctx.bumps.sentinel_account;
    Ok(())
}

pub fn handle_remove_sentinel(
    ctx: Context<ManageSentinel>,
    _sentinel_pubkey: Pubkey,
) -> Result<()> {
    let sentinel = &mut ctx.accounts.sentinel_account;
    sentinel.is_active = false;
    Ok(())
}

init_if_needed in the accounts struct is doing something specific here. Normally init means create this account and it fails if the account already exists. But CHAKRA does not know in advance how many sentinel nodes will ever exist across its lifetime. init_if_needed says create this PDA if this is the first time we are seeing this sentinel_pubkey, otherwise just use the existing one. That is how add_sentinel works identically for the very first node and the fiftieth node.

And notice remove_sentinel does not delete anything. It just sets is_active = false. The account stays on chain forever. This is the soft delete pattern, same is_active check from submit_proof on Day 9. If a node ever gets compromised, flipping this one boolean instantly and permanently locks that node out of every future submit_proof, while still leaving a permanent public record that it happened.

Part 6: The Part I Actually Want To Talk About

Here is the honest thing about every constraint in this entire file. config.admin == admin.key(). tss_config.admin == admin.key(). Right now on devnet all of those admin keys are the same keypair. My keypair. Sitting in one file on my laptop.

That means right now one private key has the power to register a completely different tss_pubkey through update_tss_config, add or deactivate any sentinel through ManageSentinel, and effectively rewrite the entire trust model from Day 9 from the outside.

I want to say this loudly instead of quietly because I think it is more important than almost anything else in this series. If this exact setup were ever deployed to mainnet as is and that one keypair got compromised, an attacker would not need to break secp256k1 or compromise two Sentinel Nodes at all. They could just call update_tss_config with their own key, then submit fake proofs that pass against their own key, and drain every escrow. Without touching any cryptography at all.

For protocol on devnet run by one person this is normal and honestly the only way I could move this fast alone. But it cannot be the end state. Before any real funds are involved this admin authority has to move off a single keypair. Things I am actively thinking about, a multisig so updates need multiple signers, or a time lock so any update_tss_config call has a mandatory delay before it takes effect giving everyone time to notice if something looks wrong.

That is admin.rs. That is the complete on chain side of CHAKRA.

Tomorrow we cross over to the other side entirely. The Sentinel Network. The actual Rust processes that heard the ControlIntent event from Day 6 and now have to do something about it.

See y'all tomorrow for Day 11.

Here are some resources

init_if_needed in Anchor How conditional account initialization works and when it is safe to use.
https://www.anchor-lang.com/docs/references/account-constraints#init_if_needed

Multisig on Solana How multisig programs work, relevant to the centralization point above.
https://docs.squads.so

Written by Maha.. thankyou for reading

@solana @web3 @anchor @rust

Where Math Meets Money
Inside submit_proof.rs: The On Chain Moment secp256k1_recover Decides Everything

Welcome to Day 9.

Day 7 was the start. initialize_intent.rs locks the funds and fires the signal. Day 8 was the escape hatch. cancel_intent.rs is what happens if nothing comes back in time.

Today is the third path. The happy path. The Sentinel Network heard the signal from Day 7, ran the 2 of 3 threshold signing ceremony I described back on Day 2, executed on Base Sepolia, and now comes back to Solana with proof that it actually happened.

This file is submit_proof.rs, and on Day 5 when I introduced InvalidProof I said this is the moment where math meets money. Today you get to see that moment in actual code.

Part 1: The Accounts Struct, Five New Faces

rust

#[derive(Accounts)]
pub struct SubmitProof<'info> {
#[account(mut)]
pub sentinel: Signer<'info>,
#[account(
    seeds = [b"sentinel", sentinel.key().as_ref()],
    bump = sentinel_auth.bump,
    constraint = sentinel_auth.is_active @ ChakraError::UnauthorizedSentinel
)]
pub sentinel_auth: Account<'info, SentinelAccount>,

#[account(
    seeds = [b"config"],
    bump = config.bump,
)]
pub config: Account<'info, GlobalConfig>,

#[account(
    mut,
    seeds = [
        b"escrow",
        escrow_account.owner.as_ref(),
        &escrow_account.target_chain_id.to_le_bytes(),
        &escrow_account.nonce.to_le_bytes()
    ],
    bump = escrow_account.bump,
    close = treasury
)]
pub escrow_account: Box<Account<'info, EscrowState>>,

#[account(
    seeds = [b"tss_config"],
    bump = tss_config.bump,
)]
pub tss_config: Account<'info, TssConfig>,

/// CHECK: Treasury wallet from config
#[account(mut, address = config.treasury)]
pub treasury: AccountInfo<'info>,

pub system_program: Program<'info, System>,
}

sentinel is the Signer here, not the user. This whole instruction is called by a Sentinel Node, not by the person who started the intent.

sentinel_auth checks constraint = sentinel_auth.is_active. This is the SentinelAccount registry from Day 4 and the UnauthorizedSentinel error from Day 5, finally being used. Even if someone has somehow produced a perfect TSS signature, if they are not a registered active sentinel, this constraint stops them right here, before the function body even runs.

escrow_account is wrapped in Box<>. Quick note on that, Box just moves the account data onto the heap instead of the stack. Anchor instructions have a limited stack size, and EscrowState at 211 bytes plus all the other accounts in this struct can get close to that limit. Boxing it is a common pattern to stay safely under the limit.

And look at close = treasury this time, not close = owner like yesterday. I will come back to this in Part 5.

Part 2: The Familiar Gatekeepers

rust

require!(!escrow.is_finalized, ChakraError::AlreadyFinalized);
require!(!escrow.is_cancelled, ChakraError::AlreadyCancelled);
require!(clock.slot <= escrow.timeout_slot, ChakraError::TimeoutReached);

Same family of checks as cancel_intent, but flipped. Cancel needed the timeout to have passed. Submit proof needs the timeout to NOT have passed yet. TimeoutReached is the mirror image of TimeoutNotReached from yesterday. Together, these two checks across two files are what guarantee an intent can only ever land in exactly one final state.

Part 3: Rebuilding The Message, And Why Big Endian

Now here is the part I told you to remember from Day 7.

rust

let mut msg_data = Vec::with_capacity(8 + 8 + 8 + 64);
msg_data.extend_from_slice(&escrow.target_chain_id.to_be_bytes());
msg_data.extend_from_slice(&escrow.nonce.to_be_bytes());
msg_data.extend_from_slice(&escrow.amount.to_be_bytes());
msg_data.extend_from_slice(&escrow.target_address);

let msg_hash = keccak256(&msg_data).to_bytes();

to_be_bytes(). Big endian. Back in initialize_intent.rs, the PDA seeds used to_le_bytes(), little endian, because that is just the normal Rust and Solana convention for deriving addresses, nobody outside Solana ever needs to recompute those seeds.

But this msg_data right here is different. This exact byte sequence, in this exact order, with this exact endianness, has to be reproduced perfectly by ChakraReceiver.sol on Base Sepolia, because the Sentinel Network signed a hash of this same data, and the contract on the other side needs to recompute the identical hash to verify that signature.

Ethereum and EVM chains use big endian as their convention. So this is CHAKRA speaking Ethereum's language on purpose, right here, in the middle of a Solana program. Get this wrong by even the endianness of one field, and the hash on Solana will never match the hash on Base, and every single proof will fail forever.

And keccak256, not sha256. Why. Because Ethereum's ECDSA signatures are produced over keccak256 hashes. If the Sentinel Nodes signed a keccak256 hash back during the signing ceremony from Day 2, then Solana has to also hash with keccak256 here, or the recovered key will be garbage.

Part 4: secp256k1_recover, The Syscall That Makes This Whole Project Possible

rust

let mut sig_bytes = [0u8; 64];
sig_bytes[0..32].copy_from_slice(&signature_r);
sig_bytes[32..64].copy_from_slice(&signature_s);

let recovery_id = signature_v
.checked_sub(27)
.ok_or(ChakraError::InvalidProof)?;

let recovered_pubkey = secp256k1_recover(&msg_hash, recovery_id, &sig_bytes)
.map_err(|_| ChakraError::InvalidProof)?;

require!(
recovered_pubkey.to_bytes() == tss_config.tss_pubkey,
ChakraError::InvalidProof
);

escrow.is_finalized = true;

A quick note on signature_v.checked_sub(27) first. In Ethereum, the recovery id v is encoded as either 27 or 28, an old historical convention. ECDSA recovery actually only needs a recovery id of 0 or 1. So we subtract 27 to convert back. And notice it is checked_sub, not a plain subtraction. If somehow signature_v came in less than 27, a plain subtraction would underflow a u8 and wrap around to some huge number. checked_sub catches that and returns InvalidProof instead. One more quiet little safety check, same family as the ones from Day 5.

Now, secp256k1_recover. This is the single most important function call in the entire program. Given a message hash, a recovery id, and a signature, it mathematically recovers the public key that must have produced that signature. Not "checks against" a public key. Recovers one, from nothing but the hash and the signature.

This is a native syscall on Solana, meaning it runs as actual compiled machine instructions inside the validator, not as some slow library running inside the program's own bytecode. That is a big deal. This is part of why CHAKRA can exist on Solana specifically. Verifying an Ethereum style ECDSA signature, cheaply, on chain, in a single instruction, is something most chains simply cannot do natively.

And then the line that everything in this entire series has been building toward.

recovered_pubkey.to_bytes() == tss_config.tss_pubkey

That's it. That is the whole trust model of CHAKRA, on one line. Remember the 64 byte tss_pubkey from Day 4, the field I said everything depends on being correct. This is the line it was waiting for. If the recovered key matches, the proof is real, is_finalized flips to true, and emit!(IntentFinalized { escrow_pda, tx_hash }) fires, the same IntentFinalized event from Day 6.

If it does not match, even by one byte, InvalidProof fires, the transaction reverts, is_finalized stays false, and the escrow stays exactly where it was, still cancellable later if needed. Nothing in between. No partial trust.

Part 5: Where The Money Actually Goes

Let's look at one final design detail honestly.

When this instruction succeeds, close = treasury routes the escrowed lamports straight to config.treasury instead of returning them to the user. This is the exact opposite of cancel_intent.rs, where funds go back to the original owner.

For our Milestone 1 release, these locked tokens act as the fee that compensates the Sentinel Network for doing the actual cross-chain heavy lifting on the other side. Right now, treasury is a placeholder destination while I map out the long-term mechanics. Once the network expands past me running all three nodes, this pool will dynamically distribute payouts to decentralized node operators based on performance. It’s a Milestone 1 framework, not the final mainnet economic model—but keeping it completely transparent here is better than pretending it's fully set in stone

Part 6: The Whole Series, In One Line

If you asked me to reduce CHAKRA’s entire security apparatus to a single sentence, it would be this: Every moving part before this moment—the Distributed Key Generation, the Shamir Secret Sharing, and the Lagrange interpolation—exists solely to reconstruct a 64-byte public key on this exact line of code that matches tss_config.tss_pubkey.

An attacker who hasn't compromised a 2-of-3 quorum cannot make those bytes match. Not because a rule tells them no, but because the mathematics won't allow it.

What's Next

I am officially pausing the writing train for the next few days. I've shown you the complete architectural vision, the custom errors, the off-chain wire, and the cryptographic proof engine. Now, it's time to put down the essays and code the hell out of CHAKRA.

See you all on the other side. Thank you for reading!

Here are some final resources for y'all

Data structures and encoding | ethereum.org

An overview of the fundamental Ethereum data structures.

https://ethereum.org

The Three Lines That Save You
Inside cancel_intent.rs: The Escape Hatch Every User Hopes They Never Need

Hello again Welcome to Day 8.

In part 7 we saw initialize_intent.rs. The longest instruction in CHAKRA. Validation, escrow creation, a CPI transfer, an event emission. A lot happens in that file.

Today is the opposite. Today's file is cancel_intent.rs, and I want to warn you in advance, it is going to feel almost anticlimactic. The actual handler function is ten lines long. Maybe less depending how you count.

But I think this might be my favorite file in the whole program, because of what those ten lines represent.

Part 1: The Whole Function, Right Here

rust

pub fn handle_cancel_intent(ctx: Context<CancelIntent>) -> Result<()> {
let escrow = &ctx.accounts.escrow_account;
let clock = Clock::get()?;

require!(
    clock.slot > escrow.timeout_slot,
    ChakraError::TimeoutNotReached
);

require!(!escrow.is_finalized, ChakraError::AlreadyFinalized);
require!(!escrow.is_cancelled, ChakraError::AlreadyCancelled);

Ok(())
}

That's it. Three checks, and then Ok(()). No state gets written. No event gets emitted. No CPI happens inside this function body.

If you only looked at this function you would think, wait, where is the refund. Where does the money go back to the user. There has to be more code somewhere.

There isn't. And that is the whole point.

Part 2: Where The Real Work Happens

The refund does not happen inside the function body at all. It happens in the accounts struct, before the function even runs.

#[derive(Accounts)]
pub struct CancelIntent<'info> {
#[account(mut)]
pub owner: Signer<'info>,

#[account(
    mut,
    seeds = [b"escrow", owner.key().as_ref(), 
             &escrow_account.target_chain_id.to_le_bytes(),
             &escrow_account.nonce.to_le_bytes()],
    bump = escrow_account.bump,
    has_one = owner @ ChakraError::Unauthorized,
    close = owner
)]
pub escrow_account: Account<'info, EscrowState>,

pub system_program: Program<'info, System>,
}

Two words in there are doing the entire job. has_one and close.

has_one = owner @ ChakraError::Unauthorized tells Anchor, before you even run this instruction, go check that escrow_account.owner equals the owner pubkey that signed this transaction. If they don't match, stop immediately with Unauthorized. You do not need to write an if statement for this. Anchor writes it for you, from this one line.

close = owner is the actual refund. This tells Anchor, after this instruction finishes successfully, close this account entirely. Take every single lamport sitting in it, including the amount the user originally locked plus the rent that was paid to create the account, and send all of it to owner. Then wipe the account data and mark it as closed so it can never be read or used again.

So by the time handle_cancel_intent even starts running, Anchor has already confirmed the right person is calling this, and has already queued up the full refund to happen the moment the function returns Ok. The function's only job is to decide whether that refund is allowed to go through at all.

Part 3: The Three Gatekeepers, One More Time

clock.slot > escrow.timeout_slot. This is the whole reason cancel exists. If the timeout has not passed yet, the Sentinel Network might still be working on this intent. You do not get to grab your funds back early just because you changed your mind. TimeoutNotReached stops you.

!escrow.is_finalized. If the Sentinel Network already finished and submit_proof already ran, this escrow is done. There is nothing left to cancel. AlreadyFinalized stops you.

!escrow.is_cancelled. And this one is honestly a bit funny to me now that I am looking at it carefully for this post. Let me be upfront about something.

Part 4: A Small Honest Thing I Noticed While Writing This

Go back to Day 4 and Day 6 for a second. EscrowState has an is_cancelled boolean. events.rs has an IntentCancelled event with one field, escrow_pda.

Now look at this function again. Nowhere in here do we ever set escrow.is_cancelled = true. Nowhere do we emit!(IntentCancelled). The check require!(!escrow.is_cancelled, ...) is checking a flag that this exact function never flips to true.

Why does it not matter functionally. Because of close = owner. The moment this function succeeds, the entire account gets deleted from existence. There is no escrow left for is_cancelled to be true on. The flag was designed as a belt and suspenders thing back when I was thinking about a version where cancel just marks the escrow instead of closing it, and the close = owner approach made that flag mostly redundant.

But the missing IntentCancelled event is a real gap. If someone is building a dashboard watching CHAKRA's logs to show "this many intents succeeded, this many got refunded", they have no clean event to catch for the refund side. They would have to watch for the account closing itself, which is a much messier thing to detect from outside.

I am noting this down as something to add. A one line emit!(IntentCancelled { escrow_pda: ... }) right before the Ok(()) would fix it completely. Small thing, but these small things are exactly why I am doing this series, writing it down in public means I cannot quietly forget about it.

Part 5: Why I Actually Love How Boring This File Is

Think back to Day 1. Ronin. Wormhole. Nomad. Hundreds of millions of dollars stuck or stolen.

When those bridges had problems, what did recovery usually look like for a normal user. Wait for an announcement. Wait for a snapshot. Wait for a vote. Wait for a multisig of validators to agree on what happened and manually push a fix.

Here, on CHAKRA, if the Sentinel Network goes completely offline for whatever reason and never comes back, the path back to your money is this. Wait until your chosen timeout slot passes. Call one instruction. has_one checks you are the owner. close sends everything back. Done. No announcement needed. No vote needed. No one's permission needed.

The entire safety net for a user, the thing that means "worst case scenario, I still get my money back", fits in ten lines plus two words in an accounts struct. That is not me being lazy. That is the design goal. The less code there is standing between a user and their refund, the less there is that can ever go wrong on that path.

In document 9

In part 9 we go to the file on the complete opposite end from this one. cancel_intent.rs is what happens when nothing went right. Tomorrow's file, submit_proof.rs, is what happens when everything went right, and it is where the actual cryptography, the secp256k1_recover syscall, the keccak256 hash, the whole reason this series exists, finally runs on chain for real.

See y'all for Day 9.

Here are some resourcess for u all

https://www.reddit.com/r/solana/comments/w2ue3c/closing_and_reopening_an_ata_that_has_delegated/

https://solanacookbook.com/kr/references/accounts.html#how-to-create-a-system-account

getSignaturesForAddress

Returns confirmed transaction signatures for transactions that reference the supplied address in accountKeys, newest first.

https://solana.com

written by maha thankyou

Pulling The Trigger
Inside initialize_intent.rs: How CHAKRA Locks Funds And Starts The Clock

Welcome to Day 7.

Day 4 was state.rs, the containers. Day 5 was errors.rs, the ten promises. Day 6 was events.rs, the voice that talks to the Sentinel Network without any middleman.

All three of those files have one thing in common. They cannot do anything by themselves. A struct cannot run. An error cannot fire on its own. An event cannot emit itself.

Something has to actually call them. Something has to be the first thing that runs when a real user does a real thing.

That something is initialize_intent.rs

This is the file that starts everything. Literally everything you have read about so far in this series, the escrow, the timeout, the event the Sentinel Nodes are listening for, all of it begins the moment this single instruction is called.

Part 1: The Accounts Struct

rust

#[derive(Accounts)]
#[instruction(target_chain_id: u64, nonce: u64)]
pub struct InitializeIntent<'info> {
#[account(mut)]
pub user: Signer<'info>,
#[account(
    init,
    payer = user,
    space = EscrowState::LEN,
    seeds = [b"escrow", user.key().as_ref(), &target_chain_id.to_le_bytes(), &nonce.to_le_bytes()],
    bump
)]
pub escrow_account: Account<'info, EscrowState>,

pub system_program: Program<'info, System>,
}

Three accounts. That is it.

user is the Signer. This is whoever is initiating the cross chain intent. They have to sign because they are about to lose lamports from their wallet, and Solana will never let anyone move your lamports without your signature.

escrow_account is the star of the show. Look at the seeds. b"escrow" plus the user's pubkey plus the target_chain_id plus the nonce, all combined. This is the exact same EscrowState struct we spent all of Day 4 designing byte by byte. space = EscrowState::LEN is literally that 211 byte calculation from Day 4 finally being put to use.

system_program is there because we are about to do a CPI, and I will explain what that means in Part 4.

One small detail before we move on. Notice target_chain_id.to_le_bytes() and nonce.to_le_bytes(). LE means little endian. Keep that in your head. Hold onto it. When we get to submit_proof.rs later in this series you are going to see the exact same numbers encoded as BE, big endian, and the difference is not a mistake. It is on purpose. I will explain why when we get there.

Part 2: The Three Gatekeepers

Before anything gets written, before any lamport moves, the function runs three checks.

rust

require!(amount > 0, ChakraError::MathError);
require!(timeout_slots >= 150, ChakraError::TimeoutTooShort);
require!(timeout_slots <= 216000, ChakraError::TimeoutTooLong);

You already met all three of these errors back on Day 5. amount > 0 stops someone from creating a pointless empty intent. timeout_slots >= 150 stops someone from setting a timeout so short the Sentinel Network physically cannot finish in time. timeout_slots <= 216000 stops someone from locking an account open for years.

This is what I mean when I say errors.rs is not a side file. It is the actual logic that runs inside the actual instruction. Day 5 was not theory. Day 5 was a preview of this exact moment.

If any of these three checks fail, the entire transaction reverts. The escrow account never even gets created. No partial state. Nothing half done. Solana either does the whole thing or none of it.

Part 3: Filling In The Blueprint

Once the gatekeepers pass, we start writing into the escrow account that Anchor just created for us.

rust

escrow.owner = ctx.accounts.user.key();
escrow.target_chain_id = target_chain_id;
escrow.nonce = nonce;
escrow.amount = amount;
escrow.start_slot = clock.slot;
escrow.timeout_slot = clock.slot.checked_add(timeout_slots).ok_or(ChakraError::MathError)?;
escrow.is_finalized = false;
escrow.is_cancelled = false;
escrow.source_chain = source_chain;
escrow.target_chain = target_chain;
escrow.target_address = target_address;
escrow.bump = ctx.bumps.escrow_account;

Every single line here is one of the fields we designed in Day 4. owner, target_chain_id, nonce, amount, you have already read the reasoning for every one of these in the 60 Lines post. This is just the moment they actually get a value for the first time.

One line worth slowing down on. timeout_slot is not the timeout duration. It is current slot plus the duration. And look, it is wrapped in checked_add. If somehow adding the duration to the current slot would overflow a u64, instead of wrapping around to some tiny number in the past, the whole thing fails with MathError. This is the exact scenario I talked about on Day 5 when explaining why MathError exists. Today you are seeing the actual line of code where that protection lives.

Part 4: The Transfer, And What CPI Even Means

rust

let cpi_context = CpiContext::new(
ctx.accounts.system_program.to_account_info(),
Transfer {
from: ctx.accounts.user.to_account_info(),
to: escrow_info,
},
);

transfer(cpi_context, amount)?;

CPI stands for Cross Program Invocation. It basically means one program calling another program. Here, the CHAKRA program is calling the Solana System Program, which is the program responsible for moving lamports around.

Why can CHAKRA not just move the lamports itself directly. Because moving SOL is the System Program's job, and on Solana, programs do not bypass each other's responsibilities. CHAKRA says please, System Program, move this much from the user's account to the escrow account, and the System Program does it, because the user already signed this transaction.

The escrow account itself never signs anything here. It is on the receiving end. A PDA can receive lamports passively like this even though it has no private key, because receiving does not require a signature, only sending does.

After this line runs, the user's wallet balance just dropped by exactly amount, and the escrow PDA's balance went up by the same amount. The money is now sitting inside a Program Derived Address that only the CHAKRA program controls.

Part 5: The Signal

rust

emit!(ControlIntent {
owner: ctx.accounts.user.key(),
target_chain_id,
nonce,
amount,
source_chain,
target_chain,
target_address,
escrow_pda: escrow_key,
timeout_slot: escrow.timeout_slot,
});

This is the very last line. This is Day 6 coming full circle. The exact ControlIntent struct we walked through field by field yesterday gets emitted right here, at the very end of this function, only after everything else has already succeeded.

Order matters here. The checks ran first. The escrow got written second. The funds moved third. The signal goes out last. By the time the Sentinel Nodes hear this event, the escrow PDA on chain already has the funds sitting in it, already has all the correct fields, ready for the Sentinel to fetch and cross check.

Part 6: What This One Function Actually Proves

Step back for a second. This single function, from top to bottom, is the entire user facing promise of CHAKRA in miniature.

You give it an amount and a destination. It checks your inputs are sane. It locks your funds in a place only the program controls. It writes down everything anyone will ever need to know about this intent. And then it shouts about it to the world, in a way that cannot be faked, because the shout only happens after the lock already happened on chain.

Nothing here asks you to trust me, Maha, or trust some company, or trust a multisig of strangers. It asks you to trust Solana's runtime, which enforces that this function either runs completely or not at all.

In part 8

we look at the file on the opposite end of the spectrum. initialize_intent.rs is the longest instruction in the program. Next file, cancel_intent.rs, might be the shortest piece of meaningful code I have ever shipped. And I want to talk about why being short is actually the entire point of that file.

See y'all for Part 8.

Here are some resources if u want to dig deeper

Cross Program Invocation

Cross Program Invocation (CPI) on Solana - how programs call other programs using invoke and invoke_signed, handle PDA signers, and compose onchain functionality.

https://solana.com

Written by Maha.. thankyou

Welcome to Day 6.

Day 4 was state.rs. The data model. The containers. Day 5 was errors.rs. The ten promises. The safety guarantees.

Today is events.rs. And this one is different from the last two.

state.rs and errors.rs are about what CHAKRA remembers and what CHAKRA refuses to do. They are internal. They define the shape and the limits of the protocol.

events.rs is about how CHAKRA talks.

Specifically - how the on-chain Solana program talks to the off-chain Sentinel Network without any trusted intermediary between them.

This is one of the most underrated design problems in all of cross-chain development. You have a Solana program running inside the Solana Virtual Machine. You have Rust processes running on three different servers. How do they communicate? Who tells the servers when to start working? How do the servers know what work to do?

The answer is in this file. Three structs. Thirty lines of code. Let me show you.

Part 1: What Is a Solana Event

Before the code, the concept.

When an Anchor program emits an event, it writes structured data to the transaction logs of that transaction. Not to an account. Not to storage. To the logs.

Every Solana transaction produces logs. They are public. Anyone watching the network can read them. And crucially anyone can subscribe to them in real time via WebSocket.

So when CHAKRA's on-chain program emits a ControlIntent event, it is not sending a message to anyone specifically. It is publishing structured data to a public channel. The Sentinel Nodes are subscribed to that channel. They hear it. They act on it.

No intermediary. No message broker. No trusted relay. Just a public log and three processes listening to it.

This design means the communication channel itself cannot be corrupted. The Sentinel Nodes read directly from Solana. If they hear a ControlIntent event it is because the CHAKRA program actually emitted it, which means a user actually called initialize_intent, which means funds are actually locked in an escrow PDA. The Sentinel Nodes do not need to trust anyone who tells them to start working. They verify the source themselves.

Part 2: The File

rust

use anchor_lang::prelude::*;

#[event]
pub struct ControlIntent {
    pub owner: Pubkey,
    pub target_chain_id: u64,
    pub nonce: u64,
    pub amount: u64,
    pub source_chain: [u8; 32],
    pub target_chain: [u8; 32],
    pub target_address: [u8; 64],
    pub escrow_pda: Pubkey,
    pub timeout_slot: u64,
}

#[event]
pub struct IntentFinalized {
    pub escrow_pda: Pubkey,
    pub tx_hash: [u8; 64],
}

#[event]
pub struct IntentCancelled {
    pub escrow_pda: Pubkey,
}

Three events. Each one marks a different moment in the lifecycle of a cross-chain intent.

Part 3: ControlIntent — The Starting Gun

rust

#[event]
pub struct ControlIntent {
    pub owner: Pubkey,
    pub target_chain_id: u64,
    pub nonce: u64,
    pub amount: u64,
    pub source_chain: [u8; 32],
    pub target_chain: [u8; 32],
    pub target_address: [u8; 64],
    pub escrow_pda: Pubkey,
    pub timeout_slot: u64,
}

This is the event that starts everything.

When a user calls initialize_intent and it succeeds funds locked, escrow created, all validations passed - the CHAKRA Controller emits this event to the transaction logs.

The Sentinel Nodes are watching. They parse it. They start the signing ceremony.

Let me walk through every field and explain why it is here.

owner — the Pubkey of the user who created the intent. The Sentinel Nodes need this to verify that the escrow PDA they are about to work on actually belongs to the person they think it belongs to. It is also in the escrow account on-chain. The Sentinel cross-references both.

target_chain_id — which blockchain to execute on. Base Sepolia is 84532. This number goes into the message payload that the Sentinel Nodes sign. The same number goes into the ChakraReceiver.sol call on the target chain. The ChakraReceiver verifies it. If the Sentinel tried to execute on a different chain than the one the user specified, the signature would not verify because the chain ID would be wrong.

nonce — the uniqueness identifier for this specific intent. Combined with the owner's address and the chain ID it is part of the PDA seed. So when the Sentinel has the nonce, it can deterministically compute the escrow PDA address and fetch the account to cross-check all the other fields.

amount — how many lamports are locked. This also goes into the signing payload. The ChakraReceiver contract verifies the signature over this amount. If a Sentinel tried to execute a different amount than what the user specified, the signature would fail verification on the target chain.

source_chain and target_chain — both 32-byte arrays identifying the chains involved. source_chain is always "solana" in the current implementation. target_chain is "base" or "ethereum" etc. These go into the event so the Sentinel Nodes can route the execution correctly. If CHAKRA supports five target chains in the future, the Sentinel Network uses this field to know which chain's RPC to call.

target_address — 64 bytes. The destination address on the target chain where the execution should happen or the funds should go. This is the most sensitive field in the event. If this were tampered with, the execution would go to the wrong address. The fact that it is signed as part of the TSS payload means any tampering would invalidate the signature and the ChakraReceiver would reject it.

escrow_pda — the address of the escrow account holding the user's funds. The Sentinel Nodes use this to verify the event data matches what is actually on-chain before starting the signing ceremony. This is the cross-check. The event data could theoretically be crafted. But the escrow account on-chain cannot be faked. The Sentinel fetches the escrow by this PDA and verifies everything matches.

timeout_slot — the absolute deadline. The Sentinel Network must complete execution and submit proof before this slot. The coordinator checks the current slot against this value before starting work. If it is already past the deadline — maybe the event was delayed, maybe the signing took too long — the coordinator aborts rather than wasting gas on an execution that can never be verified on time.

Every field in ControlIntent has a job. Nothing is there by accident.

Part 4: IntentFinalized — The Confirmation

rust

#[event]
pub struct IntentFinalized {
    pub escrow_pda: Pubkey,
    pub tx_hash: [u8; 64],
}

This event fires when submit_proof succeeds.

The TSS signature verified. The escrow closed. The lamports went to treasury.

Two fields.

escrow_pda — which intent was finalized. Any indexer, any dashboard, any monitoring tool watching CHAKRA's program logs can use this to track intent states in real time.

tx_hash — the transaction hash of the execution on the target chain. This is the receipt. When a user wants to verify that their intent was actually executed on Base Sepolia, this is the hash they take to the Base Sepolia block explorer. It is stored in the event so it is permanently on-chain as part of the Solana transaction record.

This matters for auditability. In a world where "trust me it happened on the other chain" is not acceptable, IntentFinalized puts the cross-chain receipt permanently on Solana. Every intent execution is publicly verifiable from the Solana side.

Part 5: IntentCancelled — The Safe Exit

rust

#[event]
pub struct IntentCancelled {
    pub escrow_pda: Pubkey,
}

The simplest event. One field.

This fires when cancel_intent succeeds. The timeout passed. The Sentinel Network did not complete in time. The user called cancel. The funds returned.

One field because there is nothing else to record. The escrow PDA tells you which intent was cancelled. There is no target chain transaction hash because no target chain execution happened. There is no amount because the amount went back to the user and that is a Solana-side operation recorded in the cancel transaction itself.

The simplicity of IntentCancelled is actually a design signal. If you see mostly IntentFinalized events in the logs, the protocol is working well. If you start seeing a lot of IntentCancelled events, something is wrong with the Sentinel Network. The events tell the story of protocol health in real time.

Part 6: How the Sentinel Actually Reads These

This is the part most people do not think about.

Anchor events are emitted as base64-encoded binary data in the transaction logs. They look like garbage to a human reading the raw logs. The Sentinel Nodes have to:

1. Subscribe to Solana transaction logs for the CHAKRA program via WebSocket

2. Filter for logs that contain "Program data:" — that is where Anchor encodes events

3. Base64-decode the data

4. Check the first 8 bytes he Anchor event discriminator

5. Verify it matches the discriminator for ControlIntent specifically

6. Deserialize the remaining bytes into the ControlIntent struct

The discriminator is computed as the first 8 bytes of SHA256("event:ControlIntent"). This is how the Sentinel knows it is looking at a ControlIntent and not some other event or log line.

If the discriminator does not match, the Sentinel ignores it and moves on. If it does match, the Sentinel trusts the data not because the event claimed to be valid, but because the event came from the CHAKRA program's address and the Solana validator already verified that the program executed correctly.

This is the security model of Solana events. You do not trust the data in isolation. You trust it because of where it came from and the fact that it is permanently embedded in a finalized transaction.

Part 7: The Core Foundations Are Set

With state.rs, errors.rs, and now events.rs completely laid out, you have seen the entire structural anatomy of CHAKRA:

1. The Container: How we pack every byte tightly on-chain to minimize user rent.

2. The Guardrails: The ten strict promises that make our protocol refuse to collapse.

3. The Voice: How we broadcast cryptographically verifiable signals to the off-chain world without middlemen.

We are officially done with the setup files. The architectural blueprint is complete.

In the upcoming days, things turn even more interesting. We are shifting from structure to action opening up the heavy-hitting instruction engines, starting with the file that triggers the entire machine: initialize_intent.rs. Every read from here on out gets closer to the live mainframe.

and see y'all for Day 7.

Thankyou for reading. And here are some resources you can refer to

Transaction Confirmation & Expiration

Understand how Solana transaction confirmation and when a transaction expires (including recent blockhash checks).

https://solana.com

logsSubscribe

Subscribe to transaction log messages that match a log filter.

https://solana.com

https://solanacookbook.com/references/programs.html#how-to-transfer-sol-in-a-program

Written by Maha..

CHAKRA SERIES - 5

Welcome to Day 5.

Yesterday we looked at state.rs. The four structs. The data model. The containers that hold every piece of information CHAKRA needs to remember about a cross-chain intent.

If state.rs is the blueprint of the building, today's file is the list of ways the building is not allowed to collapse.

It is called errors.rs. It is ten lines of code. And I want to spend today showing you why those ten lines tell the entire security story of CHAKRA more clearly than any whitepaper could.

Part 1: Why Error Codes Are Not Just Error Messages

When most people think about errors in code they think about something going wrong. A crash. A bug. Something you did not plan for.

In a Solana program errors are the opposite of that.

In a Solana program errors are things you planned for very carefully. They are the explicit list of every situation where the program decides to reject an operation and return funds or stop execution rather than continue.

In a normal application when something goes wrong the worst case is maybe a bad user experience. Some wrong data. A UI that breaks.

In a cross-chain protocol when something goes wrong the worst case is someone losing real money. Permanently. With no way to recover it.

So errors are not afterthoughts. Errors are the contract CHAKRA makes with every user. Here is every situation where we will stop. Here is every situation where we will protect you. Here is every edge case we have thought about and decided how to handle.

Ten error codes. Ten promises.

Part 2: The File

rust

use anchor_lang::prelude::*;

#[error_code]
pub enum ChakraError {
    #[msg("The requested timeout is too short for cross-chain finality.")]
    TimeoutTooShort,
    #[msg("The requested timeout is unreasonably long.")]
    TimeoutTooLong,
    #[msg("The cross-chain intent has not timed out yet.")]
    TimeoutNotReached,
    #[msg("The cross-chain intent has timed out and can no longer be finalized.")]
    TimeoutReached,
    #[msg("This intent has already been finalized by a ZK-Proof.")]
    AlreadyFinalized,
    #[msg("This intent has already been cancelled.")]
    AlreadyCancelled,
    #[msg("User is not authorized to manage this intent.")]
    Unauthorized,
    #[msg("The signer is not an authorized Sentinel node.")]
    UnauthorizedSentinel,
    #[msg("Mathematical overflow or underflow occurred.")]
    MathError,
    #[msg("The provided cryptographic proof is invalid or improperly signed.")]
    InvalidProof,
}

That is the entire file.

Now let me walk through every single error and tell you exactly what situation it is protecting against.

Part 3: The Timeout Errors

There are four errors that deal with time. This is not a coincidence. Time is the hardest thing to get right in a cross-chain system and I got it wrong twice before I got it right.

TimeoutTooShort

rust

#[msg("The requested timeout is too short for cross-chain finality.")]
TimeoutTooShort,

When you call initialize_intent you pass a timeout_slots parameter. This is how long the Sentinel Network has to complete execution before you can cancel and get a refund.

The minimum is 150 slots.

Why 150? Because Solana produces a slot approximately every 400 milliseconds. 150 slots is about 60 seconds. That is the absolute minimum time the Sentinel Network needs to hear the ControlIntent event, coordinate the threshold signing ceremony across three nodes, send the transaction to the target chain, wait for confirmation, and submit the proof back to Solana.

If you try to set a timeout shorter than that, TimeoutTooShort fires. Immediately. Before your funds are locked. Before anything happens.

This error protects you from accidentally setting a timeout so short that the Sentinel Network cannot physically complete the execution before you can cancel it. Without this check a malicious user could set a 1-slot timeout, immediately call cancel, and try to race the system into a broken state.

TimeoutTooLong

rust

#[msg("The requested timeout is unreasonably long.")]
TimeoutTooLong,

The maximum is 216000 slots. That is about 24 hours.

This might seem unnecessary. Why would you care if a timeout is too long?

Because if there is no upper limit, someone could create an intent with a 10-year timeout. Their funds would be locked in the escrow account for 10 years. The protocol would have to maintain that account forever. The rent would need to stay funded. And if the Sentinel Network ever changes — new keys, new nodes, upgraded protocol — that ancient intent with a 10-year timeout would be stuck in limbo with no clean way to handle it.

24 hours is long enough for any reasonable cross-chain execution. If it has not happened in 24 hours something has seriously gone wrong and you should get your money back.

TimeoutNotReached

rust

#[msg("The cross-chain intent has not timed out yet.")]
TimeoutNotReached,

This one fires when you try to call cancel_intent too early.

The Sentinel Network is still working. The execution might still succeed. The timeout has not passed yet. You do not get to cancel yet.

This protects the protocol's integrity. Imagine if you could cancel at any time regardless of timeout. You could initiate an intent, the Sentinel Network starts working, and then you immediately cancel and get your refund. The Sentinel Network continues executing on the target chain anyway — spending gas, completing transactions — and now the proof it tries to submit will fail because you already cancelled. The target chain loses fees for nothing.

TimeoutNotReached prevents that. The Sentinel Network gets the full timeout window to complete its work.

TimeoutReached

rust

#[msg("The cross-chain intent has timed out and can no longer be finalized.")]
TimeoutReached,

This is the mirror. If the Sentinel Network tries to submit a proof after the timeout has already passed, TimeoutReached fires.

The window is closed. The user has already cancelled or can cancel immediately. The protocol will not accept late proofs. A late proof could lead to a situation where the user already got their refund and then the target chain execution also happened — meaning double payment.

TimeoutReached is the hard deadline. It is enforced by the slot clock. No exceptions.

Part 4: The State Errors

AlreadyFinalized

rust

#[msg("This intent has already been finalized by a ZK-Proof.")]
AlreadyFinalized,

Once an intent is finalized it is done. The escrow is closed. The funds went to treasury. There is nothing left to do.

If anything tries to interact with a finalized intent — a second proof submission, a cancel attempt, anything — AlreadyFinalized fires.

Notice the error message says "ZK-Proof" even though the current implementation uses TSS. The message is forward-looking. The verification mechanism will upgrade. The principle stays the same. Once it is finalized, it is immutable.

AlreadyCancelled

rust

#[msg("This intent has already been cancelled.")]
AlreadyCancelled,

Same logic in the other direction. Once cancelled the escrow is closed. The funds went back to the user. Nothing can change that.

AlreadyFinalized and AlreadyCancelled together create what engineers call mutual exclusion. An intent can reach exactly one terminal state. Not both. Not neither. Exactly one. The two booleans in EscrowState enforce this. These two errors enforce it at every interaction point.

This is what prevents double-spend and double-refund. Not by accident. By explicit design.

Part 5: The Authorization Errors

Unauthorized

rust

#[msg("User is not authorized to manage this intent.")]
Unauthorized,

This fires when someone tries to cancel an intent they did not create.

The EscrowState stores the owner field. The cancel_intent instruction checks that the signer matches the owner. If they do not match, Unauthorized fires and nothing happens.

You cannot cancel someone else's escrow. You cannot steal someone else's refund. The program enforces ownership at the instruction level.

UnauthorizedSentinel

rust

#[msg("The signer is not an authorized Sentinel node.")]
UnauthorizedSentinel,

This fires when something tries to call submit_proof but is not a registered Sentinel Node.

Remember from yesterday — SentinelAccount exists in state.rs. The admin registers Sentinel Nodes explicitly. If you are not in that registry, you cannot submit proofs. Period.

This prevents anyone from submitting fake proofs. Even if someone figured out how to forge a valid TSS signature — which is cryptographically infeasible — they would still fail here because they are not in the authorized Sentinel registry.

Defense in depth. The cryptography is one layer. The authorization registry is a second layer.

Part 6: The Safety Errors

MathError

rust

#[msg("Mathematical overflow or underflow occurred.")]
MathError,

On Solana, mathematical overflow in a program causes a panic by default in debug mode. In release mode the behavior depends on your settings.

In CHAKRA we use checked arithmetic everywhere that matters. Instead of a + b we use a.checked_add(b).ok_or(ChakraError::MathError)?. If the addition would overflow a u64, instead of wrapping around to a tiny number or crashing, we return MathError and stop.

Why does this matter for a cross-chain protocol?

Because amounts and slot numbers are u64 values. If someone crafted an intent where adding timeout_slots to the current slot would overflow, the resulting timeout_slot would be a tiny number in the past. The intent would immediately be cancellable. The Sentinel Network would never get a chance to execute.

MathError catches that. The intent never gets created.

InvalidProof

rust

#[msg("The provided cryptographic proof is invalid or improperly signed.")]
InvalidProof,

This is the last line of defense.

When a Sentinel Node calls submit_proof, the program reconstructs the message hash, calls secp256k1_recover with the provided signature components, and compares the recovered public key against the registered TSS public key.

If they do not match — if the signature is wrong, if the message was constructed incorrectly, if any byte is off — InvalidProof fires. The escrow stays locked. The funds stay safe. Nothing changes.

InvalidProof is what makes the cryptographic guarantee real. It is the moment where math meets money. Either the proof is valid and the escrow releases, or it is not and everything stays exactly as it was.

Part 7: What I Actually Got Wrong

I want to be honest about something.

The first version of this file had seven errors. I was missing TimeoutTooLong, MathError, and UnauthorizedSentinel.

TimeoutTooLong I missed because I was thinking about the minimum but not the maximum. One pointed out the long-lock attack during a code review I did informally.

MathError I missed because in my test environment the numbers were always small. It was only when I started thinking about what a malicious actor could pass as inputs that I realized I needed checked arithmetic everywhere.

UnauthorizedSentinel I missed because early on there was only one Sentinel Node running — mine. No need for an authorization registry when there is only one node. As soon as I moved to three nodes the need became obvious.

Three errors added because I thought more carefully about attacks.

That is how you build security. Not by getting it right the first time. By thinking about every person who might want to break the thing you built and making sure you have thought about them too.

The Contract Is Signed Every single one of these errors acts as a hard boundary. They make sure the program logic stays entirely inside its intended lane. Without them, a state-changing transaction isn't just code executing it's a massive vulnerability waiting to be triggered by an edge-case attack vector. By defining exactly how and why our system will refuse to act, we give users absolute predictability. They know their funds can never settle into an unpredictable, stuck state. It is either total cross-chain finality or an immediate, clean refund. Now that we have mapped out the blueprint in state.rs and defined our safety boundaries in errors.rs, we finally have everything we need to build the actual engine.

Some resources for you to refer

Written by Maha thankyou for reading

Welcome to Day 4. Today, we leave the high-level concept papers behind and look at the actual code defining CHAKRA. Before we talk about threshold signatures or complex execution logic, we have to talk about the bedrock: how we model our data on-chain.

We are looking directly at the codebase, starting with the foundation that everything else rests on - The Rust state.

Firstly let me tell you something about how protocols actually work.

Most people think the hardest part of building a cross-chain protocol is the cryptography. The threshold signatures. The distributed key generation. The Lagrange interpolation.

And yes that stuff is hard. I spent months on it.

But you know what breaks protocols more often than bad cryptography?

Bad data models.

Decisions made in the first week of writing code that you can never take back. Fields that are in the wrong place. Types that are too small. Booleans that should have been enums. Accounts that were never designed to be closed cleanly.

These decisions live forever in a deployed program. On Solana they live in accounts. And accounts cost rent. And rent means real money. So every byte you waste is real money wasted by real users.

Today I want to show you the file where I made all those decisions for CHAKRA.

It is called state.rs. It is 60 lines of Rust. And it is the foundation that every single other piece of CHAKRA is built on.

Part 1: What Is State in an Anchor Program

If you have never written Solana programs before this concept is important to understand.

On Ethereum when your smart contract saves data it goes into contract storage. The contract owns the storage. You cannot really separate them.

On Solana it works completely differently.

Programs do not store data. Programs are stateless. They are just logic. Pure logic.

Data lives in accounts. Separate accounts. Owned by the program but separate from it.

So when CHAKRA needs to remember something — who initiated an intent, how much they locked, what the timeout is, whether it has been finalized — all of that lives in an account. A specific account structure defined in state.rs.

Think of state.rs as the blueprint. The struct definitions. The shapes of the containers. The program logic uses these containers. The accounts on-chain hold the data. state.rs is what connects the two.

Part 2: The Four Structs

CHAKRA has four account types defined in state.rs.

I am going to walk through each one slowly.

TssConfig

rust

#[account]
pub struct TssConfig {
    pub tss_pubkey: [u8; 64],
    pub threshold: u8,
    pub total_nodes: u8,
    pub admin: Pubkey,
    pub bump: u8,
}

This is the most important account in the entire protocol.

tss_pubkey is a 64-byte array. Not 65 bytes. Not 33 bytes. 64 bytes exactly.

Why 64?

A secp256k1 public key in uncompressed form is 65 bytes. But the first byte is always 0x04 — it is a prefix that just says "this is an uncompressed key." It carries no information. So we strip it and store only the 64 bytes of actual key material.

This 64-byte value is what every TSS proof gets verified against. When the Sentinel Network signs an intent and submits the proof, Solana runs secp256k1_recover on the signature and recovers a public key. That recovered key gets compared byte by byte against this field. If they match the proof is valid. If they do not match the proof is rejected.

Everything depends on this field being correct.

threshold and total_nodes are u8 — unsigned 8-bit integers. Maximum value 255. We only have 3 nodes right now so u8 is more than enough. These fields exist so the program knows the signing rules. Currently 2-of-3.

admin is the Pubkey that is allowed to update the TssConfig. This is important for key rotation. If the Sentinel Network needs to refresh its keys in Milestone 2, the admin can call update_tss_config to register the new public key. Nobody else can.

bump is the canonical bump seed for the PDA derivation. I will explain why we store this in Part 3.

Space calculation: 8 (Anchor discriminator) + 64 + 1 + 1 + 32 + 1 = 107 bytes.

EscrowState

rust

#[account]
pub struct EscrowState {
    pub owner: Pubkey,
    pub target_chain_id: u64,
    pub nonce: u64,
    pub amount: u64,
    pub start_slot: u64,
    pub timeout_slot: u64,
    pub is_finalized: bool,
    pub is_cancelled: bool,
    pub bump: u8,
    pub source_chain: [u8; 32],
    pub target_chain: [u8; 32],
    pub target_address: [u8; 64],
}

This is the escrow account. One of these gets created every time a user initiates a cross-chain intent. It holds all the information about that specific intent.

Let me go field by field because every single one matters.

owner — the Pubkey of the user who created this intent. This is the person who gets refunded if the intent times out and cancel is called. The program enforces this. You cannot call cancel on someone else's escrow.

target_chain_id — a u64 representing the EIP-155 chain ID of the target blockchain. Base Sepolia is 84532. Ethereum mainnet is 1. Polygon is 137. This is a standard. We use it so the Sentinel Nodes and the ChakraReceiver contract can both independently verify they are working on the same chain.

nonce — a u64 that makes each intent unique. If you send 100 intents to Base you need 100 different nonces. The PDA seed includes the nonce so each intent gets its own account address. Without nonces all your intents would try to write to the same account and fail.

amount — how many lamports the user locked. u64 because lamport values can be large and u64 goes up to about 18 quintillion. More than enough.

start_slot — the Solana slot when the intent was created. We record this for analytics and for potential dispute resolution in future versions.

timeout_slot — the absolute slot number after which cancel_intent becomes callable. Not a duration. An absolute slot. This is important. When initialize_intent runs it takes the current slot and adds timeout_slots to get this value. After that the user can always recover their funds. The Sentinel Network has until this slot to complete execution and submit proof. After this slot the protocol gives up and refunds.

is_finalized — boolean. True when a valid TSS proof has been submitted and verified. The escrow account gets closed when this happens.

is_cancelled — boolean. True when the intent timed out and was cancelled. The escrow account gets closed when this happens too.

These two booleans are your safety net. Before any state-changing operation the program checks both. If is_finalized is true you cannot cancel. If is_cancelled is true you cannot finalize. You cannot accidentally double-spend. You cannot accidentally double-refund.

bump — PDA bump. Same reason as TssConfig.

source_chain — 32 bytes. Usually contains a string like "solana" zero-padded to 32 bytes. This tells the Sentinel Network where the intent originated.

target_chain — 32 bytes. Usually contains "base" or "ethereum" zero-padded.

target_address — 64 bytes. This is the destination address on the target chain. 64 bytes because we want to support any chain. An Ethereum address is 20 bytes. A Bitcoin address is much shorter. A Solana address is 32 bytes. By making this field 64 bytes we can support all of them with room to spare. The unused bytes are zero-padded.

Space calculation: 8 + 32 + 8 + 8 + 8 + 8 + 8 + 1 + 1 + 1 + 32 + 32 + 64 = 211 bytes.

GlobalConfig

rust

#[account]
pub struct GlobalConfig {
    pub admin: Pubkey,
    pub treasury: Pubkey,
    pub is_initialized: bool,
    pub bump: u8,
}

The protocol-wide configuration. Created once by the admin when the program is first set up.

admin — who controls the protocol. Can add and remove Sentinel Nodes. Can update the TssConfig. Full protocol authority.

treasury — where the lamports go when an escrow is finalized. When submit_proof runs and verifies successfully, the escrow account closes and the lamports go here. This is how the protocol captures fees in future versions.

is_initialized — a simple guard against calling initialize_config twice. Once it is true, you cannot reinitialize. This prevents a class of attack where someone tries to reset protocol state after it is already set up.

bump — PDA bump.

Space calculation: 8 + 32 + 32 + 1 + 1 = 74 bytes.

SentinelAccount

rust

#[account]
pub struct SentinelAccount {
    pub sentinel_pubkey: Pubkey,
    pub is_active: bool,
    pub bump: u8,
}

The authorization record for a Sentinel Node.

For a Sentinel Node to call submit_proof it needs to be in this registry. The admin creates a SentinelAccount for each node when it is authorized. The admin can deactivate a node by setting is_active to false without deleting the account.

sentinel_pubkey — the Solana keypair address of the Sentinel Node process. When a Sentinel Node signs and submits a transaction, this is the key it signs with.

is_active — the on/off switch. If a Sentinel Node is compromised, the admin sets this to false immediately. Any further proof submissions from that node fail the authorization check. The attack is contained.

bump — PDA bump.

Space calculation: 8 + 32 + 1 + 1 = 42 bytes.

Part 3: Why We Store the Bump

Every single struct has a bump field. If you are new to Solana this might seem weird. Let me explain.

Program Derived Addresses on Solana are calculated from seeds and a bump value. The bump is a number from 0 to 255 that is decremented until the derived address is not on the secp256k1 curve — meaning it has no corresponding private key and only the program can sign for it.

The canonical bump is the highest valid bump. Anchor finds this automatically when you use the init constraint.

Why store it? Because every time you want to verify or use a PDA in a subsequent instruction you need to recalculate it from the seeds and bump. If you store the bump you save the computation of finding it again. More importantly you make the account addresses deterministic — given the same seeds and stored bump, you always get the same address. No ambiguity.

In production Solana programs storing the bump is standard practice. It also saves compute units which costs less in fees.

Part 4: What This File Does Not Contain

state.rs has no logic. Zero.

No function calls. No if statements. No calculations. Nothing.

Just structure definitions.

This is intentional. In Anchor the state and the logic are completely separate. The instructions in the instructions/ folder handle all the logic. state.rs is purely the data model.

This separation makes the code much easier to audit. If you want to understand what can go wrong with an EscrowState account, you read the instructions that use it. The state definition itself cannot have bugs because it cannot do anything.

Part 5: The Cost of a Byte

When I was designing these 4 structs, I spent hours counting bytes ofcourse with alot of errors. On Solana, data storage isn't free. Every byte you store requires "rent exemption," which means locking up real SOL.

If you design a sloppy data model that wastes 100 bytes per transaction, and your protocol processes 10,000 transactions a day, you are burning your users' money for nothing. That’s why TssConfig is exactly 107 bytes, and EscrowState is a tight 211 bytes. We store only what is mathematically required to guarantee safety.

This file is the bedrock. It doesn't execute anything, but it defines the boundaries of what CHAKRA can and cannot do. If the container is broken, the logic inside it won't matter.

I know looking at raw structs can feel dry if you're waiting for the action, but you can't build a mainframe without laying down the foundation first. Now that you know the exact shape of our state and why every single field exists... we are ready to make it move.

Tomorrow for Day 5, we are opening up the next file. We’ll look at the actual Rust logic that takes these structs, locks the funds, and spins the gears into motion.

Here are some resources

Accounts

Solana accounts are the fundamental data unit for storing state on the network. Account structure, addresses, types, rent, ownership, and modification rules.

https://solana.com

Written by Maha.. See y'all tomorrow.

Hello everyone for day 3 of building chakra

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 ..

Part 1: The Four Components

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 )

Part 2: What Actually Happens When You Use CHAKRA

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..

Part 3: What This Proves

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.

Hello everyone,

Welcome to the day 2 series of chakra. Yesterday I showed you the problem.

$2 billion stolen. Not because of bad luck. Not because of careless developers. Because of one architectural decision that every bridge in existence still uses. Lock real assets in a custody contract. Create a honeypot. Watch it get drained.

I ended with one question.

What if the honeypot simply did not need to exist.

Today I am going to answer that question. Not the full answer. Not yet. Today is just the idea. The insight. The thing that made me start building.

The actual system, the code, the proof that it works, that comes tomorrow.

Today, just understand what changes when you think about this differently.

Part 1: The Root Cause One More Time

Before I show you the solution I need to make sure the problem is absolutely clear. Because the solution only makes sense if you understand exactly what it is solving.

The bridge problem is not a code quality problem. It is not a team quality problem. It is not a security process problem.

It is a structural problem.

The structure is this. To use an asset on another chain, bridges move that asset into custody. A smart contract holds it. That smart contract becomes a target. The target gets hit.

Every attempt to fix bridges works within this structure. Better validators. More audits. Time delays. Emergency pause buttons. Multi-signature controls. These are all improvements to the security of the custody contract. They make the target harder to hit. They do not remove the target.

The only real fix is to remove the target entirely.

And the only way to remove the target is to never put assets in custody in the first place.

Which means the only real fix is to find a way for one blockchain to control assets on another blockchain without moving those assets anywhere.

That is what CHAKRA does.

Part 2: The Insight That Changes Everything

Here is the core insight behind CHAKRA. Read this slowly because it is the entire idea in two sentences.

Every blockchain account is controlled by a private key. Whoever holds that private key controls that account.

That is it. That is the whole thing. An Ethereum account is not controlled by a human being. It is not controlled by a company. It is not controlled by a government. It is controlled by 64 hexadecimal characters. A private key. Whoever possesses that key can sign transactions from that account. That is the only rule that matters on any blockchain that has ever been built.

So here is the question CHAKRA asks.

What if a Solana program possessed the private key to an Ethereum account.

Not a human. Not a company. A Solana program. A piece of code living on the Solana blockchain. What if that program held the key that controlled an Ethereum wallet.

Then that Solana program could sign Ethereum transactions. Directly. Natively. Without any bridge. Without any wrapped token. Without any custody contract sitting somewhere full of money waiting to be stolen.

You call the Solana program. The Solana program signs an Ethereum transaction. The Ethereum network receives a valid native signature and executes. Your ETH never moved. Your ETH was never locked. Your ETH sat in an Ethereum account the entire time. The only thing that changed is who controls that account. And the answer is a Solana program controls it. Through cryptography alone.

No honeypot. Because there is nothing to put in a honeypot. Because there is no vault. Because the ETH never left Ethereum.

This is the idea. Now let me show you the problem inside the idea.

Part 3: The Signature Problem

If you understood Part 2 your immediate next question is probably this.

How does a Solana program hold an Ethereum private key. A program is code. Code does not secretly store a key somewhere safe. And if the key is stored on-chain, anyone can read it. And if anyone can read it, anyone can steal it and take full control of the Ethereum account instantly.

This is the Signature Problem. It is the hardest technical challenge in all of cross-chain execution. Every project that has ever tried to do what CHAKRA does has had to answer this question. Most of them either gave up entirely or built something that required an entirely new blockchain to solve it. A new chain with its own token. Its own validators. Its own ecosystem you have to learn and trust.

CHAKRA solves it without leaving Solana. Without a new chain. Without a new token. Inside the SVM itself.

The answer is something called Distributed Key Generation.

Here is the idea.

Instead of one private key stored in one place, CHAKRA splits the key into multiple pieces called shards. These shards are distributed across a network of independent computers called Sentinel Nodes. Each Sentinel Node holds exactly one shard. No single Sentinel Node ever holds the complete key. No single node can do anything alone.

Think about what this means for security.

In a bridge there is one target. One custody contract. Find the flaw in that contract and take everything. This is what happened to Ronin. This is what happened to Wormhole. This is what happened to Nomad.

In CHAKRA there is no single target. The key exists nowhere in complete form. It has never existed in complete form in any one place since the moment it was generated. To forge a signature an attacker would need to compromise multiple independent Sentinel Nodes simultaneously. Nodes running on different hardware. In different locations. Operated by different people. Not one vulnerability to find. Many. All at the same time.

The math behind this is called Threshold Signature Schemes. TSS. The specific model CHAKRA uses is 2-of-3. Three Sentinel Nodes each hold one shard. Any two of them can cooperate to produce a valid signature. All three are never required. Which means even if one node goes completely offline the system still works. But an attacker who compromises only one node has absolutely nothing. One shard of three. Mathematically useless without the others.

This is the cryptographic foundation of CHAKRA. Not custody. Key distribution. Not a vault. A threshold. Not a target. A network.

The bridge creates something to steal. CHAKRA creates nothing to steal.

Tomorrow

The idea is clear. The problem inside the idea is clear. The cryptographic answer to that problem is clear.

But an idea is not a product. A concept is not a system. A threshold signature scheme described in plain English is not a threshold signature scheme running on real hardware producing real signatures on a real testnet.

In next few days I will show you what is actually running. The Anchor program on Solana Devnet. The Sentinel Nodes communicating over a real network. The signing ceremony happening in real terminals. The transaction landing on Base Sepolia hopefully.. slowly and steadily without any rush..

Not descriptions. Not slides. The actual system doing the actual thing.

Here are some documents u can refer to study to get better understanding of the terms
https://docs.near.org/chain-abstraction/chain-signatures
https://www.zetachain.com/whitepaper.pdf (The "Architectural Proof": Section 3 and 4 describe how their "Observer-Signer" nodes allow contracts to manage external assets natively. It’s the closest technical cousin to what am building)
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=11455143 ( this is a complicated read. This is the foundational research paper for Threshold Signature Schemes (TSS))
https://hackmd.io/Ge_rpr9GTnGGF2oULTGJrg ( this is also a complicated tough read as u read technical deep dive shows exactly how a 2-of-3 MPC model works in production for millions of users. It proves that chakras model "Sentinel Node" architecture is reliable and fast. )

Written by Maha.. See y'all tomorrow.

Before We Start

I want to tell you something before any technology gets mentioned.

In 2022, more than $2 billion was stolen from the crypto industry.

Not through password hacks. Not through phishing emails. Not because developers were careless or stupid or asleep at the wheel.

It was stolen because of one single architectural decision. A decision so deeply embedded in how blockchains connect to each other that almost nobody questions it anymore. A decision that every single cross-chain project in existence still uses today.

This document is about that decision. What it is. Why it exists. Why it is broken beyond repair. And the question it forced me to ask.

Tomorrow I will show you what I built because of that question.

Today, just understand the problem.

Part 1: The Island Problem

Imagine the internet. But instead of one global internet that everyone shares, every country has its own completely separate internet with zero connection to any other.

America has its internet. Japan has its internet. India has its internet.

A website that exists on America's internet does not exist on Japan's internet. They cannot share files. They cannot send messages to each other. They cannot even see each other. Completely isolated. Completely parallel. Like two universes that happen to exist at the same time but can never touch.

Now imagine each country's internet has its own money. Americans use dollars on their internet. Japanese use yen on theirs. Indians use rupees on theirs. And because the internets are completely separate, those currencies can never interact. Not because of exchange rates. Not because of government rules. Because the underlying systems have no way to communicate at all.

If you want to buy something from a Japanese website using your American dollars, you literally cannot do it. The two systems do not know each other exist.

This is exactly the situation with blockchains today. Not approximately. Exactly.

Bitcoin is one island. Running since 2009. Extraordinarily secure. Extraordinarily valuable. Right now approximately $900 billion worth of Bitcoin exists in the world. Nine hundred thousand million dollars. And Bitcoin can only do one thing: record who owns which Bitcoin. That is it. It cannot run complex programs. It cannot talk to Ethereum. It does not know Ethereum exists. $900 billion sitting on an island with no bridge to anywhere.

Ethereum is another island. It can run complex programs called smart contracts. It powers lending protocols, trading platforms, NFT markets, and thousands of applications. Genuinely remarkable technology. Also completely isolated from Bitcoin. Ethereum can see Bitcoin from a distance the way you can see a mountain through your window. It cannot touch it. Cannot reach it. Cannot do anything with it.

Solana is a third island. The fastest blockchain ever built. 65,000 transactions per second. 150 millisecond finality. One of the most powerful financial computation engines humanity has ever created. Also completely cut off from everything else. Solana cannot send a transaction to Ethereum. Solana cannot control a Bitcoin wallet. Solana cannot reach outside of itself in any direction.

Every major blockchain is its own island. Polygon. Avalanche. Base. Arbitrum. Sui. Aptos. Each one brilliant in its own specific way. Each one completely isolated from all the others.

Now here is why this matters in real money with real consequences.

That $900 billion in Bitcoin cannot participate in lending on Ethereum. It cannot be used as collateral on Solana. It cannot be put to work in the broader financial ecosystem that has been built across every other chain. Nine hundred billion dollars essentially frozen. Sitting on one island. Unable to interact with anything outside that island. Locked away not by law or regulation but by architectural reality.

This is the single biggest limitation holding back the entire crypto industry. Trillions of dollars of value locked in isolated systems that were never designed to talk to each other.

People needed a solution. So they built one.

They called it a bridge.

Part 2: How Bridges Work

To understand why bridges fail, you need to understand how they actually work. Not at a vague high level. At the real mechanical level. Because the failure does not live in the idea. It lives in the mechanics. And once you see the mechanics clearly you will never look at a bridge the same way again.

Simple example. You have 1 ETH on Ethereum. You want to use that ETH on Solana. Maybe there is a great lending protocol on Solana offering excellent interest rates and you want to deposit your ETH there as collateral.

Here is exactly what a bridge does.

Step one. You send your ETH to the bridge contract on Ethereum.

The bridge has a smart contract deployed on Ethereum. A piece of code living on the blockchain. You send your 1 ETH to that contract. The contract locks it. Your ETH is now sitting inside the bridge's vault. You no longer control it. The contract does. It is held in custody.

Step two. The bridge mints a copy on Solana.

The bridge now creates something on Solana. It is called wETH. Wrapped ETH. It looks exactly like ETH. Its price tracks ETH in real time. You can trade it, lend it, use it as collateral, do almost anything with it that you could do with real ETH. But it is not ETH. It is not even close to ETH. It is an IOU. A receipt. A promise printed on a different chain that says: this token represents 1 real ETH that is locked in a vault on Ethereum. Return this token and we will give your real ETH back.

You now have 1 wETH on Solana. You deposit it in the lending protocol. You earn your interest. Everything seems fine.

Step three. When you want your real ETH back, you return the wETH.

You send your 1 wETH back to the bridge. The bridge destroys it permanently. Then it sends a signal to the Ethereum side saying: someone just returned their wETH, release 1 real ETH to their wallet. The bridge contract on Ethereum unlocks your ETH and sends it back to you.

Complete cycle. Lock on chain A. Mint a copy on chain B. Return the copy. Unlock on chain A.

At a surface level this sounds reasonable. Your asset gets represented on another chain. You use it. You come back and get the real thing. Clean. Simple. Problem solved.

Except it is not clean. And it is not simple. And the problem is very much not solved.

Part 3: The Honeypot Nobody Talks About

Here is the thing that every bridge builder knows but nobody says loudly enough.

When you lock 1 ETH in the bridge contract, that ETH has to sit somewhere. It does not disappear. It does not teleport to Solana. It does not cease to exist. It stays in a smart contract on Ethereum, waiting for someone to come back and claim it.

As more people use the bridge, more assets pile up in that contract.

100 ETH. Then 1,000 ETH. Then 10,000 ETH. Then 100,000 ETH.

The more popular the bridge becomes, the more successful it is, the more valuable assets accumulate inside that one smart contract. Sitting on a public blockchain. Where anyone in the world can see it. Where anyone can read its code. Where anyone can attempt to interact with it. Where the exact dollar value of everything locked inside is visible to everyone at all times.

You have just created the most attractive theft target in the history of finance.

Stop and really think about this from an attacker's perspective.

There is a smart contract sitting on a public blockchain. Its address is completely public. Its code is completely public. Anyone can read it line by line and study it for as long as they want. The exact amount of money sitting inside it is public information updated in real time. And that amount is hundreds of millions of dollars.

An attacker does not need a gun. They do not need to break into a building. They do not need to steal passwords or trick individual users. They just need to find one flaw. One incorrect assumption somewhere in the code. One edge case the developers did not think about. One vulnerability in the logic for deciding who is authorized to withdraw funds.

Find that one flaw and they can drain everything. Not $1,000. Not $1 million. Every single dollar that every single user has ever deposited into that bridge. All of it. In one transaction.

This is not a theoretical risk. This is not a worst case scenario that cautious engineers dream up. This is exactly what has happened. Repeatedly. To the biggest and most well-funded bridge projects in the industry.

Part 4: The $2 Billion Evidence

Ronin Bridge. March 2022. $625 million stolen.

Ronin was the official bridge for Axie Infinity, one of the most popular blockchain games ever created. Millions of players. Billions of dollars in trading volume. A team with serious resources and serious security awareness.

Ronin used nine validators as the security model. Think of them as nine guards who each have to approve any withdrawal. To steal the money an attacker would need five of the nine guards to cooperate or be compromised simultaneously. That sounds robust.

But here is what nobody noticed until it was too late. Four of the nine validators were controlled by the same single organization. And one more validator had given standing signing authority to a third party for operational convenience. An attacker found and compromised that third party. Four validators from the one organization plus the one compromised external authority equals five. Exactly the threshold. Exactly enough.

One transaction. $625 million. Completely gone. The largest crypto hack in history at the time. Not because the cryptography was weak. Not because of a traditional software bug. Because of one incorrect assumption about how the validator structure was actually set up in practice.

Wormhole. February 2022. $320 million stolen.

Wormhole was built specifically for Solana. It was one of the primary ways the Solana ecosystem connected to Ethereum. Heavily used. Well funded. Built by a serious team.

An attacker found a flaw in how Wormhole verified guardian signatures on the Solana side of the bridge. The program had a function that was supposed to verify a legitimate guardian had signed a cross-chain message. But due to an error in account validation logic, the attacker was able to pass a fake account through the verification check. The program accepted it as valid.

Using this forged validation, the attacker convinced Wormhole to mint 120,000 wETH on Solana without depositing any real ETH on the Ethereum side. They created $320 million worth of tokens from absolute nothing. Then redeemed a portion of them for real ETH on the other side. Real money, extracted through a fake signature, from a vault that was supposed to be secure.

Nomad. August 2022. $190 million stolen.

This one is the most devastating to read about because of how it ended.

A routine upgrade to Nomad's code introduced a vulnerability. The nature of the bug meant that Nomad would accept almost any message as valid regardless of whether it was actually signed and authorized correctly. A single attacker found this first and began draining the bridge.

Then word got out. Not just to sophisticated hackers. To everyone. Regular users. Opportunists. People who had never written a line of exploit code in their lives.

People started copying the attacker's original transaction and changing only their own destination wallet address. That was all it took. Copy. Paste. Change the address. Submit. Receive money that was not yours. $190 million drained not by one sophisticated actor but by hundreds of ordinary people who stumbled into the easiest money they had ever seen. A public free-for-all on a supposedly secure financial bridge.

Part 5: The Pattern That Cannot Be Explained Away

Look at these three hacks side by side. They are completely different in their technical details. Different vulnerabilities. Different chains. Different teams. Different months. Different attack methods.

But they share one thing and only one thing.

Every single one happened because there was a massive pot of real money sitting in a smart contract. Visible to everyone. Permanently accessible to anyone with enough skill and patience to find the right flaw. Just waiting.

The Ronin team was competent. The Wormhole team was competent. The Nomad team was competent. These were not amateur operations. These were serious engineers with real security budgets and real audit processes and real awareness of the stakes involved.

It did not matter.

Because competence cannot eliminate the fundamental problem. The moment you lock real assets in a custody contract you have created an attack target. You can make that target harder to hit. You can audit the code. You can add multiple validators. You can introduce time delays and rate limits and emergency pause mechanisms. You can do everything right by every standard that exists.

And you will still lose eventually. Because eventually someone will find the one thing you missed. And when they find it on a bridge holding $500 million, they will not politely report it. They will take everything.

This is not pessimism. This is what the historical record shows without ambiguity. Billions of dollars. Dozens of bridges. Multiple years. Teams with every resource available to them.

The architecture produces the outcome. Every single time.

Part 6: The Question

After reading about these hacks over and over I kept returning to one question that I could not get out of my head.

Why does the asset have to sit somewhere?

The entire bridge model is built on one assumption so fundamental that nobody questions it. The assumption is that to use an asset on another chain, you have to move it. Or at minimum lock it somewhere while a copy lives on the other chain. The real asset must be custodied. Someone or something must hold it while you use the representation of it elsewhere.

But what if that assumption is wrong.

What if instead of moving assets between chains, a program on one chain could directly own and control an account on another chain. Natively. Without moving anything. Without locking anything in a vault. Without creating a target for anyone to attack.

What if the honeypot simply did not need to exist.

Not a smaller honeypot. Not a better protected honeypot. No honeypot at all.

If a Solana program could directly own an Ethereum account, it would not need to move ETH to Solana. It would not need to lock ETH somewhere and mint a copy. It would just control the ETH where it already lives, on Ethereum, using cryptography instead of custody.

No vault. No IOU. No target. No $625 million waiting to be found by the right attacker on the right day.

That question is what I started building three months ago.

Tomorrow I will show you exactly what the answer looks like.

Here are some reads which u can refer to
Statistics & The "Island" Problem
https://www.chainalysis.com/blog/2022-biggest-year-ever-for-crypto-hacking/
https://www.chainalysis.com/blog/cross-chain-bridge-hacks-2022/
Proof of the Hacks
https://medium.com/@alabs.ken/analysis-of-the-ronin-bridge-exploit-d9e1de8d1696
https://rekt.news/nomad-rekt
Real-Time "Honeypot" Data
https://l2beat.com/interop/summary
This live dashboard shows the "Total Value Locked" (TVL) in every major bridge. It proves that the "honeypots" are still growing and still visible to everyone.
https://defillama.com/hacks
A searchable database of every major hack. You can filter for "Bridge" to show the sheer frequency of these failures.
https://docs.near.org/
These are neardocs validates our Part 6 by explaining the move toward "account-based" cross-chain interaction instead of "asset-moving" interaction.

Written by Maha.. See y'all tomorrow.