explaingit

gabchess/kageb

Analysis updated 2026-07-25

1RustAudience · researcherComplexity · 4/5Setup · hard

TLDR

A prototype on Solana that groups four real trading orders together, cancels opposing ones internally, and only sends the net result to market so individual choices stay hidden from the public.

Mindmap

mindmap
  root((repo))
    What it does
      Pools four real orders
      Cancels opposing trades
      Sends net result to market
    How it works
      Encrypted order submission
      Two-sided pre-funding
      Three approvers called keypers
    Limitations
      Devnet only
      No deposit or refund
      Not safe for real funds
    Tech stack
      Rust
      Solana blockchain
      Local validator scripts
    Audience
      Blockchain researchers
      Privacy prototype builders

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

What do people build with it?

USE CASE 1

Study how order batching can hide individual trade direction on a public blockchain.

USE CASE 2

Run the local proof script to test the full order-pooling flow on a local validator.

USE CASE 3

Verify published Devnet evidence using the included verification script.

USE CASE 4

Experiment with threshold-based settlement using three designated approvers.

What is it built with?

RustSolanaSolana Devnet

How does it compare?

gabchess/kagebabc3dz/mixxxabyo-software/ferro-stash
Stars111
LanguageRustRustRust
Setup difficultyhardmoderatemoderate
Complexity4/52/54/5
Audienceresearchergeneralops devops

Figures from each repo's GitHub metadata at analysis time.

How do you get it running?

Difficulty · hard Time to first run · 1h+

Requires a Solana toolchain, local validator, and familiarity with on-chain program deployment and Devnet configuration.

In plain English

KageB is a prototype built on Solana that lets traders submit orders without exposing their individual choices to the public. Four real orders go into a pool, opposing orders cancel each other out internally, and only the net aggregate result reaches the market. The public settlement trace shows the group outcome, not which participant chose to buy or sell. The name comes from a Naruto technique called Kage Bunshin. The idea is that each encrypted order is like a sealed scroll in a crowd. The blockchain sees the crowd move but cannot read the choice inside each scroll. Unlike the anime technique, KageB does not create fake or decoy trades. It only pools real orders and sends the net result onward. Each participant funds both sides of a possible trade before submitting an encrypted order. This two-sided funding prevents the public funding step from revealing whether the trader intends to buy or sell. The system requires at least four valid participants before it will lock the group. Three designated approvers called keypers must reach a two-of-three threshold to authorize the lock and later the settlement. Opposing orders cancel inside the pool, and only the residual aggregate moves to a fixed venue. The prototype runs on Solana's Devnet using synthetic, zero-decimal assets. It is custodial, upgradeable, and explicitly not safe for real funds. It has no deposit, withdrawal, or refund mechanism. Each order is limited to exactly one lot at one operator-set price. The project provides a local proof script that builds the programs, starts a local validator, and checks the full flow, plus a separate script to verify published Devnet evidence. The workspace exposes Rust protocol building blocks and a reference implementation, not a hosted service or complete trading SDK. The proof does not establish unique humans, production anonymity, private funding, protection from the operator, or safe use with real assets. If an observer already knows every other participant's order, the aggregate can reveal the remaining one. Crowd size is a demo condition, not an anonymity guarantee. The full README is longer than what was shown.

Copy-paste prompts

Prompt 1
Using the KageB Rust workspace, show me how to run the local proof script that builds the programs, starts a local validator, and checks the full order-pooling flow.
Prompt 2
Explain how KageB's two-sided funding mechanism prevents the public funding step from revealing whether a trader intends to buy or sell, and walk me through the code that implements it.
Prompt 3
Using KageB's reference implementation, walk me through how three keypers reach a two-of-three threshold to authorize locking a group of four orders and later settling them.
Prompt 4
Show me how to use KageB's Devnet evidence verification script to check published on-chain proof of a completed pooled-trade settlement.

Frequently asked questions

What is kageb?

A prototype on Solana that groups four real trading orders together, cancels opposing ones internally, and only sends the net result to market so individual choices stay hidden from the public.

What language is kageb written in?

Mainly Rust. The stack also includes Rust, Solana, Solana Devnet.

How hard is kageb to set up?

Setup difficulty is rated hard, with roughly 1h+ to a first successful run.

Who is kageb for?

Mainly researcher.

Open on GitHub → Explain another repo

This repo across BitVibe Labs

Verify against the repo before relying on details.