DEV Community: Rohan Kumar

Your AI agent remembers everything. Can it prove any of it?

Rohan Kumar — Sun, 25 Oct 2026 13:30:41 +0000

Building Engram: git for agent memory, on Walrus, Sui and Tatum

By Rohan · Tatum × Walrus Total Recall hackathon · Track 02: Smart Agents for Real Life

Every belief traceable. Every decision provable. Every memory forgettable.

Watch the demo video · Try the live agent, no wallet needed · Read the docs · Read the code

- The short version. AI agents now remember things about us, and they act on what they remember. But nobody can see how an agent learned something, which memory drove a decision, whether the record was edited afterwards, or how to make it truly forget.
- Engram fixes that. It gives an agent's memory a history (like git), a proof that anyone can check (signed snapshots stored on Walrus and anchored on Sui), and an off switch (forgetting you can prove). It's live, it's on npm, and the demo agent learned from real on-chain transactions.

Part 1 · The moment that started it

Picture this. You've given an AI agent access to your wallet. Its job is simple: watch your money and warn you when something looks wrong. For weeks it does fine. It learns your salary, your rent and your subscriptions, and it stops bothering you about them.

Then one morning it stays quiet about a payment to an address you've never seen.

You ask it a simple question: "Why didn't you warn me?"

And it can't really answer.

It has memories, a growing pile of text it has collected over the weeks. But it can't show you:

which of those memories it relied on,
what it believed at the exact moment it decided,
when it started believing that, or what taught it,
or any proof that the record you're looking at is the same one it used. The logs sit on the operator's server, and anyone with access could have changed them afterwards.

That's where agent memory is today. Tools like Walrus Memory have made it easy for agents to remember. Nobody had made it easy to hold that memory to account.

We kept coming back to one thought: software developers had this exact problem decades ago, with code. Code changed constantly, many people touched it, and when something broke, nobody knew which change caused it. The answer was version control. Every change became a commit, history could be compared, and git blame could tell you exactly where any line came from.

We wanted that for an agent's mind, plus one thing git never needed: proof that a stranger can check without trusting us.

So we built Engram. The name comes from neuroscience, where an engram is the physical trace a memory leaves in the brain.

Part 2 · Why we felt we had to build it

Agents crossed a line this year

For a long time, AI assistants mostly talked. If one misremembered something, you got a wrong answer, you noticed, and you moved on.

That's changing quickly. Agents now act. They move money, approve refunds, triage support tickets, screen applicants and manage on-chain treasuries. And to act well, they need memory:
your preferences, your habits, the context from last week.

Once an agent acts for you, its memory stops being a convenience and becomes a responsibility. A wrong memory is no longer a wrong sentence. It's a wrong payment, a wrong refund, a wrong rejection.

Five questions nobody could answer

While building and using agents, we kept hitting the same five questions:

The question	What you get today	What you'd actually want
"How did it learn that?"	A pile of raw text snippets	A clear line from what it saw to what it concluded, and how that changed over time
"Why did it do that?"	A decision with no trail	A record of exactly which knowledge each decision used
"Can I trust this record?"	Logs on the operator's server	Evidence that can't be quietly edited, checkable by anyone
"What went wrong, and when?"	Guesswork	A way to search history for the moment a bad belief appeared
"Can it forget?"	"We deleted it, trust us"	Forgetting you can prove, without breaking the rest of the record

Why existing tools don't solve this

We looked hard at what already exists before building anything.

Vector databases and memory stores are good at remembering. But they're a current snapshot. They don't keep history, so you can't ask "what did you believe last Tuesday?"
Logging and observability tools record what an agent did. They don't record what it believed, and the logs belong to the operator, the very party you might need to audit.
Blockchains give you a public, tamper-proof clock. But you can't put private memories on a public chain.

Each tool solves one piece. None of them connects what an agent saw → what it concluded → what it did in a way that is private, versioned and provable at the same time.

The idea, in one sentence

Treat an agent's mind like a git repository, and make every commit provable on a public chain.

We didn't want to replace Walrus Memory. It already stores agent memory privately and in a decentralised way. We wanted to build the layer that was missing on top of it:

Walrus Memory gives agents memory. Engram gives that memory history, proof and control.

Part 3 · Who it's for

Engram is for anyone who might one day have to answer "why did the agent do that?" with evidence instead of a shrug.

Who	The question they're stuck on	What Engram gives them
Agent developers	"My agent got worse after last week. What did it learn?"	`log`, `diff`, `checkout`, `blame` and `bisect` on the agent's mind
On-chain and fintech agents (wallet watchers, treasury bots, payment agents)	"Why did the agent move, or block, this money?"	A signed receipt for every decision, which anyone can `verify`
Regulated teams (finance, health, insurance, HR)	"Can we show which knowledge an automated decision relied on?"	Tamper-evident history and audit bundles that outsiders can check
Privacy-first apps	"The user asked us to delete their data. Can we prove we did?"	`forget`, which destroys the data's key and records it in history
Everyday assistant users (through MCP)	"What do you know about me? Forget that."	Engram tools inside Claude Code, Cursor and Claude Desktop

Four stories that show why it matters

The wallet agent (our demo). An agent watches a Sui wallet through Tatum. It learns the owner's salary, rent and subscriptions, and stops alerting on normal payments. When money goes to an address the owner flagged as a scammer, it raises a CRITICAL alert. That one decision can be verified end to end, down to a public timestamp on Sui.

The support bot that went rogue. After an update, a support bot starts approving refunds it shouldn't. Instead of reading thousands of logs, the developer runs bisect, and it finds the exact commit where the bot learned "refunds are allowed up to 60 days" from one misread ticket. blame shows that ticket. forget removes it, and the next commit fixes the belief.

The trading dispute. A user says a trading bot made a trade "for no reason." The operator doesn't argue. They send the receipt for that trade, and the user runs verify on their own machine. It shows exactly which beliefs the bot used and proves they existed before the trade.

The right to be forgotten. A patient asks a health assistant to delete a conversation. After forget, the data can never be decrypted again, and the agent's own history shows the memory was removed and when.

Who doesn't need it

If you're building a simple chatbot with no need for history, audits or debugging, plain Walrus Memory is enough. And if your data must be edited in place, Engram isn't a fit, because it's append-only by design. That's what makes it trustworthy.

Part 4 · The ideas, in plain language

Engram borrows from two places: how people remember and how git tracks code. Here are the five building blocks.

Episode: what the agent saw

An episode is a raw experience. It could be a wallet transaction ("sent 0.05 SUI to 0x2498…"), something the owner said ("that's my rent"), or a tool result. Each episode is encrypted with its own key before it's stored. That detail matters later, when we get to forgetting.

Belief: what the agent concluded

A belief is a short statement the agent holds to be true, such as "The owner pays 0.05 SUI rent to 0x2498… once a month." Each belief has:

a confidence score from 0 to 1,
evidence: the exact episodes that support it,
a version number, because beliefs change when the facts do,
a status: active, revised or retracted.

Sleep: how episodes become beliefs

People don't remember every moment of their day. While we sleep, the brain turns experiences into knowledge. Engram does something similar. The sleep step hands new episodes and current beliefs to an LLM, which proposes new, revised or retracted beliefs.

There's one strict rule: every proposal must cite real episode IDs. If the model invents a reason or points at evidence that doesn't exist, the proposal is rejected. The agent can't make up why it believes something.

Commit: a snapshot of the mind

A commit freezes every active belief into one snapshot. All the beliefs are combined into a single fingerprint called a Merkle root: change any belief, even by one character, and the fingerprint no longer matches. The snapshot is signed with the agent's own key, stored on Walrus, and its fingerprint is published on Sui. Each commit names its parent, so history forms a chain that can't be rewritten without breaking every link after it.

Receipt: proof of why

Every time the agent makes a decision, Engram writes a receipt: "I did X, using exactly these beliefs, from this snapshot." The receipt is signed and includes a small mathematical proof (a Merkle proof) for each belief, showing it was part of the snapshot without revealing any of the other beliefs.

How they connect

classDiagram
    direction LR
    class Episode {
        id: ep_…
        source: user | tool | tatum | agent
        keyId: own AES-256-GCM key
        contentHash: sha256
        blobId: Walrus blob
    }
    class Belief {
        id: b_…
        version: n
        statement
        confidence: 0..1
        evidence: episode IDs
        status: active | revised | retracted
    }
    class Commit {
        id: sha256 of manifest
        parent: commit ID
        merkleRoot
        beliefs: id@version
        tombstones: episode IDs
        signature: Ed25519
        manifestBlobId
        anchor: Sui tx + checkpoint
    }
    class Receipt {
        id: r_…
        action
        inputHash
        beliefs used
        proofs: Merkle
        commitId
        signature: Ed25519
    }
    Episode "many" --> "1..many" Belief : evidence for
    Belief "many" --> "1" Commit : snapshotted in
    Commit --> Commit : parent
    Receipt --> Commit : proven against
    Receipt --> Belief : used

Episodes are evidence for beliefs. Beliefs are snapshotted in commits. Commits link to their parents. Receipts point at the commit and the beliefs they used. Follow the arrows and you can walk from any decision back to the raw experiences behind it.

Part 5 · The life of one memory

The easiest way to understand Engram is to follow a single memory from start to finish. Let's follow the rent payment from our demo.

flowchart LR
    IN["Wallet tx<br/>user message<br/>tool result"] --> OBS["1 · observe"]
    OBS --> EP["Episode<br/>encrypted with its own key"]
    EP --> SLEEP["2 · sleep<br/>LLM consolidation"]
    SLEEP --> BEL["Beliefs<br/>versioned · confidence · evidence"]
    BEL --> COMMIT["3 · commit<br/>Merkle root + Ed25519 signature"]
    COMMIT --> PROOF["Manifest on Walrus<br/>root anchored on Sui"]
    BEL --> DECIDE["4 · decide / wrap<br/>relevant beliefs in"]
    DECIDE --> REC["Signed receipt<br/>Merkle proofs into HEAD"]
    REC --> VERIFY["5 · verify<br/>anyone, anytime"]
    PROOF --> VERIFY
    PROOF --> SYNC["6 · link / sync<br/>web dashboard"]

    classDef step fill:#d4ff3a,stroke:#0a0a09,color:#0a0a09
    classDef data fill:#1b1b19,stroke:#d4ff3a,color:#f3efe6
    class OBS,SLEEP,COMMIT,DECIDE,VERIFY,SYNC step
    class EP,BEL,PROOF,REC data

Step 1 · observe: the agent sees something

0.045 SUI leaves the owner's wallet. The agent reads it from the chain through Tatum, and observe turns it into an episode. Engram generates a fresh AES-256-GCM key for this one episode, encrypts it, and stores the ciphertext on Walrus. The owner also says "that's my rent", which becomes a second episode.

Step 2 · sleep: it draws a conclusion

sleep reads the new episodes and proposes a belief: "The owner pays 0.045 SUI rent to 0x2498… monthly", citing both episodes as evidence. Engram checks that both episode IDs are real before accepting it.

Step 3 · commit: it locks in what it knows

commit builds the Merkle root over every active belief, signs the snapshot with the agent's Ed25519 key, stores it on Walrus, and publishes the root on Sui through our Move contract. From this moment, there's a public, timestamped record of what this agent believed.

Step 4 · decide: it acts, and leaves a receipt

Next month, the same rent payment arrives. Before deciding, Engram hands the agent only the relevant beliefs (found through Walrus Memory's semantic recall). The agent stays quiet, because this is normal, and Engram writes a signed receipt: "No alert, because of belief monthly_rent@1, from commit d0f7d31f."

Step 5 · revise: the facts change

In month four, the rent goes up to 0.05 SUI. The agent raises a WARN, because this doesn't match what it knows, and the owner confirms the rise. At the next sleep, the belief isn't duplicated. It's revised: version 2 replaces version 1, and both stay in history.

Step 6 · verify: anyone can check

Months later, anyone holding a receipt can run verify. Engram checks the signature, the proofs, the snapshot, the history, the copy on Walrus and the anchor on Sui. If everything matches, the answer is VALID: this decision was made on this exact memory, at this time, and nothing has changed since.

And if it ever needs to forget

If the owner asks to forget that first rent message, forget destroys its key, retracts any belief that relied only on it, and records a tombstone in the next commit. More on that in Part 8.

Part 6 · The architecture

Engram follows one rule: the owner keeps the keys, Walrus keeps the data, Sui keeps the proof. Even our own website only shows what it can re-check for itself.

flowchart TB
    subgraph L1["Access layer"]
        direction LR
        AGENT["Your AI agent<br/>(SDK: engram · wrap)"]
        CLI["CLI<br/>npx @rohankumar4179/engram"]
        MCP["MCP server<br/>Claude Code · Cursor"]
        BROWSER["Browser + Sui wallet<br/>dashboard · docs · demo"]
    end

    subgraph L2["Engram layer"]
        direction LR
        CORE["<b>Engram core</b><br/>observe · sleep · commit · decide<br/>verify · forget · link<br/><i>keys + key vault stay local</i>"]
        API["<b>Engram API</b><br/>wallet auth · hosted agents<br/>linked dashboards · live verify"]
    end

    subgraph L3["Services"]
        direction LR
        LLM["Gemini<br/>episodes → beliefs"]
        TATUM["Tatum<br/>Sui gRPC gateway"]
    end

    subgraph L4["Decentralised storage and proof"]
        direction LR
        WALRUS[("<b>Walrus Mainnet</b><br/>Walrus Memory + Seal<br/>episodes · beliefs · manifests · receipts")]
        SUI[("<b>Sui</b><br/>Walrus Blob objects<br/>engram_anchor events")]
    end

    AGENT --> CORE
    CLI --> CORE
    MCP --> CORE
    BROWSER --> API
    CORE -- "sync audit bundle" --> API
    CORE -- "sleep" --> LLM
    CORE -- "store encrypted" --> WALRUS
    CORE -- "anchor root" --> SUI
    CORE -- "read chain" --> TATUM
    API -- "re-verify" --> TATUM
    TATUM --> SUI
    WALRUS -. "blob registered on" .-> SUI

    classDef engram fill:#d4ff3a,stroke:#0a0a09,color:#0a0a09
    classDef access fill:#ffffff,stroke:#555,color:#0a0a09
    classDef svc fill:#fff4e6,stroke:#ff7a45,color:#0a0a09
    classDef dec fill:#eef4ff,stroke:#3b5bdb,color:#0a0a09
    class CORE,API engram
    class AGENT,CLI,MCP,BROWSER access
    class LLM,TATUM svc
    class WALRUS,SUI dec

Reading the diagram from top to bottom:

Layer 1 · How you reach Engram

You can use Engram four ways, depending on who you are:

The SDK wraps an agent you've already built. Your agent's logic doesn't change. Engram sits around it, handing it beliefs and collecting receipts.
The CLI gives you every command, from init to verify, in your terminal.
The MCP server puts Engram's tools inside Claude Code, Cursor and Claude Desktop, so an AI assistant can commit, blame and verify its own memory.
The web app lets anyone sign in with a Sui wallet, run a hosted agent, or watch a linked agent on a dashboard.

Layer 2 · The Engram engine

Engram core does the real work: observe, sleep, commit, decide, verify and forget. It runs on your machine, next to your agent. The agent's signing key and the vault of per-memory keys never leave it.

The Engram API powers the website: wallet sign-in, hosted agents and linked dashboards. It never holds your keys, and it re-verifies everything you send it before showing it.

Layer 3 · Helper services

Gemini does the "thinking" during sleep, turning episodes into beliefs, with every answer checked against real evidence. Tatum is Engram's window onto the Sui blockchain: every Mainnet chain read goes through Tatum's Sui gRPC gateway.

Layer 4 · Where trust comes from

Walrus stores everything durable: episodes, beliefs, snapshots and receipts, encrypted for the owner. Sui holds the public proof: each stored item is registered as an object on Sui, and our Move contract publishes each snapshot's fingerprint for anyone to read.

What leaves your machine, and what doesn't

Stays with the owner	Goes to Walrus	Goes to Sui	Goes to the dashboard
Agent key, key vault, decrypted memories	Encrypted episodes, beliefs, manifests, receipts	Blob registrations and anchor events (Merkle roots)	Commits, beliefs and receipts, re-verified by the server

What happens during a commit

Here's every step engram commit takes, in order:

sequenceDiagram
    autonumber
    participant D as Developer / agent
    participant E as Engram SDK
    participant W as Walrus Memory
    participant S as Sui (engram_anchor)
    participant T as Tatum gRPC

    D->>E: commit("week 2")
    E->>W: push pending episodes, beliefs, receipts
    W-->>E: Walrus blob IDs
    E->>E: Merkle tree over beliefs + tombstones
    E->>E: manifest {parent, root, beliefs, blob IDs}, signed with Ed25519
    E->>W: store manifest
    W-->>E: manifest blob ID
    E->>S: anchor(agent key, commit ID, root, parent, manifest blob)
    S-->>E: Anchored event in checkpoint N
    E->>T: read back Blob object and anchor
    T-->>E: confirmed on chain
    E-->>D: commit 19040b51, root 392bf9cb…, anchored

Engram doesn't just send the proof to the chain. It reads it back through Tatum to confirm it landed before reporting success.

Part 7 · How the proof works

This is the heart of Engram, so it's worth explaining slowly. We use only standard, well-studied building blocks (SHA-256, Ed25519 signatures, AES-256-GCM encryption and Merkle trees). There's no custom cryptography.

A fingerprint for the whole mind

Each belief is hashed into a short fingerprint. Those fingerprints are paired up and hashed again, and again, until one fingerprint is left at the top: the Merkle root. That single value represents the agent's entire mind at that moment. Change any belief, anywhere, and the root changes.

Two public anchors for every commit

Walrus registers every stored item as a Blob object on Sui. So the snapshot itself gets an on-chain record of when it was stored.
Our Move contract, engram_anchor, publishes the Merkle root in the clear. It emits one Anchored event with the commit ID, the root and the agent's public key. It creates no objects, so it only costs gas. Anyone can read it, and nobody can change it afterwards.

That second anchor is what lets a stranger check a commit without trusting us and without decrypting anything.

What `verify` checks

engram verify, and the Verify button on the website, run the same chain of checks. If any one fails, the answer is INVALID. There's no "mostly valid."

flowchart TB
    R(["Receipt r_…<br/>or commit"]) --> A

    subgraph S1["1 · The decision"]
        direction LR
        A["Receipt signature<br/>Ed25519 by the agent"] --> B["Belief Merkle proofs<br/>beliefs are in the commit"] --> T["Timing<br/>decided after the commit"]
    end

    subgraph S2["2 · The snapshot"]
        direction LR
        C["Commit ID = sha256 of manifest<br/>+ Ed25519 signature"] --> D["Merkle root rebuilt<br/>from the beliefs"] --> E["History<br/>every parent signed + linked"]
    end

    subgraph S3["3 · Storage and chain"]
        direction LR
        F["Walrus<br/>manifest is stored"] --> G["Sui anchor via Tatum<br/>same root, public timestamp"]
    end

    T --> C
    E --> F
    G --> OK(["VALID<br/>this decision used exactly this memory"])

    classDef ok fill:#b6f25c,stroke:#0a0a09,color:#0a0a09,font-weight:bold
    classDef chk fill:#ffffff,stroke:#555,color:#0a0a09
    class OK ok
    class A,B,T,C,D,E,F,G chk

Check	What it proves
Receipt signature	The agent really made this decision
Belief proofs	The beliefs it cited were really in that snapshot
Timing	The decision came after the snapshot, so it couldn't have been backfilled
Commit ID and signature	The snapshot belongs to this agent and hasn't been altered
Merkle root	The beliefs rebuild exactly the same fingerprint
History	Every earlier snapshot is signed and correctly linked
Walrus	The snapshot is really stored on Walrus
Sui anchor	The fingerprint was public on chain at that time

Teams can also export an audit bundle (engram export --audit), and anyone can check it with engram audit <file>, with no access to the agent at all.

Part 8 · Forgetting, without rewriting history

This was the hardest design question in the whole project.

We chose Walrus because it's permanent and decentralised: nobody can quietly delete or edit what's stored there. But people have a right to be forgotten. How can permanent storage
forget?

Our answer: don't delete the data. Destroy the only key that can read it.

Remember that every episode is encrypted with its own key before it's stored. Those keys live in a vault on the owner's machine. To forget one memory, Engram destroys that one key. The ciphertext stays on Walrus, but it's now meaningless noise, forever.

flowchart LR
    F["engram forget ep_…"] --> K["Destroy that episode's<br/>AES key in the vault"]
    K --> X["Ciphertext on Walrus<br/>can never be decrypted"]
    K --> RT["Retract beliefs that<br/>relied only on it"]
    RT --> TB["Next commit records<br/>a tombstone"]
    TB --> V["Old receipts still verify:<br/>history grows, never rewritten"]

Two more things happen at the same time:

Any belief that relied only on that memory is retracted, so the agent stops acting on it.
The next commit records a tombstone: a note that this episode was forgotten, and when.

The history isn't rewritten. It grows. Old receipts still verify, because forgetting becomes part of the record instead of a hole in it. You get a provable "we forgot this, on this date" instead of "trust us, it's gone."

Part 9 · Why Walrus, Sui and Tatum

Memory you want to trust shouldn't depend on trusting whoever runs the server. Engram needed four things from its storage, and this stack provides all four.

Engram needs…	The stack provides…	How Engram uses it
Memory no single party can quietly change or delete	Walrus: decentralised storage across independent nodes	Episodes, beliefs, snapshots and receipts all live on Walrus
A stable ID to point at in proofs	Every Walrus blob has an ID, registered as a `Blob` object on Sui	Commits list each episode's blob ID, `blame` shows them, `verify` checks them
Privacy: only the owner reads raw memories	Walrus Memory encrypts data for its owner with Seal	Engram adds its own per-memory key on top, which makes provable forgetting possible
A public clock, so history can't be backdated	Sui transactions and checkpoints	`engram_anchor` puts each commit's Merkle root in a public event

Walrus Memory: where everything lives

Each kind of data gets its own Walrus Memory namespace (engram-<agent>-episodes, -beliefs and so on). Walrus Memory's semantic recall finds the beliefs that matter for each decision, so the agent gets "what do I know about rent?" instead of its whole memory. A user's agent can also run on their own Walrus Memory account. The web app sets that up with two wallet-signed transactions.

Sui: the public clock

Sui gives every commit a public timestamp nobody can move. Because each commit names its parent, and each parent is anchored, the whole history is pinned in time.

Tatum: how Engram reads the chain

Every Mainnet chain read goes through Tatum's Sui gRPC gateway: Walrus Blob objects, anchor transactions and the demo agent's live wallet feed. One affectedAddress query returns every transaction that touched a wallet, sent or received, which is exactly what a wallet watcher needs.

What only works because of this stack

verify checks a decision against data no single party could have edited.
Linked dashboards stay honest. Our server can't read your private memories, but it can still confirm each snapshot is stored on Walrus (through the public aggregator) and that its fingerprint is on Sui.
Forgetting with proof, on storage that's permanent by design.

Private memory, stored openly, that anyone can verify.

Part 10 · The demo: an agent that learned from real money

We didn't want a scripted demo with fake data piped into the agent. So our example agent, money-ops, watches a real Sui wallet through Tatum.

We created five wallets (an owner, an employer, a landlord, a streaming service and a scammer) and sent real SUI between them: salary in, rent and a subscription out, a rent rise, and a staged theft. The agent never sees the script. It reads the owner's wallet from the chain like any other wallet, and the owner occasionally explains things in plain words, the way a person would.

Phase	On chain	What the agent does
Month 1	Salary in, rent and a subscription out. The owner explains them.	Alerts on all 3 (it knows nothing yet), then learns 3 beliefs
Months 2–3	The same six transfers again	Quiet on all 6, each receipt citing the belief it used
Month 4	Rent rises. 0.18 SUI leaves to an unknown address. The owner: "that's a scammer."	Warns about the rent change, flags the unknown payment, then revises the rent belief and learns the scam address
Month 5	New rent, and another payment to the scammer	Quiet on the new rent. CRITICAL alert on the scammer, from memory.

That's the whole point in one table: the agent learns, changes its mind when the facts change, and remembers a threat. And every step is provable.

Watching the agent think: the Mind view

The Mind view draws the agent's beliefs as a map. Each card in the middle is a belief, with its confidence bar and how many pieces of evidence support it. The small tags around each card are the episodes behind it: wallet events and things the owner said. The slider at the top
replays history commit by commit, so you can drag back to Month 1 and watch the agent learn.

Notice the version numbers: monthly_rent v5, salary_payment v3. These beliefs weren't written once. They were refined each time new evidence arrived.

Every memory, encrypted and on Walrus: the Memory view

The Memory view lists every raw episode: wallet events and owner messages. Each one shows its Walrus blob ID, with a link to see it on the Walrus explorer. The explorer can prove the blob exists, but not what it says, because only the owner holds the key. The learned tag shows that an episode has already been consolidated into beliefs.

A history you can't rewrite: the History view

The History view is the agent's git log. Each card is one commit, showing which beliefs were added (+) or revised (pencil), along with the Merkle root. On the right are the links to the snapshot on Walrus and the anchor transaction on Sui, with its checkpoint number. Look at Month 4: two new beliefs about the scam address, and revisions to rent, salary and subscription, all in one signed, anchored snapshot.

Every decision comes with a receipt: the Receipts view

This is where everything pays off. The agent made ten decisions and raised three alerts. Each row shows the decision, the agent's reason, the exact belief versions it used, and the commit those beliefs came from.

Read it from the bottom up and you can see the agent learn. Early decisions cite monthly_rent@1. Then a WARN when the rent changed, citing monthly_rent@2. Then a CRITICAL on the first payment to an unknown address, citing none, because the agent hadn't learned about it yet. And at the top, the second payment to the scammer: CRITICAL, citing scam_address_0xcbed@1, proven against commit 19040b51.

Then anyone can check it

This is the live output for that scam alert. Click Verify on the site, or ask the API yourself:

✔ receipt signature    "ALERT[critical]: sent 0.025 SUI to 0xcbed89… — Outgoing transfer detected
                        to a known scam address representing theft." signed by the agent
✔ belief proofs        2 belief(s) proven to be in commit 19040b51
✔ timing               decision made after its commit
✔ commit id            sha256 of the manifest matches the commit ID
✔ commit signature     Ed25519 by agent 0e648084a79c…
✔ commit merkle root   5 beliefs + 0 tombstones → root 392bf9cbb518…
✔ commit history       2 earlier commit(s), all signed and hash-linked
✔ commit walrus        manifest recalled from Walrus Memory, blob YI30MCNaOG…
✔ commit sui anchor    Anchored event: root 392bf9cbb5… public in checkpoint 397926925 (testnet)
✔ commit anchored at   2026-10-22T14:35:05.365Z
VALID

Check it without trusting us

You don't need our software, or our word, for any of this:

# 1. A memory is stored on Walrus Mainnet (HTTP 200; the content is encrypted)
curl -I https://aggregator.walrus-mainnet.walrus.space/v1/blobs/FC-92hYt6rX2P8oJy-pvKRMbOAW0g3V2DranpmQx-Ss

# 2. The Merkle root of commit 19040b51 is public on Sui
curl -s https://graphql.testnet.sui.io/graphql -H 'content-type: application/json' \
  -d '{"query":"{ transaction(digest: \"BPFs7EqazA9nxUtr5rGnjcAJb4eUqxsNTUcA2L5aT4yx\") { effects { events { nodes { contents { json } } } } } }"}'

# 3. The full proof check, through the live API
curl -s https://engram-blond.vercel.app/api/demo/verify/r_5080ccb4fd9c3869

16 memories on Walrus Mainnet. 4 commits anchored on Sui. Every link checked before we published. The full list of blob IDs and transactions is in the README.

A note on honesty: the "theft" is staged, because the owner's own key signs it. But it's an ordinary on-chain transfer, and the agent has no way to tell it apart from a real one. The whole story moved about 0.75 SUI.

Part 11 · Debugging an agent's mind

Proof is one half of Engram. The other half is everyday developer tooling, the commands you reach for when an agent starts behaving strangely.

Command	The question it answers
`log`	What has this agent learned, commit by commit?
`diff`	What changed in its beliefs between two points?
`checkout HEAD~1` or `checkout 2026-10-20`	What did it believe then?
`blame <belief>`	Which exact episodes (with Walrus blob IDs) taught it this?
`bisect <good> <bad>`	In which commit did it first start believing something wrong?

bisect is the one we're proudest of. Like git bisect, it does a binary search through the agent's history. You tell it one commit where the agent behaved well and one where it didn't, and it narrows down to the exact snapshot where a bad belief first appeared. Combined with blame and forget, you can go from "the agent is acting weird" to "here's the memory that caused it, and it's gone" in a few commands.

Part 12 · Using it today

In code: the SDK

Wrapping an existing agent takes a few lines. Your agent's logic stays the same:

import { engram } from "@rohankumar4179/engram-sdk";

const mind = engram({ agent: "money-ops" });   // Walrus Memory, Tatum, Gemini from .env

// Wrap your existing agent: relevant beliefs in, a signed receipt out.
const agent = mind.wrap(async (tx, beliefs) => myAgent.decide(tx, beliefs), {
  used: (decision) => decision.beliefIds,
});
const decision = await agent(tx);

mind.observe({ source: "tatum", data: tx });   // encrypted episode
await mind.sleep();                            // episodes → beliefs
await mind.commit("week 2");                   // signed, stored on Walrus, anchored on Sui
await mind.beliefs({ about: "rent" });         // Walrus Memory semantic recall
mind.at("2026-10-01");                         // time travel
mind.forget("ep_…");                           // provable forgetting
await mind.verify(agent.lastReceipt!.id);      // signature → proofs → Walrus → Sui

In the terminal: the CLI

npx @rohankumar4179/engram init my-agent
npx @rohankumar4179/engram observe "I pay 450 USDC rent to 0x7a11 on the 1st"
npx @rohankumar4179/engram sleep                   # episodes → beliefs
npx @rohankumar4179/engram commit -m "first week"  # signed → Walrus → Sui
npx @rohankumar4179/engram verify                  # ✔ … VALID

Needs Node 20+ and a .env with your keys (configuration).
On Windows PowerShell, use npx.cmd.

Inside your AI assistant: MCP

Add one entry to Claude Code, Cursor or Claude Desktop, and your assistant gets Engram's tools:

{ "mcpServers": { "engram": { "command": "npx", "args": ["@rohankumar4179/engram", "mcp", "-C", "/path/to/agent"] } } }

On the web: link your agent to a dashboard

Linking works like gh auth login. The CLI shows a one-time code, and you approve it on the website with your Sui wallet. Signing in is one free text signature, never a transaction.

sequenceDiagram
    autonumber
    participant CLI as engram CLI
    participant API as Engram API
    participant B as Owner's browser
    participant WL as Sui wallet

    CLI->>API: POST /api/link/start (agent name, public key)
    API-->>CLI: code K7QF-29XM + approval URL
    CLI->>B: owner opens /link?code=K7QF-29XM
    B->>WL: sign the free sign-in message
    WL-->>B: signature
    B->>API: POST /api/link/decide (approve, signed-in wallet)
    CLI->>API: GET /api/link/poll
    API-->>CLI: link token (bound to wallet + agent key)
    CLI->>API: POST /api/link/sync (commits, beliefs, receipts)
    API->>API: re-verify signatures, roots, Walrus, Sui
    API-->>CLI: synced, verified
    Note over CLI,WL: Later commits sync automatically.<br/>Raw episodes and keys never leave the machine.

After that, every commit syncs automatically. Only commits, beliefs and receipts are uploaded, never raw episodes or keys. A link token only accepts bundles signed by that agent's key, and history can only grow, never be replaced.

Part 13 · What broke, and how we fixed it

Building on live infrastructure during a hackathon means the ground moves under you. Here's what broke, and what we learned from it.

Sui JSON-RPC went away

Sui switched JSON-RPC off, and Tatum's JSON-RPC gateway started answering "No healthy upstream" to every call. We rewrote our Tatum client on gRPC. Tatum serves native gRPC rather than gRPC-Web, so we use a native transport. The upside: one affectedAddress query now gives us everything a wallet watcher needs.

Walrus Memory's embedder went down

On 22 October, Walrus Memory's server-side embedding failed
(MemWal#1285). Rather than wait, we added a fallback to Walrus Memory's manual mode: Engram embeds locally, Seal-encrypts with the owner's key, and the relayer only ever stores ciphertext. Reads merge both paths, so verify never noticed the switch.

The relayer rate-limits each key

Walrus Memory's relayer allows 60 requests a minute per key. Engram now waits out 429 responses using the relayer's own retry_after_seconds, instead of failing.

LLM free tiers are small

Decisions are batched, quota errors rotate between keys and models, and a failed wallet sync no longer stops the agent from learning what the owner told it.

Part 14 · Honest limits

We'd rather you hear these from us:

Forgetting can't un-read a copy. If someone already decrypted a memory before it was forgotten, destroying the key can't undo that. And the summaries of retracted beliefs stay in history, clearly marked as retracted.
Snapshots are encrypted for the owner. Outsiders confirm a snapshot exists on Walrus and check its content through the public Merkle root on Sui, rather than reading it directly.
Keys live on disk in .engram/ today. Moving them to Seal or a key management service is on the roadmap.
The Move anchor runs on Sui Testnet today. The memories on Walrus and the Tatum chain reads are on Mainnet.

Part 15 · What we shipped, and what's next

Built during the hackathon

Piece	Status
CLI: `init` · `observe` · `sleep` · `commit` · `log` · `diff` · `checkout` · `blame` · `bisect` · `verify` · `forget` · `export`/`audit` · `link`/`sync` · `mcp`	Published on npm: `npx @rohankumar4179/engram`
TypeScript SDK: wrap any agent, get signed receipts	Published on npm: `@rohankumar4179/engram-sdk`
MCP server: 10 tools for Claude Code, Cursor and Claude Desktop	Done
Move contract `engram_anchor`	Live on Sui Testnet
Tatum Sui gRPC for every Mainnet chain read	Done
money-ops example agent on real wallet transactions	Done
Web app: wallet sign-in, hosted agents, linked CLI agents, live verify, public demo, docs	Live at engram-blond.vercel.app
Tests	SDK 62 · CLI 10 · money-ops 6 · server 20, all passing

Next few months

The Move anchor on Sui Mainnet, so roots are public on Mainnet as well as Testnet
Plug-ins for the Vercel AI SDK, LangChain, the Claude Agent SDK and Mastra
A Python SDK with the same API
Scoped sharing: hand part of a memory (say, only the finance beliefs) to another agent, with an expiry date

Further out

Team dashboards: many agents, many team members, and alerts when a belief changes
Paid memory sharing: agents sell scoped knowledge to each other on Sui, with proof of exactly what was sold
Keys in Seal or a KMS instead of on disk
A public verification page: paste a receipt, get a verdict, nothing to install

What success looks like

Developers reach for Engram when they need to debug an agent. Teams use it to audit one. And users trust an agent because they can check what it remembered, instead of being asked to take it on faith.

Try it


Demo video	https://youtu.be/zpMpASWEX5k
Live demo agent (no wallet needed)	https://engram-blond.vercel.app/demo
Web app	https://engram-blond.vercel.app
Docs	https://engram-blond.vercel.app/docs
Code	https://github.com/rohan911438/Engram
CLI	`@rohankumar4179/engram`
SDK	`@rohankumar4179/engram-sdk`
Anchor package (Sui Testnet)	`0xa1fccbb3…bf86b`

Agents are getting memories. We think those memories should come with a history you can read, a proof you can check, and an off switch you can trust.

Walrus Memory gives agents memory. Engram gives that memory history, proof and control.

Building an Agentic Fraud Investigation Agent with TigerGraph

Rohan Kumar — Thu, 24 Sep 2026 09:35:18 +0000

How I built an evidence-driven fraud investigation system combining TigerGraph, agentic workflows, GraphRAG, case memory, uncertainty analysis, and policy-aware decisions.

Rohan Kumar
Team: BROTHERHOOD — Solo Builder
Hacker House Goa '26 — TigerGraph Challenge

Fraud rarely looks suspicious because of one transaction.

The difficult cases are usually hidden in the connections.

A transaction may be associated with a device that appears across dozens of cards. Multiple transactions may share infrastructure. A customer may have a previous investigation with similar characteristics. A transaction may look normal by itself but become suspicious when viewed as part of a larger network.

That was the problem I decided to tackle for Hacker House Goa '26.

I built an Agentic Fraud Investigation Agent powered by TigerGraph that investigates a transaction, gathers connected evidence, assesses uncertainty, retrieves historical investigation context, recommends a next-best action, and creates a persistent case.

The core design principle was:

The graph finds the evidence. The policy decides what to do with it. The agent connects the two.

GitHub: https://github.com/rohan911438/HHGOA_26
Demo: https://youtu.be/0dqjXyY2Hoc
Live Dashboard: https://hhgoa-fraud-frontend.vercel.app

The Problem

A conventional fraud model can tell you:

"This transaction looks suspicious."

But an investigator needs much more than that.

They need to know:

What entities are connected to the transaction?
Has this card been used elsewhere?
Is the same device associated with other customers?
Are there related transactions?
Have similar cases appeared before?
How complete is the evidence?
Is there conflicting evidence?
Is there enough evidence to take action?
What action should happen next?
Does that action require approval?
What exactly supports the recommendation?

Fraud investigation is therefore not just a classification problem.

It is an investigation workflow.

The challenge asked us to build an agent capable of moving through that workflow: investigate, gather evidence, reason about uncertainty, recommend actions, create or progress cases, use historical context, and explain the resulting decision.

That led to the architecture I built.

The Core Idea

I did not want an LLM sitting in front of a database and simply guessing whether something was fraud.

Instead, I separated the responsibilities:

                    FRAUD SIGNAL
                         │
                         ▼
                ┌─────────────────┐
                │ Agent Orchestrator│
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Investigation    │
                │ Service          │
                └────────┬────────┘
                         │
                         ▼
                 ┌──────────────┐
                 │ TigerGraph   │
                 │ Fraud Graph  │
                 └──────┬───────┘
                        │
                        ▼
                STRUCTURED EVIDENCE
                        │
            ┌───────────┴───────────┐
            ▼                       ▼
      UNCERTAINTY              CASE MEMORY
            │                       │
            └───────────┬───────────┘
                        ▼
                 POLICY ENGINE
                        │
                        ▼
                 NEXT-BEST ACTION
                        │
                        ▼
                  INVESTIGATION CASE

The result is an agentic system where every major decision is grounded in structured evidence.

Why TigerGraph?

Fraud is inherently relational.

Consider this question:

"Which other customers have used the same device as this transaction?"

In a relational system, this quickly turns into multiple joins across transaction, customer, device and identity data.

In a graph, the question becomes a traversal.

For the official HHGOA dataset, I modeled relationships between entities such as:

Customer
   │
   ▼
Card
   │
   ▼
Transaction
   │
   ├────────► Device Profile
   │
   ├────────► Email Domain
   │
   └────────► Billing Region

This lets the investigation move through the network rather than examining every transaction as an isolated row.

That distinction became especially important for one benchmark case.

The Case That Made the Graph Useful

One of the clearest examples was HHG-014.

The transaction itself was only part of the story.

The investigation traced the transaction to a device profile and then traversed back through other transactions and cards using that device.

The graph showed the same device associated with 27 other customers' cards.

More importantly, the device matched characteristics of the fraud ring described in the bank's investigation material.

This is the kind of pattern that is easy to miss when looking at one transaction in isolation.

The graph did not merely tell me:

"This transaction is suspicious."

It exposed the network behind the transaction.

That network became evidence for the investigation.

Architecture

The project ended up with two closely related layers.

1. The Investigation Platform

This is the main application:

Next.js Dashboard
        │
        ▼
FastAPI
        │
        ▼
LangGraph Orchestrator
        │
        ▼
Investigation Service
        │
        ▼
Controlled Tool Registry
        │
        ▼
TigerGraph
        │
        ├── Evidence
        ├── Uncertainty
        ├── Case Memory
        └── Policy

The public dashboard provides the analyst interface.

The backend handles orchestration and investigation logic.

TigerGraph performs the relationship-heavy investigation.

2. The Official Benchmark Pipeline

Once I obtained the official HHGOA_IEEE package, I created a dedicated benchmark path that works against the official data and the exact policy vocabulary supplied with it.

This was important because the initial development environment and the official benchmark data were not identical.

The benchmark pipeline was deliberately kept separate from the earlier development fallback so that results could not accidentally depend on the fallback fraud labels.

The Investigation Workflow

The agent follows a bounded investigation loop:

Trigger
  ↓
Open Case
  ↓
Investigate Transaction
  ↓
Gather Connected Evidence
  ↓
Assess Uncertainty
  ↓
Retrieve Historical Context
  ↓
Initial Next-Best Action
  ↓
Request More Evidence
  ↓
Final Next-Best Action
  ↓
SAR Decision
  ↓
Write Case to Graph
  ↓
Read Back and Verify

The important word here is bounded.

The agent cannot endlessly call tools.

It operates with:

a maximum number of iterations;
a maximum number of tool calls;
explicit failure handling;
controlled graph access;
approval-gated actions.

That makes the system more predictable and auditable.

Controlled Graph Tools

I did not expose unrestricted GSQL execution to the agent.

Instead, the investigation layer provides a fixed set of typed tools.

Tool	Question
`get_transaction`	What exactly was flagged?
`card_history`	What does normal activity look like for this card?
`customer_cards`	What other cards belong to the customer?
`device_neighbours`	Who else used this device?
`closed_cases_for_cards`	Has this customer appeared in earlier investigations?
`similar_closed_cases`	Which historical cases share the pattern?
`case_memory`	What has our own agent investigated before?
`write_case` / `read_case`	Can we persist and verify the investigation?

This creates a strict boundary:

Agent
  ↓
Investigation Service
  ↓
Approved Tool
  ↓
TigerGraph

The agent cannot bypass that boundary and execute arbitrary queries.

Evidence Before Reasoning

One of the most important architectural decisions was separating raw graph data from investigation evidence.

TigerGraph produces graph facts.

The application converts those facts into structured evidence.

An evidence item can contain:

{
  "type": "shared_device",
  "status": "SUCCESS",
  "observation": "...",
  "interpretation": "...",
  "quality": "HIGH",
  "provenance": {
    "source": "tigergraph",
    "entity_id": "..."
  }
}

The system distinguishes:

SUCCESS
EMPTY
ERROR
NOT_INVESTIGATED

That distinction matters.

An empty graph result is not the same as an unavailable graph query.

For example:

Shared Device → EMPTY

means:

The query succeeded, but no shared-device relationship was found.

Whereas:

Shared Device → ERROR

means:

We were unable to obtain that evidence.

That prevents missing data from silently becoming "no evidence."

Evidence Quality

Another lesson was that not every relationship is equally strong.

Suppose several transactions share an address.

That does not automatically mean those transactions belong to one fraud ring.

Some attributes are naturally more discriminative than others.

So the investigation preserves evidence quality rather than treating every relationship as equal.

This becomes especially important when multiple signals disagree.

The system records:

Evidence coverage
Evidence quality
Signal conflicts
Data completeness
Missing evidence
Overall investigation uncertainty

Uncertainty Is Not Fraud Probability

This distinction became fundamental to the architecture.

The system tracks two different ideas.

Fraud likelihood

How strongly does the available evidence indicate fraud?

Investigation uncertainty

How uncertain are we about the investigation itself?

These are not the same thing.

For example:

Strong evidence + complete data
→ low investigation uncertainty

Missing device evidence + conflicting signals
→ higher investigation uncertainty

The uncertainty engine is deterministic and independent from the LLM.

That means uncertainty does not depend on a language model deciding how confident it "feels."

GraphRAG and Case Memory

Fraud investigations should not start from zero every time.

A previous investigation can contain useful context.

So I implemented structured historical retrieval.

The agent can retrieve:

similar historical cases;
recurring patterns;
previous outcomes;
relevant evidence patterns;
its own previously written cases.

The current implementation intentionally uses structured graph retrieval rather than an embedding/vector database.

The similarity model considers:

Signal	Weight
Evidence-type overlap	40%
Uncertainty-level match	20%
Action match	20%
Conflict overlap	10%
Trigger match	10%

That keeps retrieval deterministic and reproducible.

Historical cases are treated as data, not as instructions.

This also prevents historical content from becoming an uncontrolled prompt-injection mechanism.

The Agent

The orchestration layer uses LangGraph.

The workflow looks roughly like:

Initialize Case
      ↓
Investigate
      ↓
Assess Uncertainty
      ↓
Build Context
      ↓
Decide Next Step
   ↙          ↘
More Evidence  Enough Evidence
   ↓              ↓
Investigate     Policy
                  ↓
             Update Case
                  ↓
                 END

The LLM's role is deliberately constrained.

What the LLM can do

Interpret the current investigation state
Synthesize structured evidence
Identify information gaps
Use retrieved context
Explain findings
Support workflow decisions

What the LLM cannot do

Execute arbitrary GSQL
Directly call TigerGraph
Bypass the tool registry
Execute financial actions
Invent evidence
Replace deterministic graph analysis
Expose hidden chain-of-thought

The point is not to make the LLM do everything.

The point is to use the LLM where language reasoning is useful and structured systems where determinism matters.

Next-Best Action

After the evidence is collected, the system needs to answer:

"What should happen next?"

The project implements a policy-aware next-best-action layer.

Actions include:

ALLOW_TRANSACTION
BLOCK_TRANSACTION
MONITOR_ACCOUNT
WARN_CUSTOMER
CREATE_CASE
REQUEST_MORE_EVIDENCE
ESCALATE_ANALYST
FILE_REPORT

These decisions are evaluated using:

evidence sufficiency;
uncertainty;
evidence quality;
conflicting signals;
action permissions;
required approval route.

The resulting decision contains:

Action
Approval Route
Evidence IDs
Executable State
Rationale

The system does not automatically execute high-impact actions.

Where approval is required, the recommendation remains approval-gated.

Evidence Can Change the Decision

This is where the workflow becomes genuinely agentic.

The system is not limited to:

Investigate → Decide → Stop

Instead:

Investigate
    ↓
Uncertain
    ↓
Request Evidence
    ↓
Receive Evidence
    ↓
Reassess
    ↓
Change Recommendation

Across the official 20-case benchmark:

12 of 20 cases requested additional evidence, and the recommendation changed in all 12.

This demonstrates that the investigation is not simply a static classification step.

Case Management

Every investigation can become a structured case.

A case contains elements such as:

Case
 ├── Trigger
 ├── Status
 ├── Findings
 ├── Evidence
 ├── Decisions
 ├── Recommendations
 ├── Actions
 ├── Approval State
 ├── Outcomes
 └── Historical Context

The case state follows a controlled lifecycle:

OPEN
  ↓
INVESTIGATING
  ↓
PENDING_EVIDENCE
  ↕
INVESTIGATING
  ↓
ACTION_RECOMMENDED
  ↓
PENDING_REVIEW
  ├──→ CLOSED
  └──→ INVESTIGATING

A case that is written to the graph should not simply be assumed to exist.

For the official benchmark, all 20 generated cases were written to TigerGraph and then read back and compared.

20 out of 20 matched.

Suspicious Activity Reports

Fraud investigation can also lead to regulatory reporting.

The official benchmark policy distinguishes an internal investigation case from a Suspicious Activity Report.

The agent therefore evaluates SAR conditions separately from the ordinary case decision.

For the official benchmark:

5 SARs were filed.

Each report is generated from verified case facts and linked identifiers rather than invented narrative.

The Official HHGOA_IEEE Benchmark

The most important milestone came when I obtained the official HHGOA_IEEE package.

The package contained:

transactions.csv
identity.csv
closed_cases_history.csv
case_pack.csv
the official README and policy material

The dataset contains approximately 590,742 transactions and the benchmark contains exactly 20 cases — HHG-001 to HHG-020.

I validated the package against its README before running the benchmark.

Then I ran all 20 cases.

Final Benchmark Execution

Metric	Result
Cases executed	20 / 20
Completed	20 / 20
Failed	0
Partial	0
Case outputs generated	20 / 20
Cases written to TigerGraph	20 / 20
Cases read back and verified	20 / 20
NBA + approval before evidence	20 / 20
NBA + approval after evidence	20 / 20
Additional evidence requested	12 / 20
Recommendation changed after evidence	12 / 12
SARs filed	5

The produced verdict distribution was:

12 fraud
6 legitimate
2 uncertain

But there is an important caveat.

Why I Am Not Claiming an Accuracy Score

The official package does not contain an answer key.

The benchmark material states that the cases are scored against an answer key that participants do not receive.

Therefore, I am not presenting the benchmark's conformance checks as an accuracy score.

The system did validate every output for:

required structure;
policy consistency;
valid identifiers;
correct approval routes;
report/action agreement;
graph persistence.

Those checks demonstrate that the outputs conform to the required format and policy.

They do not prove that every investigation conclusion is correct.

I believe making that distinction explicit is important.

The Most Important Part: We Were Wrong First

One of the most valuable parts of the project was not the final run.

It was the failed runs.

The first benchmark run classified 16 out of 20 cases as fraud.

That clearly indicated a problem.

The biggest mistake was our shared-device logic.

Initially, the system interpreted:

"Many customers used the same device"

as evidence of a fraud ring.

But a popular phone is not automatically a fraud ring.

A device profile can naturally appear across many legitimate customers.

So instead of tuning against hidden benchmark answers, I went back to the data and studied the actual fraud-ring characteristics documented in the dataset.

The documented suspicious device had a much more specific fingerprint:

consistently marked as a new device;
associated with anonymous proxy behavior;
jumping between customers;
repeated activity across multiple cards;
overlap with previously investigated fraud rings.

That led to a more specific graph pattern.

The second run exposed another issue: some cases were being called fraud without an actual recognized pattern.

That exposed missing logic around identity history and customer-denial scenarios.

Those bugs were fixed.

The earlier runs remain archived.

I intentionally kept them because in a real fraud system, the wrong answer is often more informative than the perfect demo.

What the Benchmark Taught Me

1. Shared Does Not Mean Suspicious

A shared device or address is not inherently fraudulent.

You need contextual baselines.

The graph gives you connectivity.

The investigation logic determines whether that connectivity is meaningful.

2. Missing Evidence Should Be Explicit

There is a huge difference between:

No evidence exists

and:

We could not retrieve the evidence

The system keeps those states separate.

3. Uncertainty Is a Real Outcome

Sometimes the correct investigation state is not simply:

"Fraud."

It is:

"We don't know yet. Gather more evidence."

That is where an investigation agent can provide value beyond a static classifier.

4. Write and Verify

A successful database write should not be treated as an assumption.

The benchmark pipeline writes the case and reads it back.

The final state is only marked successful after verification.

5. Keep the Wrong Runs

The failed runs became some of the most useful engineering documentation in the project.

They exposed assumptions that looked reasonable but did not survive contact with the actual dataset.

Security and Human Approval

Because this system operates in a fraud-investigation context, safety boundaries matter.

The implementation includes:

controlled graph tools;
no arbitrary GSQL route;
read-only investigation tools;
approval-gated actions;
gitignored credentials;
no benchmark secrets in tracked files;
no hidden chain-of-thought exposed through the API;
explicit evidence provenance;
explicit missing and error states.

The frontend also never communicates directly with TigerGraph.

Everything goes through the backend API.

That keeps the graph and policy layer behind a controlled application boundary.

The Analyst Dashboard

The frontend is designed as a fraud investigation command center rather than a generic admin panel.

The workflow starts with a transaction ID.

The dashboard then presents:

Investigation Summary
        ↓
Next-Best Action
        ↓
Evidence
        ↓
Graph
        ↓
Uncertainty
        ↓
Findings
        ↓
Historical Cases
        ↓
Recurring Patterns
        ↓
Case Timeline

The graph visualization is generated from actual backend evidence.

It does not fabricate relationships for visual effect.

That was an important rule throughout the build:

The UI should visualize the investigation, not manufacture it.

Live dashboard:

https://hhgoa-fraud-frontend.vercel.app

Technology Stack

Backend

Python
FastAPI
LangGraph
TigerGraph
GSQL
Structured policy engine
Case management layer

Frontend

Next.js 16
React 19
TypeScript
Tailwind CSS

Graph and AI

TigerGraph Savanna
Graph-based investigation
Structured GraphRAG
Agent orchestration
Deterministic uncertainty evaluation
Case memory

What I Would Build Next

Make Memory Influence Decisions

Historical cases should eventually become a real signal rather than only contextual evidence.

Calibrate Probabilities

The current probabilities use hand-set weights derived from documented dataset behavior.

With more time, I would calibrate those weights against the labelled closed investigations.

Add Richer Graph Algorithms

Community detection and graph-based clustering could identify fraud rings without relying entirely on manually defined fingerprints.

Add True Document GraphRAG

Policy documents, closed-case narratives and regulatory references could be indexed alongside graph relationships to create richer investigation context.

Bring the LLM Deeper Into the Workflow

A future version could use the LLM for:

case summaries;
SAR narrative generation;
evidence synthesis;
analyst-facing explanations;

while still validating every claim against graph-backed evidence.

Final Thoughts

Building this project changed the way I think about agentic systems.

The temptation with an AI agent is to make the model do everything.

For fraud investigation, I do not think that is the right architecture.

The better approach is to divide responsibilities:

TigerGraph
→ Find the relationships

Investigation Layer
→ Turn relationships into evidence

Uncertainty Engine
→ Measure what we know and don't know

Case Memory
→ Remember what happened before

Policy Engine
→ Determine what should happen next

Agent
→ Orchestrate the workflow

Analyst
→ Remain in control of consequential actions

That is the system I built for Hacker House Goa '26.

Not a chatbot that simply says whether a transaction "looks fraudulent."

An agentic investigation workflow that can trace relationships, gather evidence, recognize uncertainty, request additional information, recommend a next-best action, and leave behind a verifiable case.

The graph does the finding.

The policy does the deciding.

The agent connects them.

And the analyst remains in control.

Links

GitHub: https://github.com/rohan911438/HHGOA_26

Live Demo: https://hhgoa-fraud-frontend.vercel.app

Demo Video: https://youtu.be/0dqjXyY2Hoc

Builder: Rohan Kumar
Team: BROTHERHOOD
Team Size: 1

Built for Hacker House Goa '26 — TigerGraph Challenge.

Building the Agentic Economy on Stellar: Why We Created Hypha Protocol and Mycelium

Rohan Kumar — Wed, 08 Jul 2026 12:29:08 +0000

How two builders went from asking "How will AI agents pay each other?" to building the missing infrastructure for autonomous AI economies on Stellar.

AI Agents Are Everywhere. But They're Still Alone.

Over the past year, AI agents have evolved from simple chatbots into autonomous systems capable of reasoning, planning, writing code, using external tools, and collaborating with other models.

As we built AI products, we kept asking ourselves one question:

What happens when AI agents no longer need humans in the loop?

If an agent can think, why can't it hire another agent?

If an agent can complete work, why can't it get paid?

If multiple agents solve a problem together, who coordinates them?

How do autonomous agents discover each other?

How do they establish trust?

How do they prove ownership?

How do they build reputation?

These weren't AI problems.

They were infrastructure problems.

And that realization became the beginning of Mycelium.

Why Stellar?

When we started exploring blockchain infrastructure, Stellar immediately stood out.

It offers everything autonomous systems need:

Fast finality
Extremely low transaction fees
Soroban smart contracts
Native asset support
Excellent developer experience
A mature payments ecosystem

We quickly realized that Stellar could become the settlement layer for autonomous AI agents.

But one important piece was still missing.

The Missing Infrastructure

Today's AI frameworks are incredibly powerful at helping agents think.

Blockchain networks are excellent at helping applications transact.

But there was no native infrastructure connecting the two.

AI agents still couldn't:

Discover one another.
Exchange capabilities.
Build trust.
Coordinate work.
Negotiate tasks.
Build reputation.
Receive autonomous payments.

Existing Agent-to-Agent (A2A) standards were primarily designed around Ethereum. While they provided valuable ideas, Stellar required an implementation designed specifically for Soroban and the Stellar ecosystem.

Rather than waiting for that infrastructure to appear, we decided to build it ourselves.

Introducing Hypha Protocol

Hypha Protocol is our native Agent-to-Agent (A2A) protocol built specifically for Stellar.

Think of it as the communication and trust layer for autonomous AI agents.

Through Hypha, agents can:

Register identities on-chain
Discover other agents
Exchange capabilities
Negotiate securely
Build reputation
Validate completed work
Settle payments autonomously

Hypha combines Soroban smart contracts, Stellar-native identity, encrypted off-chain communication, and programmable micropayments into one unified protocol.

Instead of isolated AI systems, we now have a network where autonomous agents can collaborate securely without centralized intermediaries.

In many ways, Hypha acts like the underground fungal network found in nature—connecting independent organisms into one intelligent ecosystem.

That's exactly where its name comes from.

But Protocols Alone Don't Help Developers

After building Hypha, we realized something important.

Protocols solve infrastructure problems.

Developers still need a great developer experience.

Most blockchain development still requires learning new languages, complex tooling, and low-level smart contract concepts.

We wanted to change that.

Introducing Mycelium

Mycelium is the developer platform built on top of Hypha Protocol.

Instead of learning Rust or worrying about blockchain internals, developers simply write Python.

Mycelium takes care of everything else.

Using Mycelium, developers can:

Build AI agents entirely in Python
Compile Python into Soroban smart contracts
Deploy agents directly to Stellar
Register agents on-chain
Discover other autonomous agents
Publish and claim decentralized bounties
Receive escrow-backed payments
Store portable, verifiable agent memory

Our goal wasn't simply to create another framework.

Our goal was to make blockchain-native AI development feel as natural as writing a Python application.

Why Build Both?

One of the questions we get most often is:

"Why build both Hypha Protocol and Mycelium?"

The answer is simple.

They solve different problems.

Hypha Protocol provides the decentralized coordination layer.

It handles:

Identity
Discovery
Reputation
Communication
Trust
Settlement

Mycelium provides the developer experience.

It gives developers the tools to build autonomous agents without worrying about blockchain complexity.

Together, they transform isolated AI agents into autonomous economic participants.

Our Vision

We don't believe the future will consist of one giant AI model.

We believe it will consist of millions—eventually billions—of specialized AI agents.

Some will write software.

Some will perform research.

Some will analyze financial markets.

Some will automate businesses.

Some will negotiate with other agents.

Some will create entirely new digital services.

These agents will need to:

Discover one another
Exchange value
Build trust
Coordinate work
Earn autonomously

We believe Stellar provides the perfect foundation for that future.

And we're building the infrastructure to make it possible.

Try Mycelium

We're currently in beta and would love feedback from builders across the Stellar ecosystem.

Website

https://mycelium.isriz.xyz

Documentation

https://mycelium.isriz.xyz/docs

GitHub — Mycelium

https://github.com/MyceliumStellar/Mycelium

GitHub — Hypha Protocol

https://github.com/MyceliumStellar/HyphaProtocol

PyPI

https://pypi.org/project/mycelium-stellar/

We'd Love Your Feedback

This is only the beginning.

We're continuing to improve the developer experience, expand the protocol, and build the infrastructure for autonomous AI economies on Stellar.

If you're building with Stellar, experimenting with AI agents, or simply curious about where autonomous systems are heading, we'd love for you to try Mycelium and share your feedback.

Every suggestion, issue, and discussion helps us make the platform better.

Final Thoughts

Artificial Intelligence has already changed how software is built.

The next transformation won't just be smarter AI.

It will be autonomous AI.

Autonomous systems won't simply answer questions.

They'll discover opportunities.

Negotiate work.

Collaborate with other agents.

Exchange value.

Build trust.

And participate in entirely new digital economies.

We believe that future deserves infrastructure built specifically for it.

That's why we created Hypha Protocol.

That's why we built Mycelium.

And we're just getting started.

Welcome to the Agentic Economy.

From Confusion to Running My First Bittensor Miner: My Learning Journey Through HackQuest Co-Learning Camp #21

Rohan Kumar — Wed, 24 Jun 2026 09:01:50 +0000

Introduction

When I first joined the HackQuest India x Bittensor Co-Learning Camp #21, I had heard about Bittensor but didn't truly understand what made it different.

I knew it had something to do with decentralized AI. I knew there were miners and validators. I knew people were building AI-powered subnets.

But if someone had asked me how Bittensor actually worked, I probably wouldn't have been able to explain it.

Fast forward a few weeks, and I found myself setting up wallets, learning BTCLI, exploring subnet architecture, and eventually running my first miner.

This blog is not a technical guide. Instead, it's a story of my learning journey, the mistakes I made, what surprised me, and what I'd tell anyone starting today.

The Beginning: "What Even Is Bittensor?"

My first challenge wasn't running a miner.

It was understanding what Bittensor actually is.

Most blockchain ecosystems focus on transactions, DeFi, NFTs, or smart contracts.

Bittensor felt different.

The idea behind Bittensor is simple but powerful:

Create a decentralized marketplace for intelligence.

Instead of one company controlling AI models, anyone can contribute value through specialized networks called subnets.

Each subnet focuses on a specific task.

Inside every subnet:

Miners produce value.
Validators evaluate that value.
Incentives reward useful contributions.

That concept immediately caught my attention because it combines two areas I'm interested in:

Artificial Intelligence
Decentralized Systems

Learning BTCLI

Before touching mining, our camp focused on BTCLI.

At first I underestimated its importance.

I thought it was simply a wallet management tool.

I was wrong.

BTCLI is basically the command center for interacting with the Bittensor ecosystem.

Using BTCLI, I learned how to:

Create wallets
Manage hotkeys and coldkeys
Query subnet information
Inspect network data
Explore validator and miner information

One thing that stood out was the hotkey/coldkey model.

Coming from traditional software development, I wasn't used to separating operational keys from ownership keys.

The design made a lot of sense once I understood the security implications.

Understanding Subnets

The next major breakthrough came when I finally understood subnets.

Before the camp, I assumed Bittensor was a single AI network.

In reality, it's more like an ecosystem of AI marketplaces.

Each subnet has:

Its own community
Its own objective
Its own incentive mechanism

Some subnets focus on language tasks.

Others focus on different AI capabilities.

This flexibility is what makes Bittensor fascinating.

Every subnet can experiment independently while remaining connected to the broader ecosystem.

My First Attempt at Running a Miner

This was the point where theory became practice.

Like most beginners, I expected everything to work perfectly the first time.

It didn't.

I ran into setup issues.

I spent time reading documentation.

I double-checked configurations.

I learned that blockchain infrastructure requires patience.

The biggest lesson wasn't technical.

It was mental.

Instead of blindly copying commands, I started asking:

"What is this command actually doing?"

That small shift helped me understand the system much better.

The Moment It Finally Worked

There is a special feeling when something you've been learning about finally starts running.

After spending time understanding wallets, subnets, and network interactions, seeing my miner come online felt rewarding.

Not because I was earning anything significant.

But because I finally understood how the pieces fit together.

The miner wasn't just a process running on my machine.

It was a participant in a much larger ecosystem.

For the first time, I wasn't just reading about Bittensor.

I was interacting with it.

What Surprised Me Most

Several things surprised me during the camp.

1. Bittensor Is More Than AI

Initially I thought Bittensor was simply an AI blockchain.

The deeper I went, the more I realized it's really an incentive system for intelligence.

The network isn't rewarding activity.

It's rewarding useful contributions.

That's a much harder problem to solve.

2. Incentives Matter

Many technical systems focus entirely on architecture.

Bittensor focuses heavily on incentives.

The question isn't:

"Can we build AI?"

The question is:

"How do we reward valuable intelligence fairly?"

That perspective changed how I think about decentralized systems.

3. Community Learning Helps

There were several moments where documentation alone wasn't enough.

Being part of the HackQuest community made the learning process much easier.

Sometimes a simple conversation saves hours of confusion.

Challenges Along the Way

My journey wasn't perfect.

Some challenges included:

Understanding subnet terminology
Learning wallet management
Understanding validator-miner relationships
Navigating documentation
Connecting concepts together

At times, I felt like I understood individual pieces but not the whole picture.

Eventually everything started clicking.

That seems to be how most technical learning works.

Lessons for Beginners

If you're starting your Bittensor journey today, here are a few things I'd recommend.

Don't Rush

It's tempting to jump directly into mining.

Spend time understanding the fundamentals first.

Learn BTCLI Properly

BTCLI teaches you how the ecosystem operates.

Those skills become useful later.

Read the Documentation

Many questions already have answers in the docs.

Learning how to navigate documentation is a skill by itself.

Experiment

The best way to learn is by doing.

Reading is important.

Building is better.

Ask Questions

Nobody understands everything on day one.

The community exists for a reason.

Looking Ahead

Running my first miner is only the beginning.

I'm excited to continue learning about:

Validators
Subnet development
Incentive mechanisms
Yuma Consensus
Advanced Bittensor architecture

The more I learn, the more I realize how much there is still to explore.

And that's what makes the journey interesting.

Final Thoughts

The HackQuest India x Bittensor Co-Learning Camp #21 has been one of the most hands-on learning experiences I've participated in recently.

What started as curiosity about decentralized AI turned into a practical exploration of wallets, subnets, BTCLI, and mining.

Running my first miner wasn't just a technical achievement.

It was the moment when the concepts stopped being abstract and started becoming real.

For anyone considering learning Bittensor, my advice is simple:

Start small.

Stay curious.

Break things.

Fix them.

And keep building.

The ecosystem is still growing, which means there has never been a better time to learn.

Thank you to @HackQuestIN, @bittensor, and @AbhirupTweetOn for organizing this learning opportunity.

See you on the next milestone of the journey

My First Steps into the Bittensor Ecosystem: Learning BTCLI Through HackQuest Co-Learning Camp #21

Rohan Kumar — Wed, 17 Jun 2026 03:28:15 +0000

Introduction

When I first joined the HackQuest India x Bittensor Co-Learning Camp #21, I honestly did not know much about Bittensor beyond hearing that it was related to decentralized AI. Like many students exploring Web3 and AI, I had seen discussions around machine learning, blockchain, and open-source development, but Bittensor seemed to be creating something different.

Instead of building another AI application, Bittensor is attempting to create a decentralized network where intelligence itself becomes a digital commodity. That idea immediately caught my attention.

During the first phase of the camp, our focus was on understanding the ecosystem and getting familiar with BTCLI, the command-line interface used to interact with the Bittensor network. While it might sound simple, learning BTCLI gave me a much better understanding of how the network operates and how participants interact with it.

This article is a reflection of my learning journey so far, the challenges I faced, the concepts that surprised me, and the lessons I would share with someone starting today.

What is Bittensor?

Before touching BTCLI, I wanted to understand what Bittensor actually is.

Most AI systems today are controlled by a handful of large companies. They own the models, infrastructure, and data. Bittensor proposes a different approach.

The network allows participants to contribute intelligence, validate outputs, and earn rewards through a decentralized protocol. Instead of one company deciding which model is useful, the network collectively determines value.

What fascinated me was the idea that machine intelligence can be treated almost like a marketplace.

Participants contribute useful outputs.

Validators evaluate contributions.

Rewards are distributed according to value.

Everything happens on-chain.

This was a completely different way of thinking about AI.

My First Encounter with BTCLI

The first practical tool we explored was BTCLI.

Initially, I assumed it would simply be a wallet management tool. However, after spending time with it, I realized it serves as a gateway into the entire Bittensor ecosystem.

Through BTCLI, users can:

Create wallets
Manage keys
Interact with subnets
Check balances
Register miners
Query network information
Monitor participation

For someone interested in understanding the network beyond the surface level, BTCLI is essential.

Setting Up BTCLI

The installation process itself was a learning experience.

Like many developers, I am comfortable working with command-line tools, but blockchain-related CLI tools often introduce their own terminology and workflows.

During setup, I spent time understanding:

Wallet creation
Coldkeys and hotkeys
Network configuration
Security practices

One of the first things that stood out was the distinction between coldkeys and hotkeys.

Coming from a more traditional software development background, this was a concept I had heard about but never actively used.

The coldkey acts as the secure owner account.

The hotkey acts as the operational account used for network activities.

This separation improves security and helps reduce risk.

Understanding Wallets and Keys

One of the biggest lessons from the early sessions was that managing wallets correctly is extremely important.

When creating a wallet, BTCLI generates recovery information that must be stored securely.

At first, it feels similar to setting up any crypto wallet.

However, as I explored more commands and documentation, I realized that losing access to keys can have significant consequences for participation in the network.

This reinforced a lesson that applies throughout Web3:

Always prioritize security before experimentation.

Exploring the Network

After getting comfortable with wallet creation, I began exploring network information using BTCLI.

This was the moment when the ecosystem started feeling real.

Instead of reading documentation, I could actually see:

Network data
Active subnets
Registered participants
Blockchain information

Seeing live network activity helped bridge the gap between theory and practice.

Many tutorials focus on concepts.

Actually querying a live network makes those concepts easier to understand.

Challenges I Faced

Not everything was easy.

One challenge was understanding the terminology.

Words like:

Validators
Miners
Subnets
Stake
Registration

are common in documentation, but understanding how they connect requires time.

I often found myself opening multiple resources simultaneously:

Documentation
Community discussions
Session recordings
BTCLI help commands

Another challenge was resisting the urge to rush.

In blockchain ecosystems, it is tempting to copy commands and move forward quickly.

I discovered that spending a few extra minutes understanding what a command actually does saves a lot of confusion later.

What Surprised Me Most

The biggest surprise was how much thought has gone into network incentives.

At first glance, Bittensor appears to be just another blockchain project.

The deeper I explored, the more I realized it is really an experiment in coordinating intelligence.

The network isn't simply rewarding activity.

It attempts to reward useful contributions.

That distinction is important.

Creating a decentralized system where participants are incentivized to provide valuable outputs is a fascinating challenge.

Why Learning BTCLI Matters

Many newcomers want to jump directly into mining, subnet development, or advanced concepts.

After working with BTCLI, I believe learning the CLI first is extremely valuable.

It forces you to understand:

How wallets work
How the network is structured
How participants interact
How information is queried

Without these fundamentals, advanced topics become much harder to understand.

Think of BTCLI as learning the controls before driving the car.

Advice for Beginners

If you're just starting your Bittensor journey, here are a few suggestions based on my experience so far.

1. Take Notes

There are many new concepts.

Writing things down helps connect the dots later.

2. Use the Help Commands

The CLI documentation is your friend.

Many questions can be answered directly from the terminal.

3. Don't Rush

Understanding the ecosystem is more valuable than blindly following commands.

4. Engage With the Community

The learning curve becomes much easier when discussing concepts with others.

5. Focus on Fundamentals

Wallets, keys, subnets, and network structure should be understood before moving into advanced topics.

Looking Ahead

This is only the beginning of my journey in the Bittensor ecosystem.

So far, we have focused primarily on understanding the network and learning BTCLI.

In the coming weeks, I am excited to explore:

Subnets
Mining
Validation
Incentive mechanisms
Decentralized AI applications

I believe the most valuable part of this camp is not just learning commands but understanding the broader vision behind the technology.

Bittensor is attempting to build an open marketplace for intelligence, and being able to learn directly through hands-on exploration makes the experience much more meaningful.

Final Thoughts

The HackQuest India x Bittensor Co-Learning Camp #21 has already helped me move from curiosity to practical understanding.

Learning BTCLI may seem like a small step, but it provided the foundation needed to navigate the ecosystem with confidence.

The experience reminded me that every advanced system starts with simple fundamentals.

Before building, mining, or contributing, we first need to understand the tools.

For me, BTCLI was that first step.

I'm excited to continue learning, experimenting, and sharing my journey as I explore the world of decentralized AI through Bittensor.

Thank you to HackQuest India and the Bittensor community for creating opportunities like this for learners and builders.

HackQuest #Bittensor #DecentralizedAI #Web3 #AI #LearningInPublic

The Hidden Winner of the 2026 FIFA World Cup: Prediction Markets

Rohan Kumar — Fri, 12 Jun 2026 07:00:24 +0000

Why the Biggest Financial Event of the Tournament Might Not Be Football

Every four years, the FIFA World Cup captures the attention of billions of people worldwide. Fans fill stadiums, advertisers spend billions, broadcasters compete for rights, and brands race to attach themselves to the biggest sporting spectacle on Earth.

But in 2026, there may be another winner quietly emerging behind the scenes:

Prediction markets.

While the world watches goals, penalties, and dramatic upsets, millions of users are placing forecasts on outcomes across decentralized and centralized prediction platforms.

And for the first time in history, prediction markets could become one of the most important financial ecosystems surrounding a sporting event.

I believe the 2026 FIFA World Cup could drive close to $1 billion in prediction market volume and related ecosystem activity, making it one of the largest prediction market events ever recorded.

More importantly, it may mark the beginning of a future where prediction markets generate more economic activity than the sporting events themselves.

That sounds crazy today.

It won't sound crazy a decade from now.

The Rise of Prediction Markets

Prediction markets are platforms where users trade on future outcomes.

Instead of betting against a bookmaker, participants buy and sell probabilities.

Questions look simple:

Who will win the World Cup?
Will Brazil reach the semi-finals?
Will Argentina score more than 10 goals?
Will France defeat England?
Who will win the Golden Boot?

Each prediction becomes a market.

Each market becomes a source of liquidity.

Each source of liquidity attracts traders, speculators, sports fans, market makers, and algorithms.

The result is an entirely new economy built around information.

Every Blockchain Wants Its Own Prediction Market

Unlike previous World Cups, the 2026 tournament arrives during the age of blockchain ecosystems.

Today almost every major chain has its own prediction market ambitions.

Examples include:

Polygon ecosystem projects
Solana prediction applications
Ethereum based markets
Base ecosystem applications
BNB Chain prediction platforms

Why?

Because prediction markets solve a major problem for blockchains:

They create recurring user activity.

A football fan doesn't need to understand DeFi.

They don't need to understand smart contracts.

They simply need an opinion.

And everyone has an opinion during the World Cup.

The Reward War Has Already Started

Prediction markets are no longer competing only on product quality.

They are competing on incentives.

This changes everything.

Platforms now offer:

Trading rewards
Loyalty points
Airdrop campaigns
Ecosystem incentives
Referral programs
Liquidity mining
Quest-based rewards

Users are no longer participating solely because they believe they can predict outcomes.

They are participating because they can earn additional rewards regardless of the match result.

This creates a powerful growth loop:

Rewards attract users.
Users create liquidity.
Liquidity improves markets.
Better markets attract more traders.
More traders justify larger reward pools.

The cycle repeats.

Why the World Cup Is the Perfect Prediction Market Event

Most sporting events struggle to reach mainstream audiences.

The FIFA World Cup is different.

The tournament delivers:

Global Attention

More than five billion people are expected to engage with World Cup content globally.

Few events can match this reach.

Continuous Market Opportunities

A single final creates one market.

A World Cup creates thousands.

Every match can generate:

Match winner markets
Goal markets
Player performance markets
Group qualification markets
Knockout qualification markets
Tournament winner markets

One tournament becomes an entire marketplace.

Emotional Trading

Financial markets are often driven by information.

Sports prediction markets are driven by emotion.

Emotion increases participation.

Participation increases liquidity.

Liquidity increases revenue.

Why $1 Billion Is Not Impossible

Many people hear "$1 billion" and assume it is unrealistic.

I think the opposite.

Consider the ingredients:

Massive Audience

The World Cup is arguably the largest sporting event on the planet.

Global Accessibility

Prediction platforms operate online and increasingly through mobile applications.

Crypto Adoption

Millions of users already hold digital assets and can participate without traditional banking restrictions.

Incentive Programs

Reward pools continue to grow as ecosystems compete for attention.

Multiple Platforms

The volume is not concentrated on one platform.

It is distributed across dozens of platforms, chains, and jurisdictions.

When all of these factors combine, reaching hundreds of millions—or even approaching a billion dollars in cumulative prediction market activity—becomes increasingly plausible.

The Bigger Prediction: One Day Prediction Markets Will Generate More Revenue Than FIFA

This sounds outrageous today.

But consider what happened in other industries.

Financial derivatives became larger than the underlying assets.

Advertising ecosystems became larger than the content they supported.

Gaming economies became larger than some traditional entertainment businesses.

Prediction markets may follow the same path.

Why?

Because FIFA can only monetize a limited number of things:

Broadcasting rights
Sponsorships
Ticket sales
Merchandise

Prediction markets can monetize something much larger:

Every opinion held by every fan.

That is a much bigger market.

A football match lasts 90 minutes.

Debates about the match can last weeks.

Prediction markets transform those debates into economic activity.

The Information Economy of Sports

The future of sports may not be defined by who watches.

It may be defined by who predicts.

Imagine a world where:

Every major sporting event has thousands of active markets.
AI agents trade probabilities automatically.
Fans earn rewards for accurate forecasts.
Teams, brands, and media companies integrate prediction data directly into broadcasts.

In that world, prediction markets become an information layer sitting on top of sports itself.

And information markets are often larger than entertainment markets.

Final Thoughts

The 2026 FIFA World Cup may be remembered for great goals, unforgettable upsets, and legendary performances.

But it could also be remembered as the moment prediction markets entered the mainstream.

For the first time, billions of viewers, millions of traders, dozens of blockchains, and hundreds of millions of dollars in incentives are converging around a single global event.

Whether the final number is $500 million, $1 billion, or even more, the direction is clear.

Prediction markets are no longer a niche experiment.

They are becoming a new financial layer for global attention.

And the World Cup may be the catalyst that proves just how large that layer can become.

Building Sentinel AI: Honest Feedback from a Builder After Shipping a Full Multi-Agent Smart Account Application

Rohan Kumar — Fri, 05 Jun 2026 13:56:09 +0000

Introduction

Over the last several days, I built Sentinel AI, an autonomous investment committee powered by:

MetaMask Smart Accounts
ERC-7715 Advanced Permissions
ERC-7710 Redelegation
x402 Payments
1Shot Permissionless Relayer
Venice AI

Unlike most hackathon feedback, this is not a project showcase.

This is builder feedback.

The goal is simple:

What worked exceptionally well?

What slowed development?

What can be improved for future builders?

After spending dozens of hours reading documentation, deploying contracts, debugging integrations, and connecting multiple systems together, I think I can provide feedback that is both practical and actionable.

What MetaMask Got Extremely Right

1. Smart Accounts Finally Make AI Agents Practical

The biggest takeaway from this hackathon is that Smart Accounts fundamentally change how AI systems can interact with crypto.

Before learning MetaMask Smart Accounts, my mental model was:

User owns wallet
User signs everything
AI can only recommend

After implementing ERC-7715 and ERC-7710, the model became:

User defines boundaries
AI operates inside boundaries
Blockchain enforces the rules

This is a massive shift.

It is probably the most important thing I learned during the entire hackathon.

The permission model feels genuinely future-proof.

2. Documentation Quality Was Surprisingly High

One thing I want to specifically praise is the quality of the MetaMask documentation.

Most Web3 documentation explains APIs.

MetaMask documentation explains concepts.

That difference matters.

The explanations around:

Smart Accounts
Delegation
Redelegation
Advanced Permissions

were much easier to understand than similar account abstraction documentation from other ecosystems.

This significantly reduced the learning curve.

Where MetaMask Documentation Can Improve

1. Missing End-to-End Examples

This was probably the single biggest friction point.

Most documentation pages explain individual concepts well.

However, real applications combine everything.

As a builder, I constantly wanted a single example showing:

User Connect Wallet
↓
Create Smart Account
↓
Grant ERC-7715 Permission
↓
Create Session Key
↓
Redelegate Permission
↓
Execute Transaction
↓
Revoke Permission

Currently, this flow exists across multiple documentation pages.

Future builders would benefit enormously from one complete reference implementation.

Suggested Improvement

Create a dedicated:

Full Lifecycle Smart Account Example

with frontend, backend, and smart contract code.

This would probably save builders several hours.

2. More Architecture Diagrams

The documentation is technically strong.

However, Smart Accounts are fundamentally visual systems.

When implementing redelegation, I found myself drawing diagrams manually.

For example:

User
↓
Smart Account
↓
Session Account
↓
Execution Agent
↓
1Shot Relayer
↓
Blockchain

I believe every major documentation section should include:

Architecture diagram
Sequence diagram
Permission flow diagram

This would dramatically improve comprehension.

3. Better Error Troubleshooting

One challenge I encountered repeatedly:

I would receive an error.

The documentation explained how things work.

But not why they fail.

Examples:

Invalid delegation
Permission context mismatch
Session account issues
Smart account initialization failures

A dedicated troubleshooting database would be extremely valuable.

Something similar to:

Common Error

Cause

Solution

would save builders substantial time.

What 1Shot Did Extremely Well

1. The Relayer Is Genuinely Impressive

The 1Shot Permissionless Relayer was probably the smoothest integration in the entire stack.

The capability discovery endpoint was especially useful.

Instead of hardcoding assumptions, applications can dynamically determine:

Supported chains
Payment tokens
Delegation targets
Fee structures

This feels significantly more scalable than traditional approaches.

2. Gas Abstraction Feels Like Magic

One of the strongest moments in my build process was seeing transactions executed without worrying about native gas tokens.

This sounds simple.

But for user experience, it is transformative.

Most users do not care about gas.

They care about outcomes.

1Shot aligns perfectly with that reality.

Where 1Shot Can Improve

1. More Real-World Production Examples

Most builders are not creating simple token transfer demos.

They're creating:

Agents
DAOs
Portfolio managers
Automation systems

I would love to see:

Example Projects

AI Agent + Relayer
DAO Treasury + Relayer
Smart Account + Relayer
x402 + Relayer

These examples would accelerate adoption significantly.

2. Better Webhook Documentation

Webhooks are powerful.

However, they are also where many production systems break.

More examples covering:

Retry logic
Signature verification
Event ordering
Failure handling

would be extremely useful.

What Venice AI Did Well

1. The Idea Is Powerful

The most exciting aspect of Venice is not the model itself.

It is the philosophy.

Permissionless intelligence.

Permissionless payments.

Permissionless infrastructure.

That combination is incredibly powerful for agentic systems.

The vision aligns perfectly with where autonomous applications are heading.

Where Venice Can Improve

1. More Web3-Specific Agent Examples

Most AI providers show:

Chatbots
Assistants
Content generation

Builders in this hackathon are building:

Trading agents
Governance agents
Treasury agents
Research agents

Dedicated examples would help developers understand best practices much faster.

Feedback for HackQuest

1. Excellent Track Design

The track structure was one of the strongest aspects of the hackathon.

Most hackathons reward feature accumulation.

This event rewarded architecture.

That encouraged builders to think deeply about systems rather than simply adding more buttons.

2. Better Resource Organization

As the event progressed, I found resources spread across:

Documentation sites
GitHub repositories
Discord discussions
HackQuest resources

A centralized builder portal would improve navigation significantly.

3. Weekly Technical Office Hours

This is probably my biggest recommendation.

Builders often spend:

30 minutes coding
5 hours debugging

A weekly technical office hour with ecosystem teams could dramatically improve builder velocity.

Even one session per week would create enormous value.

The Biggest Lesson From Building Sentinel AI

The biggest lesson wasn't about AI.

It wasn't about smart contracts.

It wasn't about relayers.

It was about permissions.

The future of Web3 is not giving software unlimited authority.

The future is programmable trust.

MetaMask Smart Accounts, ERC-7715, ERC-7710, x402, and 1Shot collectively point toward a future where autonomous agents can safely act on behalf of humans.

That future feels much closer after building Sentinel AI.

And for that reason alone, this hackathon was worth participating in.

Thank you to the MetaMask, Venice AI, 1Shot API, and HackQuest teams for creating an event that pushed builders to explore what autonomous onchain systems can become.

Is the AI Doom Narrative Slowing Down — Or Are We Just Delaying the Inevitable?

Rohan Kumar — Tue, 02 Jun 2026 03:51:18 +0000

Two years ago, the conversation around AI and employment had a certain electric panic to it. Software engineers, writers, analysts — knowledge workers of every stripe — were being told that their careers faced an existential reckoning. Models were accelerating. Automation was arriving. The disruption was a matter of when, not if.

Then something shifted.

Today, you're more likely to hear that AI is "just a productivity tool." That teams still need engineers. That AI-generated code is expensive, messy, and hard to maintain without skilled human oversight. That the copilot, not the replacement, is the more accurate metaphor.

It all sounds very reasonable. Very measured. Very… convenient.

The question worth asking is not whether these claims are technically accurate. Some of them are. The question is whether the narrative shifted because the technology changed — or because the business environment changed.

The Current Argument, and Why It's Being Made

The argument being made today goes roughly like this: AI coding tools are expensive to run at scale. The outputs frequently require human review and correction. Complex systems still demand experienced engineers who understand architecture, edge cases, and business logic. Therefore, software engineers aren't going anywhere.

On the surface, this is true. No serious observer believes AI will eliminate every software engineering job in the next two years.

But notice something about who is making this argument most loudly. It's the same companies whose valuations depend on enterprise adoption, whose IPO narratives require institutional trust, and whose continued hiring practices signal stability to regulators and the public. Reassuring engineers isn't purely altruistic — it's also strategically sensible.

Note: This is not an accusation of bad faith. Companies can simultaneously believe something and benefit from saying it. The overlap between sincere belief and business interest doesn't make either false — but it does warrant scrutiny.

Why I Remain Skeptical

Here's what gets lost in the "AI won't replace engineers" framing: complete replacement is not required to cause profound disruption.

If a company that previously needed 10 engineers now needs 5, that is a seismic shift for the profession — even if no single engineer was "replaced by AI." Hiring demand drops. Entry-level positions disappear. The pipeline narrows. Those effects compound over years, quietly, without a single dramatic announcement.

The automation of labor doesn't always look like robots taking over factory floors. Sometimes it looks like a hiring freeze that never gets reversed. Sometimes it looks like a team of three doing what a team of eight used to do — and no one calling a press conference about it.

The Cost Argument Is a Temporary Phenomenon

One of the more substantive critiques of AI coding assistance is cost. Running large models at scale isn't cheap, and for many organizations, the economics don't yet pencil out favorably against the cost of senior engineers.

This is a legitimate observation. It is also, almost certainly, temporary.

Technology costs fall. This is one of the most reliable patterns in the entire history of computing. Processing power, storage, bandwidth — every major infrastructure cost has followed a downward trajectory that would have seemed implausible to contemporaries at the time.

AI inference is no different. We are currently watching an entire industrial ecosystem organize itself around making AI cheaper to run — model compression, quantization, specialized inference chips, open-source alternatives from DeepSeek, Mistral, and others that dramatically undercut the pricing of frontier models.

To argue that AI won't disrupt engineering because it's currently expensive is roughly equivalent to arguing in 1994 that the internet wouldn't change publishing because dial-up was too slow.

The economics of 2024 are not the economics of 2028.

On Amodei, Altman, and the Tone Shift

Something interesting happened in the past 12–18 months. Leaders at the very top of the AI industry — people who had previously spoken with great urgency about the coming transformation of knowledge work — began making notably more measured statements.

Dario Amodei and Sam Altman have both, at various points, suggested that software engineering jobs may be more resilient than earlier framings implied, or that the transition will be slower, or that the "copilot" framing is more accurate than "replacement."

Why the shift?

It's worth considering — and this is speculation, not accusation — that both Anthropic and OpenAI now operate under significant business constraints. Regulatory scrutiny has intensified globally. Public concern about labor displacement is a real political force. Institutional investors and potential public market investors tend to prefer narratives of augmentation over disruption.

To be clear: there is no evidence that either company is being dishonest. But the alignment between the new narrative and their business interests is striking enough to notice.

The Bigger Contradiction

Here is the tension I find most difficult to reconcile with the reassuring narrative:

The same companies telling us that AI is merely a productivity tool are simultaneously spending hundreds of billions of dollars to make AI more autonomous, more capable, and more intelligent. They are pursuing AGI. Some speak openly about ASI.

"If AI is only ever meant to assist humans — never to replace human judgment — why is the entire frontier of AI research pointed toward systems that reason independently, act autonomously, and improve recursively?"

You cannot simultaneously argue that AI will never replace human knowledge workers and that the goal is to build systems of superhuman intelligence. Those two positions are not compatible over any meaningful time horizon.

The Human Advantage Is Shrinking

What does modern knowledge work actually consist of? For most roles, it breaks down into pattern recognition, synthesis of existing information, prediction based on historical data, structured reasoning, and communication of conclusions.

These are not areas where AI is struggling. These are areas where AI is improving most rapidly.

Look honestly at your own work this week. How much of it was genuinely novel judgment — the kind of contextual, embodied, relationship-dependent cognition that requires human presence? And how much was pattern matching, drafting, summarizing, organizing, and reviewing?

For most knowledge workers, the honest answer reveals that the ratio is more tilted toward the latter than we'd like to admit.

What Software Engineers Should Actually Do

None of this is an argument for despair. Engineers are not obsolete today. The profession is not dying — it is transforming, as it has many times before.

The appropriate response is adaptation, not reassurance-seeking.

System design and architecture — Think about how complex systems fit together, their failure modes, their scalability. AI tools can't do this well. Build that muscle.
Product thinking — Understanding what to build and why, connecting technical decisions to user needs and business outcomes, is something AI cannot derive without human context.
AI orchestration — The engineers who thrive in the next decade won't be the ones who resist AI. They'll be the ones who know how to direct it, evaluate its outputs, and integrate it into systems that actually work.
Domain depth and business understanding — The richer your understanding of a specific problem domain, the more irreplaceable your judgment becomes. Generalist skills are more substitutable than deep expertise.
Human communication — Translating between technical and non-technical worlds, building trust, navigating organizational complexity — these capabilities are not diminishing in value. They're appreciating.

A Balanced but Honest Conclusion

Nobody — and I mean nobody — knows exactly when or how deeply AI will transform knowledge work. The confident doomsayers of 2022 were wrong about the timeline. The confident reassurers of 2025 may be equally wrong about the ceiling.

What we can say with reasonable confidence: AI capabilities are not static. Costs are falling. Competition is intensifying. The models available in 2030 will be substantially more capable than the models available today. And if that trend continues for another decade while costs keep dropping, the economics of human knowledge work will face pressures that today's measured messaging cannot fully anticipate.

Claiming that engineers are completely safe is just as speculative as claiming they'll all be replaced by Tuesday. The honest position is uncertainty — combined with a clear-eyed view of the directional forces at work.

The real question is not whether AI replaces engineers today. The real question is what the world looks like if AI capabilities keep compounding for the next 5 to 10 years while the cost to deploy them keeps falling.

History rarely rewards those who assume technology has reached its limits. The biggest mistake may not be overestimating AI. It may be assuming that today's limitations are permanent.

The Internet Got HTTP. AI Agents Need x402. PayRam Is Building That.

Rohan Kumar — Sun, 05 Apr 2026 15:15:19 +0000

We've spent the last two years talking about what AI agents can do. Nobody is talking about what they can't do — and the answer is surprisingly simple: they can't pay for anything on their own.

The Problem Nobody Is Talking About

Think about what an AI agent actually needs to operate autonomously. It needs to call APIs for real-time data. It needs to purchase compute on demand. It needs to subscribe to services, unlock content, hire other agents, and settle with vendors — all without a human sitting behind a screen approving every transaction.

Now try doing any of that with today's payment infrastructure.

Every payment system we've built assumes a human in the loop. OAuth flows need human clicks. Credit card forms need manual entry. Stripe accounts need a person to sign up, verify identity, and monitor for "unusual activity." The entire financial stack was designed for humans transacting with businesses — not software transacting with software.

One of the biggest unsolved problems of 2026 is exactly this: how can autonomous agents pay for API access without requiring a human to manually enter credit card details or approve every transaction?

This isn't a small friction point. It's a wall. And until it's removed, AI agents aren't truly autonomous — they're just very fast assistants waiting for permission.

x402: The HTTP Status Code That Was Waiting 27 Years

Here's something most people don't know. The HTTP 402 status code — "Payment Required" — has existed since 1997. It was baked into the original HTTP specification as a placeholder for future use. For nearly three decades, it sat dormant because no viable payment protocol existed at the right layer to activate it.

The recent emergence of scalable, low-fee blockchains and the urgent need for autonomous AI agent payments have created the perfect conditions for x402 to finally fulfill the original vision of a native web payment layer.

The way it works is elegant:

An agent requests a resource
The server responds with a 402 status — "this costs money"
The response contains payment details: amount, currency, recipient address
The agent signs a stablecoin payment, attaches the receipt, retries
Resource unlocked. No accounts. No approvals. No humans.

The numbers back the momentum. Since its summer 2025 launch, x402 has crossed 35 million transactions on Solana alone and over 100 million payments across all chains. Cloudflare co-founded the x402 Foundation with Coinbase. Google incorporated it into its Agent Payments Protocol — launching with over 60 partners including Mastercard, PayPal, Visa, and Adyen.

The protocol is real. The adoption is real. The only question is: who owns the infrastructure underneath it?

The Infrastructure Gap — And Why It Matters

This is where most articles stop. They explain x402, celebrate the vision, and move on. But protocols don't run themselves.

x402 tells you how a payment should happen. It doesn't tell you where it settles, who verifies the transaction, or who holds the funds.

In the standard x402 flow, there's an entity called a Facilitator — the party that verifies payment proofs and releases resources. Currently, the default facilitator is Coinbase-hosted, which introduces centralization and identity leakage. x402 also embeds payment data directly into HTTP headers, creating traceable links between web2 metadata and on-chain transactions.

In other words, the payment protocol is open. But the infrastructure running it is not. And for any merchant, developer, or agent operator who's ever had an account frozen, that distinction matters enormously.

Where PayRam Comes In

PayRam acts as your self-hosted facilitator and settlement engine.

When you deploy PayRam, you don't rely on Coinbase's hosted facilitator — you are the facilitator. Funds settle directly into your self-hosted wallet. No third party holds your keys, monitors your transactions, or reserves the right to freeze your account.

PayRam operationalizes the x402 protocol while maintaining a non-custodial architecture where funds settle directly into the merchant's self-hosted wallet — preserving the censorship resistance that is core to the x402 ethos.

But x402 only solves half the problem. It answers how does an agent pay? It doesn't answer who is this agent, and can it be trusted?

That's where ERC-8004 enters the picture.

ERC-8004 is the trust and discovery layer — letting agents find and verify each other. x402 is the payment layer. An agent uses ERC-8004 to prove it's trustworthy, then uses x402 to request payment for its services. They are complementary, not competitive.

PayRam bridges both. It enables a Trustless Agent Escrow contract — where an agent and a user lock funds in a PayRam-powered smart contract. The contract autonomously queries the ERC-8004 Validation Registry, and only when it reads a validation response of TRUE — proving the agent completed the task — does PayRam release the funds.

Trust verified. Payment released. No human required anywhere in that loop.

What This Actually Enables

Stop thinking about payment infrastructure as plumbing. Start thinking about what becomes possible when that plumbing works autonomously.

An AI research agent can purchase real-time data feeds per query — paying fractions of a cent per API call — without a pre-funded account or subscription
An agent marketplace where autonomous buyers and sellers transact 24/7 becomes viable overnight
A SaaS product can charge per inference, per output, per verified result — with no invoicing, no NET-30 terms, no accounts receivable

Standard APIs require creating an account, getting a key, and paying a monthly fee. x402 allows an agent to pay per request instantly — without an account.

This isn't incremental improvement. It's a different economic model entirely.

The Bigger Picture

McKinsey projects that by 2030, the agentic economy could account for between $3 trillion and $5 trillion in global transaction volume. But today's infrastructure is hostile to this future — OAuth flows require human clicks, credit card forms demand manual entry, and data silos block autonomous access.

PayRam is positioning itself exactly at this gap. Not as a crypto payment gateway. Not as a Stripe alternative. But as the sovereign settlement layer for a web where software needs to pay software — at scale, without permission, without a human cosigning every transaction.

The internet got HTTP in 1991. It got HTTPS in the late 90s. The payment layer — the 402 that was always supposed to exist — is arriving now, thirty years late.

PayRam isn't just participating in that moment.

It's building the infrastructure that makes it real.

Learn more at payram.com

My Journey Learning Arbitrum Stylus Through HackQuest Co-Learning Camp

Rohan Kumar — Thu, 19 Mar 2026 16:12:31 +0000

My Journey Learning Arbitrum Stylus Through HackQuest Co-Learning Camp

Three weeks ago, I didn't know what Arbitrum Stylus was. I'd heard the name floating around crypto Twitter, seen a few developer threads, but never really understood why people were excited about "Rust on Ethereum L2s."

Today, after completing the HackQuest Co-Learning Camp for Arbitrum Stylus, I've built smart contracts in Rust, understood the EVM at a deeper level than I thought possible, and fundamentally changed how I think about blockchain development.

This is the story of that journey—the struggles, the breakthroughs, and why I think every serious Web3 developer should be learning Stylus right now.

What Even Is Arbitrum Stylus?

Let me start with the problem Stylus solves.

Traditional smart contract development happens almost exclusively in Solidity. If you want to build on Ethereum, Polygon, Arbitrum, or most EVM chains, you write Solidity. It's the lingua franca of Web3.

But Solidity has limitations:

It's a domain-specific language that only exists for blockchain
Performance is constrained by EVM design decisions from 2015
Gas costs can be prohibitively expensive for complex logic
The developer tooling ecosystem is smaller than mainstream languages
Memory management and optimization are difficult

Arbitrum Stylus changes the game entirely.

Instead of being locked into Solidity, Stylus lets you write smart contracts in Rust, C, or C++—languages with decades of optimization, massive developer communities, and production-grade tooling. These contracts compile to WebAssembly (WASM) and run alongside traditional EVM contracts on Arbitrum.

The key insight: Stylus doesn't replace the EVM. It extends it. You can call Stylus contracts from Solidity and vice versa. It's fully interoperable, but with dramatically better performance and lower gas costs.

When I first read this, I was skeptical. How could you just... run Rust on Ethereum? Wouldn't that break composability? What about security?

The HackQuest camp answered all these questions—but through building, not just reading docs.

Week 1: Wrestling with Setup and Mental Models

The first mission in HackQuest was deceptively simple: set up the Stylus development environment and deploy a "Hello World" contract.

I thought this would take an hour. It took a day.

Not because the tools are bad—they're actually excellent. But because I had to unlearn assumptions about how smart contract development works.

The Mental Shift

In Solidity, you think in terms of:

State variables stored in contract storage
Functions that modify state
Events for logging
Gas optimization through storage patterns

In Stylus (using Rust), you think in terms of:

Ownership and borrowing (Rust's core concepts)
Explicit memory management
Type safety enforced at compile time
Performance optimization through algorithmic efficiency, not just storage tricks

Here's what a basic Stylus contract looks like:

#![no_main]
#![no_std]

use stylus_sdk::{prelude::*, storage::StorageU256};

#[storage]
#[entrypoint]
pub struct Counter {
    count: StorageU256,
}

#[public]
impl Counter {
    pub fn increment(&mut self) {
        let count = self.count.get();
        self.count.set(count + 1);
    }

    pub fn get(&self) -> U256 {
        self.count.get()
    }
}

Compare this to Solidity:

contract Counter {
    uint256 public count;

    function increment() public {
        count += 1;
    }
}

The Solidity version is simpler syntactically. But the Rust version gives you:

Compile-time guarantees about state mutations (&mut self vs &self)
Explicit control over storage reads/writes
Type safety that catches bugs before deployment
Performance optimizations the compiler can leverage

My first breakthrough came when I realized Stylus isn't harder—it's more explicit. Solidity hides complexity. Stylus makes you understand what's actually happening.

Week 2: Building Real Contracts and Understanding Gas

The second week focused on building functional contracts: token standards, simple DeFi primitives, and storage patterns.

This is where Stylus's advantages became undeniable.

The Gas Efficiency Revelation

HackQuest had us build the same contract in both Solidity and Stylus, then compare gas costs. The mission: implement a contract that validates cryptographic signatures and performs complex string operations.

Solidity implementation:

Deployment cost: ~2.1M gas
Execution cost for signature verification: ~85K gas

Stylus implementation:

Deployment cost: ~950K gas (55% cheaper)
Execution cost for signature verification: ~31K gas (64% cheaper)

This isn't a marginal improvement. This is transformative for applications that need complex computation on-chain.

Why the difference?

Solidity compiles to EVM bytecode, which is interpreted at runtime. Every operation has gas costs defined by the EVM spec—costs set years ago based on hardware assumptions that are now outdated.

Stylus contracts compile to WASM, which runs near-native speed. The gas model charges based on actual computational cost, not arbitrary historical pricing.

For developers building:

Complex DeFi protocols with heavy math
On-chain gaming logic
AI/ML inference on-chain
Advanced cryptographic operations

Stylus isn't just better—it makes things economically viable that weren't before.

Week 3: Interoperability and the "Aha" Moment

The final week covered cross-contract calls between Stylus and Solidity contracts.

This is where everything clicked.

I built a DeFi protocol where:

A Solidity contract handled user-facing interactions (because most wallets/frontends expect Solidity ABIs)
A Stylus contract performed the heavy computational logic (pricing algorithms, validation)
The Solidity contract called the Stylus contract for computation, then executed the results

Here's the pattern:

// Solidity contract
interface IStylusValidator {
    function validateAndPrice(uint256 amount) external view returns (uint256);
}

contract DeFiProtocol {
    IStylusValidator validator;

    function executeSwap(uint256 amount) public {
        uint256 price = validator.validateAndPrice(amount);
        // ... rest of swap logic
    }
}

The Stylus contract did the heavy lifting:

#[public]
impl Validator {
    pub fn validate_and_price(&self, amount: U256) -> U256 {
        // Complex validation logic
        // Advanced pricing calculations
        // All running at WASM speed for fraction of gas cost
    }
}

The breakthrough: You don't have to rebuild everything in Rust. You can incrementally adopt Stylus where it matters most—the computationally expensive parts—while keeping familiar Solidity patterns for everything else.

This is how real adoption happens. Not forcing developers to rewrite everything, but giving them a better tool for specific problems.

Challenges and Mistakes I Made

Let me be honest about the hard parts:

1. Rust's learning curve is real.
If you've never written Rust, the borrow checker will frustrate you. I spent hours debugging lifetime errors that would've been runtime bugs in Solidity—but that's actually the point. Better to catch them at compile time.

2. Storage patterns are different.
Solidity's mapping and array structures don't translate directly. Stylus uses different storage primitives that require understanding how EVM storage actually works. This was frustrating initially but made me a better developer.

3. Debugging is harder early on.
Error messages from WASM compilation can be cryptic. The tooling is improving rapidly, but it's not as mature as Hardhat/Foundry yet. I learned to love cargo-stylus's simulation features, but there was a learning curve.

4. Mental model switching.
Going between Solidity's implicit behaviors and Rust's explicit everything requires constant context switching. By week three, this became natural, but week one was mentally exhausting.

Why Developers Should Learn Stylus in 2026

Here's my honest take after three weeks of intensive learning:

If you're building:

High-performance DeFi (DEXs, lending, derivatives)
On-chain gaming with complex logic
Advanced cryptography or zero-knowledge applications
Computational protocols (oracles, data processing)

You should learn Stylus. Not eventually—now.

Here's why:

1. Performance advantages are non-negotiable.
As blockspace gets more expensive and applications more complex, gas efficiency isn't optional. Stylus gives you 10-100x improvements in specific scenarios.

2. Rust is the future of systems programming.
Learning Rust makes you a better developer period. It's used in blockchain (Solana, Polkadot, NEAR), systems programming, cloud infrastructure, and embedded systems. Stylus gives you blockchain-specific Rust experience.

3. Early ecosystem advantage.
Stylus is new. Being an early expert means you're positioned for grants, jobs, and opportunities as adoption grows. The developers who learned Solidity in 2017-2018 had massive advantages. Same pattern here.

4. Composability with existing ecosystems.
You're not abandoning Ethereum. You're extending it. All your Solidity knowledge still matters—you're just adding a more powerful tool.

A Beginner Roadmap for Getting Started

Based on my experience, here's how I'd recommend approaching Stylus:

Phase 1: Foundations (1-2 weeks)

Learn Rust basics (ownership, borrowing, traits)
- Resource: "The Rust Book" (first 10 chapters)
- Don't try to master everything—focus on core concepts
Understand EVM fundamentals
- How storage works
- Gas mechanics
- Contract interaction patterns

Phase 2: Stylus Basics (1 week)

Complete Arbitrum Stylus docs tutorials
Deploy your first contract (counter, simple storage)
Use cargo-stylus for local development
Join HackQuest Co-Learning Camp (seriously, it's structured perfectly)

Phase 3: Build Real Projects (2-3 weeks)

Replicate a simple Solidity project in Stylus
- ERC20 token
- Simple vault
- Basic NFT
Build a hybrid Solidity + Stylus contract
- Use each where it makes sense
Compare gas costs between implementations

Phase 4: Advanced Patterns (ongoing)

Study production Stylus contracts
Contribute to Stylus tooling
Build something novel that leverages WASM performance

My Biggest Wins

Looking back at three weeks:

✅ I built a working DeFi primitive that's 60% cheaper to execute than the Solidity equivalent

✅ I understand the EVM at a level I never did just writing Solidity

✅ I can read and write Rust confidently (not expertly, but functionally)

✅ I have a portfolio project that demonstrates cutting-edge Web3 development

✅ I'm excited about blockchain development again after feeling like everything was just "another fork of Uniswap"

The Future: Why I'm Betting on Stylus

The blockchain industry has a talent problem. We need more developers, but learning Solidity is a barrier—it's a language you can only use for one thing.

Stylus inverts this. Learn Rust, use it everywhere—including blockchain.

As Layer 2s scale and applications become more sophisticated, the performance advantages of WASM-based execution will matter more, not less. Developers will migrate to tools that let them build better products more efficiently.

Arbitrum Stylus isn't just a technical upgrade. It's a strategic positioning for the next era of blockchain development.

Three weeks ago, I was skeptical. Today, I'm convinced this is where serious builders should be focusing.

The HackQuest Co-Learning Camp gave me the structure, community, and hands-on practice to make that transition. If you're reading this and wondering whether to learn Stylus—stop wondering. Start building.

The future of Ethereum isn't just Solidity anymore. And that's a really good thing.

Want to connect? . Let's build the next generation of Web3 together.

Why Stellar Is Built for Micropayments at Internet Scale

Rohan Kumar — Sat, 07 Mar 2026 10:16:06 +0000

The internet's payment infrastructure is broken for small transactions. Try to charge someone $0.05 for an API call, $0.002 for reading an article, or $0.0001 for a single AI inference—and you'll immediately hit the limitations of traditional payment rails.

Credit card processing fees start at $0.30 plus percentage cuts. PayPal has minimum thresholds. Bank transfers cost dollars in fees. Even most blockchains—supposedly built for peer-to-peer value transfer—cannot economically support payments under a dollar due to gas costs and fee volatility.

Yet the digital economy increasingly demands exactly this: frequent, tiny payments for metered usage, consumed resources, and micro-transactions that traditional infrastructure simply cannot handle.

As we move toward an internet where AI agents transact autonomously, APIs charge per request, content creators monetize per-view, and IoT devices settle micro-debts in real-time, the need for true micropayment infrastructure becomes critical. Most blockchain platforms are structurally incapable of supporting this. Stellar, by design, is not.

The Micropayment Use Cases Already Here

The demand for micropayments isn't theoretical—it's emerging across multiple domains:

API monetization. Services like weather data, geocoding, translation, or image processing charge per request. But payment friction forces them into subscription models or prepaid credits because processing thousands of $0.01 transactions through traditional rails is economically impossible.

Content monetization. Writers, podcasters, and video creators want to charge per article, per episode, or per minute watched—not force users into monthly subscriptions. But no payment infrastructure supports charging $0.15 to read a single blog post.

AI and compute services. Language models, image generation, and data processing could charge per inference or per compute second. But without micropayment infrastructure, providers bundle usage into monthly API credits.

IoT and machine-to-machine payments. Connected devices—electric vehicle chargers, bandwidth routers, sensor networks—could settle micro-debts continuously based on actual consumption. A car could pay $0.03 for 10 minutes of charging. A router could pay $0.0005 for bandwidth used. But no settlement layer supports this granularity.

Streaming payments and time-based services. Instead of paying $10 upfront for a service you might use twice, pay $0.0001 per second of actual usage. Music streaming could compensate artists per-second-played. Cloud services could bill per millisecond of compute.

Gaming and virtual economies. In-game microtransactions, digital item trades, or small reward distributions currently require either centralized payment processors (with high fees) or blockchain systems that make $0.50 transactions uneconomical.

The common thread: these use cases require payments smaller than traditional infrastructure can economically process. And the opportunity cost is massive—entire business models remain unbuilt because the payment layer doesn't exist.

Why Traditional Systems Fail at Micropayments

Credit card networks were built for retail transactions measured in dollars, not cents. The merchant fee structure—typically $0.30 + 2.9%—makes a $0.10 transaction cost $0.33 to process. You lose money on every sale.

PayPal, Venmo, and digital wallets have similar economics. Their infrastructure assumes transactions in the dollars-to-hundreds range, not fractional cents.

Banks are even worse. Wire transfers cost $25-50. ACH transactions have minimum thresholds and multi-day settlement. The entire correspondent banking system is built for bulk settlement, not high-frequency micro-transactions.

This isn't a technology problem—it's an economic design mismatch. Legacy payment infrastructure has fixed overhead costs that cannot scale down to micro-transaction levels.

Why Most Blockchains Also Fail

Blockchain was supposed to solve this. Bitcoin's whitepaper literally describes "A Peer-to-Peer Electronic Cash System." But in practice, most blockchain networks cannot support micropayments either:

Ethereum: Gas fees during periods of congestion regularly exceed $5-20 per transaction. Even during quiet periods, fees hover around $0.50-2.00. You cannot economically send $0.10 worth of value.

Bitcoin: Lightning Network improves this significantly, but base-layer Bitcoin transaction fees range from $1-10 depending on network state. Great for large transfers, unsuitable for $0.01 payments.

Solana: While significantly cheaper, fees are still measured in fractions of a cent per transaction—economically viable for some micropayments, but with occasional network instability that creates settlement uncertainty.

Layer-2 solutions: Optimistic and ZK-rollups reduce fees substantially, but introduce bridging complexity, withdrawal delays, and fragmented liquidity. Users must manage which L2 holds their funds and navigate bridging costs.

The fundamental issue: most blockchains use auction-based fee markets or proof-of-work economics that create baseline transaction costs incompatible with true micropayments. When network activity spikes, fees spike with it—making payment costs unpredictable.

For micropayments to work at internet scale, you need infrastructure where the cost of a transaction is less than the value being transferred—and that cost must remain stable regardless of network conditions.

Stellar's Micropayment Architecture

Stellar's design makes sub-cent payments not just possible, but economically trivial:

Ultra-low, deterministic fees. Every operation costs 0.00001 XLM—currently about $0.000004. Sending $0.01, $0.001, or $0.0001 costs the same: four ten-thousandths of a penny. This fee doesn't change based on network congestion, transaction complexity, or payment size.

Fast finality. Transactions confirm in 3-5 seconds with deterministic settlement. No mempool uncertainty, no multi-block confirmation requirements, no waiting for fraud proof windows. Payment either confirms or fails immediately.

No gas mechanics. Users don't need to estimate fees, set priority levels, or worry about transactions failing due to insufficient gas. The fee is fixed and known. Infrastructure builders can calculate exact costs at any transaction volume.

Efficient transaction model. Stellar's ledger architecture and Federated Byzantine Agreement consensus enable high throughput without the computational overhead of proof-of-work or complex proof-of-stake validator economics. This keeps base costs minimal.

Native asset support. Micropayments can happen in any asset issued on Stellar—USDC, custom tokens, or any other value representation—without smart contract overhead or token approval transactions that add costs.

The result: you can economically send a $0.001 payment. The infrastructure cost is $0.000004—0.4% overhead. For a $0.01 payment, infrastructure cost is 0.04%. For a $0.10 payment, 0.004%.

Compare this to Ethereum, where even a $1.00 payment might cost $0.50 in gas during congestion—50% overhead that makes small payments impossible.

Practical Micropayment Workflows

Pay-per-API-call. A weather API charges $0.002 per request. A developer building an app makes 10,000 requests monthly, paying $20 total. On Stellar, the settlement cost for those 10,000 transactions is $0.04. On Ethereum, even at low gas prices, it might cost $50+ in fees—more than the API usage itself.

Streaming content payments. A reader pays $0.0001 per second to read premium articles. After reading for 5 minutes (300 seconds), they've paid $0.03 total. The settlement cost: $0.000004. The writer receives effectively all revenue minus fractional infrastructure costs.

AI agent transactions. Autonomous agents pay for compute resources, API access, or data services in real-time as consumed. An agent might make 1,000 micro-transactions daily—each costing $0.001-0.01 in value. Settlement infrastructure costs $0.004 total regardless of transaction volume.

IoT device settlements. Electric vehicle charging stations settle payments per kilowatt-hour. A 30-minute charging session consuming 15 kWh at $0.15/kWh costs $2.25 total but might be settled as 30 separate minute-by-minute payments of $0.075 each. On Stellar: trivial. On most blockchains: impossible.

Gaming microtransactions. In-game item trades, small reward distributions, or play-to-earn payouts happen continuously in tiny amounts. A player might earn $0.05 for completing a quest. On Stellar, they receive $0.049996 after fees. On Ethereum, the fee might exceed the reward.

The Infrastructure Threshold

For micropayments to work at scale, infrastructure must cross a critical threshold: transaction costs must be negligible relative to transaction value across several orders of magnitude.

If your blockchain can handle $10 payments efficiently but breaks down at $1 payments, you're not micropayment infrastructure. If you can handle $1 but not $0.10, still not there. If you can handle $0.10 but not $0.01—getting closer, but insufficient for many use cases.

Stellar crosses this threshold. You can economically send $0.001 payments. The infrastructure doesn't care whether you're sending $0.0001 or $1,000—the cost is identical and negligible in both cases.

This opens design space that doesn't exist on other platforms. Developers can build business models around per-use pricing, metered consumption, and high-frequency small payments without worrying whether infrastructure costs will consume revenue.

Micropayments as Internet Infrastructure

The shift toward usage-based pricing is already underway. SaaS companies increasingly offer pay-as-you-go models. Cloud providers bill per resource consumed. API services charge per call. Content platforms experiment with microtransactions.

But this shift is constrained by payment infrastructure. Most services must batch small charges into monthly invoices because processing individual transactions is uneconomical.

Blockchain-based settlement can remove this constraint—but only if the underlying protocol is designed for high-frequency, low-value transactions. Most chains were built for DeFi, NFTs, or store-of-value use cases. Micropayments were an afterthought.

Stellar's architecture inverts this priority. The protocol was designed specifically for moving value efficiently—whether that's $1 million in corporate treasury settlement or $0.001 in API micropayments. The infrastructure doesn't distinguish.

As AI agents proliferate, IoT devices become ubiquitous, and internet services shift toward granular usage pricing, micropayment infrastructure transitions from nice-to-have to essential.

The platforms that enable this won't be those with the most speculative activity or the largest TVL. They'll be those where the cost of settlement is negligible—predictable, minimal, and completely independent of payment size.

For internet-scale micropayments, that threshold matters more than any other metric. And Stellar crosses it.

Internet-Native Payroll: Why Global Salary Infrastructure Needs Settlement-First Blockchains

Rohan Kumar — Wed, 25 Feb 2026 08:14:26 +0000

The modern workforce is borderless. A San Francisco startup employs developers in Portugal, designers in Argentina, and customer support in the Philippines. A London consulting firm contracts specialists across three continents. A DAO pays contributors in twenty countries simultaneously.

But payroll infrastructure hasn't caught up. Companies still navigate a patchwork of legacy systems built for domestic employment in an era when "remote work" meant the next state over, not the next continent.

The result: salary payments that take 3-5 business days to settle, foreign exchange spreads of 3-5%, compliance paperwork across multiple jurisdictions, reconciliation headaches at month-end, and infrastructure costs that make paying small amounts or frequent contributors economically painful.

As work becomes genuinely global and internet-native, payroll systems must follow. And that transition requires infrastructure designed for cross-border settlement, not domestic banking rails retrofitted for international use.

The Payroll Problem

Traditional international payroll operates through correspondent banking networks: money moves through multiple intermediary banks, each taking fees and time. A US company paying a contractor in Brazil might see funds route through three banks over four days, losing 4% to FX spreads and wire fees along the way.

This creates several structural problems:

Timing uncertainty. Employees can't predict when salary will arrive. "2-5 business days" might mean Tuesday or Friday, depending on banking hours, intermediary processing, and weekend delays. For workers in emerging markets living paycheck-to-paycheck, this uncertainty creates real financial stress.

High costs for small payments. Fixed wire fees ($25-50) make small payments uneconomical. Paying a $500 contractor invoice might cost $30 in fees—6% overhead. This effectively excludes micro-contractors, part-time contributors, and fractional work arrangements.

Opaque FX pricing. Workers rarely see mid-market exchange rates. Banks and payment processors embed 2-4% markups into currency conversion, sometimes more in exotic corridors. A Philippine contractor paid $2,000 might receive only $1,920 worth of pesos after FX markups.

Multi-currency complexity. Companies with global teams must maintain banking relationships in multiple jurisdictions or route everything through payment providers that charge premium fees for multi-currency support. Treasury teams spend hours each month reconciling payments across systems.

Compliance overhead. Each jurisdiction has different tax withholding rules, labor regulations, and reporting requirements. International payroll providers handle this complexity but charge 10-15% of payroll costs for the service.

No programmability. Traditional payroll systems cannot easily support automated payments, conditional distributions, or dynamic splitting. Everything requires manual processing or expensive enterprise software.

For startups and distributed teams, these inefficiencies aren't minor annoyances—they're structural barriers. The administrative cost of paying ten international contractors can exceed the administrative cost of managing fifty domestic employees.

The Demand for Internet-Native Payroll

The remote work explosion has created new requirements:

Global freelancing platforms—Upwork, Toptal, Contra—need to settle payments across hundreds of countries instantly when work is completed, not days later through banking rails.

DAOs and crypto-native organizations distribute compensation to pseudonymous contributors worldwide, often in multiple assets, requiring infrastructure that doesn't assume KYC'd bank accounts.

Emerging market hiring has accelerated as companies realize talent is globally distributed but compensation expectations vary by location. A Manila-based engineer might prefer PHP salary, while an Argentine designer wants USD stability.

Real-time settlements align better with modern work patterns. Freelancers completing projects want payment immediately, not after multi-day banking delays. Hourly contractors want daily settlement, not biweekly cycles.

Programmatic payroll enables new business models: streaming salaries paid by the second, performance-based bonuses distributed automatically, equity vesting settled on-chain, or milestone payments triggered by oracle data.

These use cases share common requirements: instant global settlement, minimal costs, multi-currency support, and programmable execution. Traditional banking infrastructure cannot provide this. But blockchain-based settlement can—if the underlying protocol is designed for payments rather than speculation.

Stellar as Payroll Infrastructure

Stellar's architecture maps directly to internet-native payroll requirements:

Fast finality. Transactions confirm in 3-5 seconds with deterministic finality. A company can send salary on the 1st of the month and know every employee receives funds within seconds, regardless of location. No waiting for banking hours or intermediary processing.

Predictable, minimal costs. Every transaction costs 0.00001 XLM (roughly $0.000004), regardless of payment size. Paying a $100 contractor costs the same as paying a $10,000 employee—fractions of a cent. This makes micro-payments, frequent settlements, and small contractor payments economically viable.

Native multi-currency support. Stellar treats every asset as a protocol-level primitive. A company can hold USD stablecoin in treasury while employees receive EUR, MXN, BRL, or PHP—all settled in the same transaction batch. No need to maintain accounts in multiple jurisdictions.

Built-in FX routing. Stellar's path payments enable sending one currency while the recipient receives another, with the protocol automatically routing through available liquidity. A US company can send USDC while a Manila contractor receives PHP-backed stablecoin, all settled atomically at transparent market rates.

This eliminates opaque FX markups. The employee sees exactly what exchange rate was used. The employer knows exactly what they paid. No hidden spreads.

Stablecoin integration. Circle's USDC is natively issued on Stellar, providing dollar-denominated settlement without volatility risk. Employees in countries with unstable currencies can choose to receive USD stablecoin rather than local currency—giving them dollarized savings while maintaining instant settlement.

Programmable payments. Stellar supports conditional payments, multi-signature authorization, and time-locked transactions at the protocol level. A company can automate monthly salary distributions, implement approval workflows for large payments, or schedule recurring contractor payments—all without smart contract complexity.

Practical Payroll Workflows

Global contractor payments. A design agency pays fifty freelancers across twenty countries monthly. Using Stellar, they send USDC from treasury to a payment distribution script. The protocol routes payments to each contractor in their preferred currency—EUR, GBP, PHP, MXN—all settled in under a minute for aggregate fees under $0.01.

Compare this to traditional wire transfers: days of settlement time, $30-50 per wire, opaque FX spreads, and manual reconciliation tracking which payments cleared.

Real-time salary streaming. A startup implements per-second salary payments using Stellar's micropayment capabilities. Employees effectively receive salary continuously throughout the month rather than in lump sums. If an employee leaves mid-month, they've already received exact payment for time worked—no accrual calculations or final payment disputes.

This becomes economically viable because transaction costs are effectively zero. Paying someone 720 times per month (every hour) costs $0.003 total in fees.

Multi-asset compensation. A crypto-native company pays employees partially in USDC (stable salary) and partially in company tokens (equity-like incentive). Using Stellar, both assets settle simultaneously in a single transaction. Employees receive one consolidated payment rather than managing multiple incoming transactions from different systems.

Automated compliance. Tax withholding and regulatory reporting happen at the protocol level. A payroll system can automatically split gross salary into net payment (to employee), withholding (to tax authority wallet), and benefits (to insurance provider)—all executed atomically in one transaction.

Emerging market accessibility. A Latin American contractor receives USD stablecoin salary on Stellar, then uses local on-ramps to convert to local currency when needed—getting better exchange rates than receiving wire transfers through local banks. They maintain dollar-denominated savings while controlling exactly when to convert to local currency.

The Competitive Landscape

Several companies already build in this direction:

Bitwage enables employees to receive traditional salary in cryptocurrency, though still dependent on slow banking rails upstream
Rise offers crypto payroll for US companies, focusing on compliance and contractor payments
Request Finance provides Web3-native invoicing and salary infrastructure
Utrust (now part of Elrond) experimented with crypto salary payments before pivoting

But these solutions often layer on top of general-purpose blockchains not optimized for payments, resulting in fee volatility, settlement complexity, or limited multi-currency support. Using Ethereum for payroll means navigating gas mechanics, accepting fee unpredictability, and explaining blockchain concepts to finance teams.

Stellar's payment-first design removes these friction points. A fintech founder building payroll infrastructure on Stellar doesn't need to explain gas estimation to their CFO or build contingency buffers for fee spikes. The infrastructure just works—predictably, cheaply, globally.

Payroll as Settlement, Not Experimentation

The opportunity isn't building "crypto payroll" as a novelty feature for Web3 companies. It's recognizing that global salary distribution is fundamentally a settlement problem—moving value from employer to employee across jurisdictions reliably and efficiently.

Traditional banking systems were built for domestic payments with international capabilities bolted on. They're slow, expensive, and complex for cross-border use because that wasn't the primary design goal.

Blockchain-based settlement inverts this: international payments become the default, with instant finality and transparent pricing. But this only works if the underlying blockchain is optimized for payments rather than treating them as just another application.

As work continues becoming borderless—driven by remote work normalization, global talent competition, and digital-native companies—payroll infrastructure must become internet-native. Not as a futuristic vision, but as practical business necessity.

Companies need to pay global teams efficiently. Contractors need instant settlement. Finance teams need predictable costs and simple reconciliation. Compliance teams need transparent audit trails.

Stellar provides the settlement infrastructure this requires: deterministic fees, instant finality, native multi-currency support, and stablecoin integration. Not as experimental DeFi features, but as production payroll rails.

The future of payroll isn't built on the most popular blockchain or the one with the most speculative activity. It's built on infrastructure designed specifically for moving money globally—fast, cheap, and reliably.

For distributed teams and internet-native companies, that future is already technically possible. The question is how quickly payroll systems catch up to where work already is.

DEV Community: Rohan Kumar

Your AI agent remembers everything. Can it prove any of it?

Building Engram: git for agent memory, on Walrus, Sui and Tatum

Part 1 · The moment that started it

Part 2 · Why we felt we had to build it

Agents crossed a line this year

Five questions nobody could answer

Why existing tools don't solve this

The idea, in one sentence

Part 3 · Who it's for

Four stories that show why it matters

Who doesn't need it

Part 4 · The ideas, in plain language

Episode: what the agent saw

Belief: what the agent concluded

Sleep: how episodes become beliefs

Commit: a snapshot of the mind

Receipt: proof of why

How they connect

Part 5 · The life of one memory

Step 1 · observe: the agent sees something

Step 2 · sleep: it draws a conclusion

Step 3 · commit: it locks in what it knows

Step 4 · decide: it acts, and leaves a receipt

Step 5 · revise: the facts change

Step 6 · verify: anyone can check

And if it ever needs to forget

Part 6 · The architecture

Layer 1 · How you reach Engram

Layer 2 · The Engram engine

Layer 3 · Helper services

Layer 4 · Where trust comes from

What leaves your machine, and what doesn't

What happens during a commit

Part 7 · How the proof works

A fingerprint for the whole mind

Two public anchors for every commit

What verify checks

Part 8 · Forgetting, without rewriting history

Part 9 · Why Walrus, Sui and Tatum

Walrus Memory: where everything lives

Sui: the public clock

Tatum: how Engram reads the chain

What only works because of this stack

Part 10 · The demo: an agent that learned from real money

Watching the agent think: the Mind view

Every memory, encrypted and on Walrus: the Memory view

A history you can't rewrite: the History view

Every decision comes with a receipt: the Receipts view

Then anyone can check it

Check it without trusting us

Part 11 · Debugging an agent's mind

Part 12 · Using it today

In code: the SDK

In the terminal: the CLI

Inside your AI assistant: MCP

On the web: link your agent to a dashboard

Part 13 · What broke, and how we fixed it

Sui JSON-RPC went away

Walrus Memory's embedder went down

The relayer rate-limits each key

LLM free tiers are small

Part 14 · Honest limits

Part 15 · What we shipped, and what's next

Built during the hackathon

Next few months

Further out

What success looks like

Try it

Building an Agentic Fraud Investigation Agent with TigerGraph

The Problem

The Core Idea

Why TigerGraph?

The Case That Made the Graph Useful

Architecture

1. The Investigation Platform

2. The Official Benchmark Pipeline

The Investigation Workflow

Controlled Graph Tools

Evidence Before Reasoning

What `verify` checks