AniLog

Writing Your Own Claude Plugin and Shipping it to the World

2026-04-20T00:00:00Z

Claude Code has a plugin system now. Which means anyone, including you, can bundle up a bit of AI-assisted magic, put a pretty bow on it, and have it installed by strangers on the internet in two commands.

Writing the plugin is the easy part. Getting people to actually install it is the part nobody tells you about.

This post walks through the whole round trip: build a Claude plugin, publish it to GitHub, list it on AgentHub (a community marketplace I built), and see the install from the user side. We’ll do it with a tiny demo plugin so nothing gets in the way of the shape of the thing.

Once you’ve everything set, you can install your plugin like:

/plugin install your-plugin@agenthub

What even is a Claude plugin?

A Claude plugin is a directory. That’s it. A directory with a manifest at .claude-plugin/plugin.json and some combination of:

Skills — markdown files Claude invokes when the task fits
Commands — skills you call explicitly with /plugin-name:command-name
Agents — full subagent definitions
Hooks — run scripts on events like PostToolUse
MCP servers — wire in external tools
LSP servers — language intelligence for Claude

You can include one of these or all of them. The manifest is the glue.

The official docs are excellent and you should keep them open in another tab:

Create plugins → the main guide
Plugin manifest schema
Plugin marketplaces — how distribution works
Skills, Hooks, Subagents, MCP

Now that you’ve acquainted with the basics, let’s build…

Make sure that you got these setup first:

Claude Code installed and you’re logged in. If /plugin doesn’t exist in your session, update or upgrade.
A GitHub account. Your plugin is going to live in a public repo.

We’re building claude-plugin-demo. One skill, called greet. It takes a name, prints an ASCII-art banner of it via figlet (because the CLI doesn’t need to be boring, right?), and follows up with a warm, slightly over-enthusiastic welcome. Nothing fancy. The point is the pipeline, not the payload. Make sure you have figlet installed: brew install figlet, apt install figlet, or equivalent.

Once you’ve got the full pipeline working with a toy plugin, swapping greet for something useful (a PR reviewer, a commit-message writer, a changelog formatter, whatever) is a mechanical exercise.

Lets get started

mkdir claude-plugin-demo cd claude-plugin-demo mkdir -p .claude-plugin skills/greet

Your tree now looks like this:

claude-plugin-demo/ ├── .claude-plugin/ └── skills/ └── greet/

One structural thing the docs call out and everyone gets wrong: only plugin.json goes inside .claude-plugin/. Skills, agents, commands, and hooks all sit at the plugin root. If you nest them inside .claude-plugin/, Claude Code silently ignores them and you spend 40 minutes wondering why. This was my first mistake when I was writing my first publishable skill.

The Manifest

If you’ve shipped anything on a package registry, you already know this shape. A Node package has package.json. A Rust crate has Cargo.toml. A Python project has pyproject.toml. A VS Code extension has package.json with a contributes field. A browser extension has manifest.json. Same idea every time: a small declarative file at a known path that tells the host what this thing is, who made it, what version it’s at, and what surface it exposes.

A Claude plugin’s manifest plays the same role. It lives at .claude-plugin/plugin.json, and Claude Code reads it to figure out your plugin’s name (which becomes the skill namespace), its version (how /plugin update decides there’s something new), its author, and the metadata that marketplaces like AgentHub use to list you. Unlike package.json, it doesn’t declare dependencies or build scripts — the plugin is the source; there’s nothing to compile. And unlike a VS Code contributes block, you don’t enumerate every skill and command here. Claude Code discovers those by walking the directory. The manifest is intentionally thin: identity and metadata, nothing more.

Create .claude-plugin/plugin.json:

{
  "name": "claude-plugin-demo",
  "description": "A tiny demo plugin with one greeting skill. Use it as a template for your own.",
  "version": "1.0.0",
  "author": {
    "name": "Ani",
    "url": "https://blog.anirudha.dev"
  },
  "homepage": "https://github.com/anistark/claude-plugin-demo",
  "repository": "https://github.com/anistark/claude-plugin-demo",
  "license": "MIT",
  "keywords": ["demo", "greeting", "tutorial"]
}

Field-by-field, the ones that actually matter:

name — kebab-case, becomes the skill namespace. Skills get called as /claude-plugin-demo:greet. Pick something you won’t regret in six months.
description — shows up in plugin browsers. Write it like a product tagline, not like an NPM readme.
version — Follow semver. Bump it when you ship.
author.name — attribution. Optional but put it in.

The full schema has a bunch more fields (homepage, icon, settings, commands, agents, skills, etc.). See the reference when you need them.

The Skill

Create skills/greet/SKILL.md:

---
description: Greet a user by name with a figlet ASCII-art banner plus a warm welcome. Use when asked to say hi to someone, onboard a new person, or welcome someone to a project.
---

# Greet

The user wants you to greet "$ARGUMENTS".

Run this command to print an ASCII-art banner of their name:

```sh
figlet "$ARGUMENTS"
```

If `figlet` is not installed, tell the user to install it (`brew install figlet` on macOS, `apt install figlet` on Debian/Ubuntu, `choco install figlet` on Windows) and stop.

After the banner prints, write a short (2–3 sentence) welcome message below it. Be warm. Be slightly over the top. Throw in one genuinely useful offer of help — e.g. "want me to set up your project skeleton?" or "shall I explain the codebase layout?".

Do not include emoji unless the user's name already has one.

A few things to notice:

The YAML frontmatter’s description is what Claude reads to decide whether to auto-invoke the skill. Write it like you’re writing to a very literal coworker. Say what it does AND when to use it. Vague descriptions = skill never gets picked.
$ARGUMENTS captures everything the user types after the skill name. /claude-plugin-demo:greet Priya → $ARGUMENTS = "Priya".
The body is the instruction. Claude treats it as a system prompt for that skill. Be specific about output format.

If you want the skill to never auto-invoke and only fire when the user explicitly calls it, add disable-model-invocation: true to the frontmatter. Worth it for commands where accidental invocation would be annoying.

. ├── .claude-plugin │ └── plugin.json ├── .gitignore ├── LICENSE ├── README.md └── skills └── greet └── SKILL.md

Testing

Don’t publish yet. Run it against Claude Code on your machine first:

claude --plugin-dir ./claude-plugin-demo

Then in the session:

/claude-plugin-demo:greet Priya

Claude should shell out to figlet, print an ASCII-art banner of Priya, then write a warm welcome underneath. Tweak the SKILL.md, run /reload-plugins inside the same session, try again. No restart needed.

If the skill doesn’t show up at all, check:

Your directories live at the plugin root, not inside .claude-plugin/
The manifest parses (paste it into a JSON linter; trailing commas have ended careers)
The skill folder name matches what you’re typing

Validating Skills

“It works on my machine” is not a shipping criterion. Before you push, run your skill through a validator so the frontmatter, metadata, and structure are all sane. I use sutras for this. A small devtool I built for the skill lifecycle: scaffolding, validation, evaluation, and packaging.

Install it:

pip install sutras

Then validate the skill you just wrote:

sutras validate skills/greet

You’ll get back a report on the YAML frontmatter, required fields, description length, naming, and a bunch of quality checks you’d otherwise discover the hard way in someone else’s CI. Add --strict to turn warnings into errors, or --all to sweep every skill in the repo at once. Super useful once a plugin grows beyond one skill:

sutras validate --all --path skills/ --strict

From inside Claude Code (via pi)

If you use pi, sutras ships an extension that exposes /sutras commands directly in-session — validate, list, and inspect without leaving the editor:

pi install npm:sutras

In CI

The same check belongs on every push so a bad merge can’t sneak past. Sutras publishes a reusable GitHub Action:

# .github/workflows/validate-skills.yml
name: Validate Skills
on: [push, pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anistark/sutras@v0
        with:
          path: skills/
          strict: true

Pin to a major tag (@v0) for automatic patch updates, or to an exact release (@v0.4.5) if you want full reproducibility. Either way, the validator runs on every PR and fails the build before AgentHub’s own checks ever see it.

Treat validation the same way you treat linting or typechecking: cheap, local, automated, non-negotiable. If you want the longer argument for why skills deserve a proper lifecycle in the first place, I wrote about it here: Skills, Agents, and the Missing Middle. That post is the “why.” This step is the “how.”

Ready to publish

Time to make this plugin real.

git init git add . git commit -m "chore: init claude-plugin-demo v1.0.0" gh repo create anistark/claude-plugin-demo --public --source=. --push

Add two more files before you call it done:

README.md — what it does, install commands, a usage example. Don’t overthink it.
LICENSE — MIT is the default Sunday vibe. Pick whichever works for you, but pick something.

Tag the release if you want clean semver history:

git tag v1.0.0 git push --tags

At this point your plugin already works. Anyone can install it directly from your repo:

/plugin marketplace add anistark/claude-plugin-demo /plugin install claude-plugin-demo

But asking every user to remember your GitHub handle and add your repo as a one-off marketplace is friction. We can do better.

Meet AgentHub

AgentHub is a community-driven marketplace for Claude Code plugins. I built it because the plugin ecosystem was coming in hot and there was no central place to discover what’s out there.

The design is deliberately boring: your plugin code stays in your own repo. AgentHub holds a catalog of references. You open a PR, we merge it, your plugin shows up when users run /plugin and hit the Discover tab. You keep ownership, you keep your CI, you keep your license. We just do matchmaking.

Users install AgentHub once:

/plugin marketplace add nullorder/agenthub

After that, any plugin in the catalog is one command away:

/plugin install <plugin-name>@agenthub

Right now there are 300 plugins from 73 authors and the catalog is growing fast. Your demo plugin can join that list in the next ten minutes.

Distribute your plugin

Fork nullorder/agenthub on GitHub and clone your fork.

Inside the repo, every plugin is a single JSON file under plugins/. The filename must match the plugin name. So for our demo:

touch plugins/claude-plugin-demo.json

Fill it in:

{
  "name": "claude-plugin-demo",
  "source": {
    "source": "github",
    "repo": "anistark/claude-plugin-demo"
  },
  "description": "A tiny demo plugin with one greeting skill. Great template for your own first plugin.",
  "version": "1.0.0",
  "author": {
    "username": "anistark"
  },
  "category": "other",
  "license": "MIT",
  "tags": ["skills", "tutorial", "demo"]
}

The rules, because rules have consequences:

name — kebab-case, no “claude” / “anthropic” / “official” in the name, must match the filename.
source — usually github with repo: "<user>/<repo>". If your plugin lives on GitLab, is in a monorepo subdir, or ships via npm, there are three other source types. See CONTRIBUTING.md for those.
version — must match the version in your plugin’s own plugin.json. If the two drift, /plugin update lies to users and tells them they’re up to date when they aren’t. Keep them in lockstep.
category — one of: development, testing, devops, security, documentation, productivity, data, design, other. Pick honestly.
tags — required, and must include at least one component type tag so users know what they’re getting: skills, agents, commands, hooks, mcp-servers, lsp-servers, integration, or other. You can add free-form tags after that (languages, frameworks, moods).

One thing worth underlining: don’t edit .claude-plugin/marketplace.json directly. That file is auto-generated from everything in plugins/ after your PR merges. If you touch it, the next build overwrites you and everyone’s annoyed.

Listing on AgentHub

AgentHub is a public repo, so contributions go through the standard GitHub fork-and-PR flow. You don’t have write access to nullorder/agenthub (and neither does anyone outside the maintainers). You open a PR from your own fork.

If you haven’t already, fork nullorder/agenthub from the GitHub UI, then clone your fork locally:

gh repo fork nullorder/agenthub --clone cd agenthub

Or, if you prefer the manual route: click Fork on the GitHub page, then git clone git@github.com:<your-username>/agenthub.git. Either way, add the upstream so you can pull new changes later:

git remote add upstream https://github.com/nullorder/agenthub.git

Now create your manifest file (as in the previous section), then branch, commit, and push to your fork:

git checkout -b add-claude-plugin-demo git add plugins/claude-plugin-demo.json git commit -m "Add claude-plugin-demo" git push origin add-claude-plugin-demo

Then open a PR against nullorder/agenthub:main. A good PR body looks like this:

### Plugin: claude-plugin-demo

A tiny demo plugin with one greeting skill. Meant as a reference template
for people writing their first Claude Code plugin.

- Repo: https://github.com/anistark/claude-plugin-demo
- Version: 1.0.0
- Category: other
- Tags: skills, tutorial, demo

Tested locally with `claude --plugin-dir ./claude-plugin-demo`.

Keep it short. CI will run some validation (JSON schema, naming, required fields). If something’s off, the checks will tell you what. Fix, push, done.

After a merge, the catalog regenerates and the site updates. Your plugin is now browsable by everyone using AgentHub.

Into the wild

Like the beautiful movie goes… with a little Eddie Vedder in background strumming along…Now, it’s time for a real plugin example… I wrote ani-skills, a small collection of agent skills I use every day: a commit message writer, a PR description writer, and an upstream-sync helper. Of course planning on adding more such skills to it. Listed on AgentHub as: ani-skills@agenthub.

Inside the plugin’s own repo, .claude-plugin/plugin.json looks roughly like this:

{
  "name": "ani-skills",
  "description": "Reusable AI agent skills for Claude Code — commit messages, PR descriptions, upstream sync.",
  "version": "0.3.0",
  "author": {
    "name": "Ani",
    "url": "https://blog.anirudha.dev"
  },
  "homepage": "https://github.com/anistark/ani-skills",
  "repository": "https://github.com/anistark/ani-skills",
  "license": "MIT",
  "keywords": ["git", "commit", "pr", "development"]
}

Inside the AgentHub marketplace, plugins/ani-skills.json:

{
  "name": "ani-skills",
  "source": {
    "source": "github",
    "repo": "anistark/ani-skills"
  },
  "description": "Reusable AI agent skills for Claude Code — commit messages, PR descriptions, upstream sync.",
  "version": "0.3.0",
  "author": {
    "username": "anistark"
  },
  "category": "development",
  "license": "MIT",
  "tags": ["skills", "git", "development"]
}

Same name, same version, same description. Two files, one source of truth. This is the version-pairing discipline I was yelling about earlier. Here it is in practice.

The repo layout is the same pattern we’ve been building, just with three skills instead of one:

ani-skills/ ├── .claude-plugin/ │ └── plugin.json ├── skills/ │ ├── commit-msg/ │ │ └── SKILL.md │ ├── pr-msg/ │ │ └── SKILL.md │ └── sync-upstream/ │ └── SKILL.md ├── README.md └── LICENSE

Because it’s installed via the plugin system, each skill is namespaced under ani-skills::

/ani-skills:commit-msg — write a well-structured git commit message from staged changes
/ani-skills:pr-msg — draft a PR title and description from the current branch’s commits and diff
/ani-skills:sync-upstream — sync the current branch with upstream, resolving conflicts interactively

Want to try it right now instead of reading about it? Three commands, live:

/plugin marketplace add nullorder/agenthub /plugin install ani-skills@agenthub /ani-skills:commit-msg

That’s the full round trip on a plugin that’s actually in production. Everything we’ve walked through so far (the manifest, the skill folders, the AgentHub entry, the PR) is what got that plugin on the shelf.

Using Plugin

This is the payoff. Imagine someone (a friend, a stranger, your future self) wants to use your plugin.

They open Claude Code. They do this once, forever:

/plugin marketplace add nullorder/agenthub

Then any time they want to install something:

/plugin

That opens the plugin browser. They tap Discover, find claude-plugin-demo, tap install. Or, if they’re terminal-pilled and know the name:

/plugin install claude-plugin-demo@agenthub

Three seconds later:

/claude-plugin-demo:greet Ani

Claude runs figlet on their box, prints a chunky ASCII banner of the name, and writes a warm welcome underneath. Your plugin, running on someone else’s machine, doing the thing you wrote. Satisfying.

Shipping Updates

Your plugin is not a fossil. You’ll want to ship v1.1.0, v1.2.0, v2.0.0, and so on…

The update flow is a two-step because AgentHub pins to versions explicitly:

Ship in your own repo. Make your changes, bump version in .claude-plugin/plugin.json (say, to 1.1.0), commit, push, tag.
Open a PR to AgentHub updating the version field in plugins/claude-plugin-demo.json to match.

Both versions must match. If your source repo says 1.1.0 but the AgentHub entry still says 1.0.0, then /plugin update claude-plugin-demo@agenthub will tell users they’re on the latest version. They won’t be. They’ll be annoyed. Don’t do that.

If you’re only changing metadata (description, tags, category) and not shipping new plugin behavior, no version bump needed. Just edit the file in plugins/ and open a PR.

On the user end, pulling the latest:

/plugin marketplace update agenthub /plugin update claude-plugin-demo@agenthub /reload-plugins

Users can also update using by simple going in /plugin and browsing through installed plugins and clicking on Update like:

Do not forget to run /reload-plugins or reload your claude code session for the effect to take.

A few things I learned the hard way

Skill descriptions are a product spec. If Claude doesn’t reliably invoke your skill at the right moment, the description is almost always the culprit. Be concrete about trigger conditions. “Use when the user asks to review a PR, check code quality, or audit a diff” beats “code review skill”. The description is what Claude reads to decide whether to reach for your skill. Treat every word like it’s going on the back of a box.

Do not nest anything inside .claude-plugin/. This is the #1 bug report. Only plugin.json lives in .claude-plugin/. Everything else (skills/, agents/, hooks/, commands/, .mcp.json, settings.json) sits at the plugin root. If you put skills/ inside .claude-plugin/skills/, Claude Code silently ignores it, your skill never loads, and you burn an afternoon wondering why /reload-plugins does nothing.

Version drift is the silent killer. The version in your plugin’s own plugin.json and the version in plugins/<your-plugin>.json on AgentHub must match. If they drift, /plugin update tells users they’re on the latest version when they are emphatically not. You pushed v1.2.0 to your repo, bumped your manifest, tagged it, blogged about it, but forgot to open the AgentHub PR. Nobody gets the update. Nobody tells you. You just slowly gather confused issues.

YAML frontmatter will humble you. The YAML block at the top of SKILL.md is strict. Trailing whitespace, tabs instead of spaces, unquoted colons in descriptions: any of these can make the whole skill invisible. When a skill isn’t loading, check the frontmatter parses as YAML before you suspect anything else.

The skill character budget is a real constraint. Claude Code injects plugin skills into the system prompt with a default cap of about 15,000 characters. On a marketplace like AgentHub with 300+ plugins, if users install aggressively, some skills get silently truncated. Users can fix it by setting SLASH_COMMAND_TOOL_CHAR_BUDGET=30000 in their shell profile. Worth mentioning in your README if your plugin depends on long skill descriptions. Also a good argument for keeping your own skill descriptions tight.

/reload-plugins is not a magic wand. It reloads skills, agents, hooks, MCP servers, and LSP servers within a session. It does not always pick up changes to plugin.json itself or to settings.json. When you’re editing the manifest, restart the session. When you’re editing skill bodies, /reload-plugins is fine.

$ARGUMENTS is literal string substitution. It’s not parsed, not validated, not escaped. If a user passes "hi; rm -rf /", your skill just sees that text. Which is fine for skills that only send it to Claude as context, but if your skill runs bash (via hooks or scripts) and interpolates $ARGUMENTS directly, that’s a shell injection waiting for a bad day. Quote aggressively. Or better, use jq to parse hook input on stdin rather than threading args through the shell.

Namespacing is your friend. /claude-plugin-demo:greet looks verbose the first time you see it. After your fourth plugin, when you realize three of them shipped with a /hello, you’ll thank the designers. Do not try to fight the namespace by naming your plugin h to keep invocations short. Your future self will hate you.

Name your plugin like you’re stuck with it. Renaming after launch is painful. Users have it installed under the old name, AgentHub’s entry is keyed to the name, your docs reference the name. And on AgentHub, the name must be unique across the whole catalog. Check the plugins directory before you commit to one. If you pick something already taken, the PR gets rejected and you start over.

License and README are not optional. AgentHub’s contributing guide requires both in your plugin repo. This catches people out constantly. A five-line MIT license and a README with install commands plus one usage example is the minimum. Do it before the PR, not after.

Don’t ship secrets. If your plugin includes MCP server configs or hooks that call external APIs, resist the urge to hardcode tokens into .mcp.json or hook scripts. Use environment variables and document what the user needs to set. The moment your plugin is popular, your hardcoded key is being lifted into a hundred other users’ setups.

Platform compatibility bites hook authors. Bash one-liners in hooks.json work great on your Mac. They die silently on a user’s Windows machine, or on a minimal Linux container without jq installed. If your plugin is going to a general audience, either write hooks in something portable (Node, Python with a shebang) or list the required binaries in your README.

Read one real plugin before writing yours. The AgentHub plugins/ directory has 300 live examples. Clone a few source repos that do what you’re aiming for. Steal structure. A good reference saves more time than any doc page.

Add the badge. If your plugin ships on AgentHub, drop this in your README:

[![AgentHub](https://agenthub.nullorder.org/badge.svg)](https://agenthub.nullorder.org)

Helps discoverability, helps the marketplace, helps other builders find it.

That’s it!

Claude plugins are genuinely one of the more pleasant extension points I’ve built against in a while. The manifest is small, the local dev loop with --plugin-dir is fast, and the distribution story through a marketplace like AgentHub is two JSON files and a PR.

The era where “build a developer tool” meant shipping an npm package, a binary, a VS Code extension, and a config schema at the same time isn’t over, but it’s contracting. Now you can ship a folder.

If you end up building one, list it on AgentHub. If you hit a wall, the AgentHub Discord is where the plugin authors hang out.

Now go ship something.

References

Demo repo — anistark/claude-plugin-demo
Real plugin on AgentHub — anistark/ani-skills
AgentHub — agenthub.nullorder.org · source · contributing guide
Official Claude Code plugin docs — Create plugins · Manifest schema · Marketplaces · Discover and install
Related reading — Skills · Hooks · Subagents · MCP

N Reviewers Walk Into a PR...

2026-04-02T00:00:00Z

A Story You’ve Lived

It’s 4:47 PM. You open a pull request. It touches 12 files across 3 directories. CI is green. You tag one reviewer (the person who happens to be online) and close your laptop.

Three days later, a bug makes it to production. Your reviewer missed a subtle interaction between two of those 12 files. Not their fault. They were one human reading a diff the size of a short story. In hindsight, a second pair of eyes would’ve caught it in five minutes.

Sound familiar? Yeah, me too.

The question “how many reviewers does this PR actually need?” is one every engineering team answers by vibes. Small PR? One reviewer. Massive PR? Also one reviewer, because nobody wants to be that person who requests three reviews on a Friday afternoon.

Here’s the thing: vibes don’t scale. Teams grow. Codebases get gnarlier. PRs stack up. And the cost of under-reviewing compounds silently… right up until it very loudly doesn’t.

The Tools Available (And Why They Fall Short)

GitHub gives you a decent toolkit for review workflows:

Branch protection rules: require a minimum number of approvals. But it’s a flat number. A one-line typo fix and a 2000-line refactor both need… 2 approvals? Really?
CODEOWNERS: auto-assigns reviewers based on file paths. Tells you who, not how many. Great at “Alice owns the frontend” but useless at “this PR is big enough to need Alice and Bob.”
actions/labeler: GitHub’s official labeling action. Labels PRs by file paths and branch names (frontend, docs, feature). Super useful, but it has zero concept of change size or review effort.

None of these answer the fundamental question: for this specific PR, with these specific changes, how many humans should look at it?

Enter: PR Reviewer Labeler

So I built pr-reviewer-labeler, a GitHub Action that looks at every PR and figures out the ideal number of reviewers. Automatically. No vibes required.

Here’s what it does:

Counts total lines changed (additions + deletions)
Optionally weighs different file types differently (because 100 lines of tests ≠ 100 lines of auth middleware)
Maps the result against configurable thresholds
Slaps a label on the PR (reviewers: 2) and drops a summary comment

Think of it as a bouncer for your PR queue. “This PR is a 500-liner touching core auth? Yeah, you’re gonna need at least 3 reviewers. Next!”

Zero-Config Setup (Seriously, It’s This Easy)

name: Reviewer Labeler
on:
  - pull_request_target

jobs:
  label:
    permissions:
      contents: read
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - uses: anistark/pr-reviewer-labeler@v1

That’s it. Out of the box, it uses these defaults:

Lines Changed	Reviewers You’ll Get
< 50	1 (quick glance)
50-199	1 (solid read)
200-499	2 (buddy system)
500-999	3 (bring friends)
1000+	4 (all hands)

Every PR gets labeled and commented. No config files to maintain. No YAML rabbit holes. Just plug and play.

Your Team, Your Rules

Of course, a team of 3 doesn’t need the same scale as a team of 20. Tune the thresholds to your taste:

- uses: anistark/pr-reviewer-labeler@v1
  with:
    thresholds: |
      - lines: 30
        reviewers: 1
      - lines: 150
        reviewers: 2
      - lines: 400
        reviewers: 3
      - lines: 800
        reviewers: 4

Not All Lines Are Born Equal

Here’s where it gets fun. A 500-line PR that’s mostly test files? Probably fine with 2 reviewers. A 500-line PR rewriting your payment processing? You might want the whole team in the room.

File-type weighting lets you express this:

- uses: anistark/pr-reviewer-labeler@v1
  with:
    file-weights: |
      - glob: "**/*.test.*"
        weight: 0.5
      - glob: "**/*.md"
        weight: 0.25
      - glob: "src/core/**"
        weight: 1.5

Translation:

Tests count at half. Important, but rarely where the sneaky bugs hide
Docs count at quarter. A README typo doesn’t need a 3-person review committee
Core source counts at 1.5x. This is where you want extra eyeballs

The action calculates both raw and weighted line counts, so you always see the full picture.

What Happens Under the Hood

For the curious (I see you), here’s the flow:

Fetch changed files: hits the GitHub API to get every file in the PR with its additions and deletions
Weigh the lines: each file gets matched against your glob patterns. Match found? Multiply by the weight. No match? Weight of 1.0. Business as usual
Pick the reviewer count: walks through your thresholds (sorted lowest to highest) and finds the right tier
Label the PR: removes any stale reviewer labels from previous runs, applies the fresh one. Your PR always shows the current recommendation
Drop a comment: posts a clean summary table. If it already commented before, it updates the existing one. No spam. No duplicates

Push more commits? The label and comment update automatically. It’s fully idempotent, a fancy way of saying “it won’t make a mess.”

Wire It Into Your Workflow

The action exposes outputs you can chain into other steps:

steps:
  - id: reviewers
    uses: anistark/pr-reviewer-labeler@v1

  - if: steps.reviewers.outputs.reviewer-count >= 3
    run: echo "Big PR detected. Maybe consider splitting this one up."

Available outputs: reviewer-count, total-lines, weighted-lines, and label. Build whatever automation you want on top.

Best Friends With actions/labeler

This isn’t a replacement for actions/labeler. It’s the other half of the story. They answer different questions:

Action	Answers	Example Labels
`actions/labeler`	What changed?	`frontend`, `docs`, `feature`
`pr-reviewer-labeler`	How much changed?	`reviewers: 2`, `reviewers: 3`

Run them together:

steps:
  # What changed?
  - uses: actions/labeler@v6

  # How much changed?
  - uses: anistark/pr-reviewer-labeler@v1

Now a PR labeled frontend + reviewers: 1 paints a very different picture than frontend + reviewers: 3. Context at a glance.

The Roadmap (a.k.a. “I Have Ideas”)

This is v1. It handles the core job well: sizing PRs and recommending reviewer counts. But I’m just getting started.

CODEOWNERS Integration

Right now it tells you how many. Next up: who. Imagine the action reading your CODEOWNERS file and suggesting “This PR needs 2 reviewers: @alice (owns src/auth/) and @bob (owns src/api/).” That’s the dream.

Complexity Scoring

Line count is a solid start, but it’s not the whole story. A 200-line change in one file hits different than 200 lines scattered across 15 files in 8 directories. I want to factor in:

How many directories the PR touches
New files vs edits to existing ones
Whether the change spans architectural layers (frontend + backend + infra = buckle up)

Auto-Request Reviewers

The endgame: don’t just suggest reviewers. Assign them. Pick from a configured pool, skip the PR author, respect existing assignments. Full automation, zero friction.

All of these are tracked as open issues on GitHub.

I built this to scratch my own itch, but I know every team’s review culture is different. Maybe you need reviewer recommendations based on commit count, not line count. Maybe you want Slack notifications when a PR needs 3+ reviewers. Maybe you have an idea I haven’t thought of yet.

I’d love to hear it.

Try it out: install from the GitHub Marketplace or just add anistark/pr-reviewer-labeler@v1 to your workflow
Open an issue: feature requests, bug reports, wild ideas, all welcome at github.com/anistark/pr-reviewer-labeler/issues
Send a PR: the codebase is small, TypeScript, well-tested, and MIT licensed. Jump in
Star the repo: if you think this should exist, let me know with a star. It helps others find it too

Because no PR should go under-reviewed just because someone didn’t want to bother a third person on a Friday.

Software Without Pause

2026-03-28T00:00:00Z

Move fast and break things. That was the old motto. Now, things break even if you stand still.

A founder I know spent six months building an AI writing product. Good team. Real traction. Paying users. Then one Tuesday morning, a foundation model company dropped a feature that did the same thing, for free, baked into a product with 100 million users.

Six months of work. Obsolete by lunch.

This isn’t a cautionary tale. It’s the new normal. And the uncomfortable truth is that almost every business rulebook we’ve inherited was written for a world that no longer exists.

A new model every few months. Then every few weeks. Then every few days. New startups, new products, new announcements every other day. The ground beneath every company, whether you’re building with AI or just building near AI, is shifting faster than anyone’s planning cycle can keep up with.

Just checkout this article about everything claude team shipped in 52 days.

So here’s the question worth sitting with: if the old rules are dead, what replaces them?

The Rulebook That Got Us Here

For decades, building a technology company followed a recognizable script.

You found a market gap. You raised money. You hired engineers. You built a product over 12 to 18 months. You launched. You iterated based on feedback. You scaled. If things went well, you raised more, hired more, built more.

The whole system was calibrated for a world where change was fast, but predictable. You could forecast quarters. You could define a two-year roadmap and actually execute against it. Competitive advantages were durable enough to defend: your data moat, your distribution, your engineering team, your brand.

Y Combinator’s early doctrine, Paul Graham’s essays, the Lean Startup methodology, Blitzscaling… all of it assumed that the competitive landscape, while intense, moved at a pace you could plan around.

That assumption held for a long time. It doesn’t anymore.

A Pattern We’ve Seen Before

If you zoom out, this moment starts to feel familiar.

When James Watt patented the improved steam engine in 1769, it took nearly 60 years before railways connected British cities. The first factories appeared in the 1780s. Labor laws didn’t catch up until the 1830s. An entire generation was born, lived, and died inside just the first act of the Industrial Revolution.

The engine didn’t just make factories faster. It moved populations. Manchester went from a town of 25,000 to a city of 300,000 in under a century. New social classes formed. The concept of a “job” as we know it, showing up to a place, doing defined work, getting paid by the hour, was invented during this period. Entire ways of living were rewritten. But it unfolded over decades. Generations. Slow enough that society could metabolize the change, even if painfully.

The businesses that thrived weren’t the ones that built the best steam engine. They were the ones that understood what steam meant: that geography was no longer a constraint on production. The cotton mills of Lancashire didn’t win because they had better machines. They won because they reorganized everything, supply chains, labor, logistics, around what steam made possible.

Then came the internet.

Information began to move at near-zero cost. But even the internet’s disruption had a tempo you could follow. Amazon was founded in 1994 and didn’t turn a consistent profit until the mid-2000s. It took Netflix a decade to pivot from DVDs to streaming. The iPhone launched in 2007, but the mobile-first economy didn’t fully mature until the mid-2010s. Twenty to thirty years of runway. Slow enough for companies to adapt. Slow enough for people to re-skill.

The winners of the internet era weren’t the ones who built the best websites. They were the ones who understood what near-zero distribution costs meant: that you could reach everyone, that the marginal cost of serving one more customer approached zero, that network effects would create winner-take-all dynamics. Amazon, Google, Facebook didn’t just use the internet. They built business models that only made sense because of the internet.

Now compare that to what leaders like Jensen Huang are pointing at when they describe AI as the “Intelligence Revolution”: a shift not in muscle or information, but in cognition itself.

GPT-3 arrived in mid-2020. By 2023, AI was writing legal briefs, generating production code, and composing music that charted. By 2025, autonomous agents were shipping features, debugging pipelines, and running customer support at scale. That’s not a 30-year arc. That’s 5 years from “interesting demo” to “reshaping industries.”

The pattern is the same. Every great technological shift creates a window where the old rules stop working and the new ones haven’t been written yet. The businesses and people who figure it out during that window are the ones who define the next era.

But the timeline has collapsed. The window is narrower than ever. And we’re standing in the middle of it right now.

This pace of transformation is insane, if not for the fact that we’re living this life right now. It would sound like science fiction if you read it in a book ten years ago. But here we are, watching entire product categories get created and destroyed in the time it used to take to finalize a roadmap. The speed isn’t theoretical. It’s Tuesday morning. It’s the notification you just got about another launch, another model, another startup that didn’t exist last week doing what took your team a quarter. We don’t get the luxury of processing this from a distance. We’re inside the blast radius, building while the ground shifts, and somehow that’s just… the job now.

When Intelligence Became a Primitive

The real shift isn’t that software got faster. Or that products ship more frequently. Those are symptoms.

The deeper thing that happened is that intelligence itself became programmable.

For most of history, intelligence was a constraint. You could hire it, train it, organize it, but you couldn’t instantiate it on demand. Every company in history, no matter how wealthy, was bottlenecked by the number of smart people it could recruit, retain, and coordinate. That’s why org charts exist. That’s why management is a discipline. The entire machinery of corporate structure was invented to organize scarce cognition.

Now you can spin up intelligence like a container. Need legal analysis? Call an API. Need code review at 3am? It’s already running. Need to evaluate 10,000 customer support tickets for sentiment? That’s a five-minute job now, not a six-week project.

And once intelligence becomes a primitive, like storage, compute, or bandwidth before it, everything built on top of it changes.

This is the part that most businesses haven’t fully internalized. We’ve had decades of strategy built around the assumption that smart human labor is the bottleneck. Hiring plans. Training programs. Talent wars. Retention packages. Entire industries (consulting, outsourcing, recruiting) exist because human cognition was scarce and expensive.

What happens to all of that when cognition becomes abundant?

Products are no longer bundles of features. They are expressions of capability. Notion went from a note-taking app to something that drafts, summarizes, and connects your thinking. Figma added AI and the canvas started suggesting layouts. Cursor and Claude Code turned the code editor from a place where you type into something that builds alongside you, scaffolding entire features from a description, catching bugs before you do, refactoring with an understanding of your codebase.

And that raises a question (brought up by a friend just today in a discussion) that would have sounded absurd two years ago: why pay for an editor when you can pay for the agent? The editor, the IDE, the interface, those used to be the product. Now they’re becoming the shell around the thing that actually does the work. Cursor, VS Code with Copilot, Zed, they’re all positioning as agent-first environments, because they’ve recognized the shift. The value isn’t in syntax highlighting or file management anymore. It’s in the intelligence layer that understands your intent and acts on it. The editor is becoming a viewport into an agent’s workspace, not the workspace itself. As Andrej Karpathy put it, “The hottest new programming language is English,” and if that’s true, the tool you need isn’t a better text editor. It’s a better thinker.

We are moving from software that executes instructions to systems that participate in outcomes. And every business built on the old assumption, that value comes from organizing human intelligence efficiently, needs to rethink its foundations.

The Old Guard vs. The New Movement

You can already see two very different responses playing out.

The old guard is trying to absorb AI into their existing framework. They’re adding “AI features” to existing products. They’re hiring “AI teams” within traditional org structures. They’re running 18-month transformation programs. They’re treating AI like a tool to bolt on, not a force that changes the shape of the game itself.

And then there’s the new movement.

Pieter Levels runs multiple profitable products, mostly solo. Andrej Karpathy left OpenAI and started building and shipping educational tools on his own. Indie hackers are launching SaaS products in a weekend that would have taken a small team six months two years ago. The “weekend project” has become a legitimate go-to-market strategy.

What once required teams of engineers, months of development, and layers of coordination can now, in many cases, be prototyped by a single person in days. Not because problems got easier. Because leverage exploded.

A single developer with good taste and an AI assistant now has the output capacity of a small team. Not in theory. In practice. Right now. AI is acting as a force multiplier on every layer of the stack: writing code, generating designs, conducting research, even helping with strategic thinking.

Meanwhile, consider what’s happening to the incumbents. In 2022, the conventional wisdom was that AI couldn’t write reliable code. By mid-2024, Devin launched as the “first AI software engineer” and every tech company scrambled to respond. By 2025, AI-assisted coding was standard practice at most startups. Companies that spent 18 months building traditional developer tools watched their market assumptions evaporate in a quarter.

Jasper raised $125M to build an AI writing tool, then watched OpenAI launch ChatGPT and obliterate their moat in weeks. Stability AI raised hundreds of millions, then struggled as open-source alternatives and platform-native features caught up. The old thinking says your moat is your data, your distribution, your team. But when a foundation model company can replicate your core value proposition as a feature update on a Tuesday afternoon, that moat is a puddle.

Here’s the irony: it used to be that bigger companies moved slowly. That was the feature of being a startup. You found the gap between what a large incumbent knew it should build and how long it took them to actually build it. That gap was your runway. Steve Blank, the godfather of lean startup methodology, built his entire framework around this asymmetry: startups win not by outspending incumbents, but by outmaneuvering them while they’re stuck in committee. Clayton Christensen’s The Innovator’s Dilemma documented the same pattern across decades of industry: big companies see the disruption coming and still can’t move fast enough because their own success holds them hostage.

But AI has collapsed that gap from both directions. The big companies are moving faster, shipping AI features at startup speed because the cost of experimentation has plummeted, and the small companies are discovering that their nimbleness advantage has shrunk because everyone can move fast now. When Google can prototype and ship an AI feature in weeks, and a solo founder can do the same in days, the old “big company slow, startup fast” playbook stops being a reliable edge. The new gap isn’t speed of execution. It’s speed of insight, seeing what to build before anyone else does.

Capabilities change faster than planning cycles. Competitors appear overnight. Entire markets shift direction between board meetings.

The New Economics

Every great technological shift reshapes economics by making something abundant that used to be scarce. Understanding what becomes cheap is the key to understanding what becomes valuable.

Factories made physical production cheap. A shirt that once took a tailor days could be stamped out in minutes. The value shifted from the craftsman’s hands to the factory owner’s capital. The people who understood this built empires. The ones who kept thinking in terms of craftsmanship got outscaled.

The internet made distribution cheap. Sending information across the world went from expensive (fax machines, postal mail, phone calls) to effectively free. The value shifted from owning distribution channels to creating things worth distributing. The people who understood this built Google, YouTube, Spotify. The ones who kept thinking in terms of distribution gatekeeping (newspapers, record labels, broadcast networks) spent two decades in decline.

AI is making thinking cheap.

Analysis that required a team of consultants and six weeks? An afternoon. Code that needed a senior engineer? A well-written prompt. A market research report? Minutes, not months.

And when thinking becomes abundant, value shifts again. It moves away from doing the work and toward deciding what work matters. Strategy over execution. Curation over creation. Asking the right question over computing the answer.

This is economics 101 playing out in real time: when supply explodes, price drops. The supply of cognitive labor is exploding. Which means the premium falls on the things AI can’t easily replicate: taste, judgment, conviction, and the willingness to make a call when the data is ambiguous.

The founders and companies that understand this are already reorganizing around it. They’re not asking “how do we use AI to do what we already do, faster?” They’re asking “what becomes possible now that cognition is cheap?” Those are fundamentally different questions, and they lead to fundamentally different businesses.

The Recursive Engine

Perhaps the most unsettling part of this shift, and the reason it feels so different from anything before, is how recursive it is.

AI is not just helping us build products. It is helping us build better systems for building products. Which then accelerates how fast the next generation of products can be created. Which generates more data. Which makes AI better. Which…

You see where this is going.

It’s already happening concretely. AI models are being used to generate synthetic training data for the next generation of AI models. AI coding assistants are being used to write the code for better AI coding assistants. Anthropic used Claude to help build Claude. The tool is improving the toolmaker.

Each cycle shorter than the last. Each iteration more powerful.

Steam engines didn’t build better steam engines. The printing press didn’t write better books. The internet didn’t architect a better internet. But AI is actively involved in making AI better. That’s a fundamentally different kind of feedback loop, one that doesn’t just compound, but accelerates its own compounding.

For businesses, this means the competitive landscape isn’t just changing fast. It’s changing faster every quarter. The pace of disruption itself is accelerating. A strategy that was brilliant six months ago might be irrelevant today, not because it was wrong, but because the world it was designed for no longer exists.

Not just change, but change that gets better at changing.

Rethinking the Fundamentals

So if the old rules are dead, what does the new approach look like?

It’s still being written. But some patterns are emerging from the founders and companies that seem to be getting it right.

Think in weeks, not quarters. The planning horizon has collapsed. Companies that thrive in this environment are running rapid experiments, not executing against 18-month roadmaps. They ship something, learn from it, and adjust, often within the same week. The question isn’t “what will we build this quarter?” It’s “what can we learn this week?”

Optimize for learning velocity, not output. The old metric was shipping speed: how fast can we build and launch? The new metric is learning speed: how fast can we understand what’s changing and adapt to it? The companies that look like research labs with a revenue model are outperforming the ones that look like traditional execution machines.

Stay close to the frontier. In a world where foundation model capabilities change every few weeks, the biggest risk isn’t building the wrong thing. It’s building the right thing on yesterday’s assumptions. The founders who spend time understanding what the latest models can actually do, not what the marketing says, but what they can do in practice, have an enormous edge over those who treat the model as a black box.

Build for disposability. This sounds counterintuitive, but the best companies in this environment aren’t building cathedrals. They’re building things they’re prepared to throw away and rebuild when the underlying capabilities shift. The cost of rebuilding has dropped dramatically. The cost of being stuck with the wrong architecture hasn’t.

Leverage over headcount. The old logic said: to do more, hire more. The new logic says: to do more, multiply what you have. A small, sharp team with strong AI leverage can outpace a team ten times its size. The competitive advantage is no longer in the number of people you have, but in how much each person can do.

Judgment is the moat. When execution is cheap, the differentiator is knowing what to execute on. Taste. Strategy. The ability to read the landscape and make a call. The premium isn’t on building anymore. It’s on deciding what to build.

Getting Ahead of the Curve

Every generation believes it is living through unprecedented change. Most of them are wrong.

This time feels different. And I know, that’s exactly what someone living through any era would say. But consider the structural argument: every previous revolution amplified something external to cognition. Muscles. Movement. Communication. The thing doing the thinking about the revolution, the human mind, remained unchanged. It was always the constant in the equation.

For the first time, the variable is the mind.

The Industrial Revolution gave us machines that amplified our bodies. The internet gave us systems that amplified our communication. AI is giving us something far more powerful: systems that amplify our minds. And once the thing that drives progress is itself being accelerated, the pace doesn’t just increase. It escapes.

Getting ahead of the curve doesn’t mean predicting the future. Nobody can do that right now, and anyone who claims otherwise is selling something. It means building the capacity to respond faster than everyone else.

Arie de Geus, who studied corporate longevity at Shell, wrote that “the ability to learn faster than your competitors may be the only sustainable competitive advantage.” He wrote that in 1988. It’s never been more true than right now.

The founders who win won’t be the ones who made the best prediction about where AI is heading. They’ll be the ones who built organizations, products, and habits of mind that can absorb whatever comes next without breaking.

Because when everything else is moving (the models, the tools, the platforms, the expectations, the economics), the only way to win is to move with it.

And honestly? That’s the exciting part. We’re not watching this revolution from the outside. We’re building inside it. Every day. The tools are better than yesterday. The possibilities are wider than last week. And the thing we ship tomorrow will be built on capabilities that don’t exist yet today.

Software without pause. Building without pause.

That’s not a warning. That’s an invitation.

The Missing Playbook for AI Agents

2026-03-17T00:00:00Z

Recently I went to an AI conference and saw dozens of people demo their agents. Agents that could search the web, summarize documents, write code, book meetings, deploy to staging, you name it. The demos were impressive. But every time someone in the audience pushed back with a slightly unexpected question or asked the agent to chain two tasks together, things fell apart. Hallucinated tools. Made-up API arguments. Confident reports of success when nothing had actually happened.

These weren’t hobbyists. These were solid engineers, people who know how to build reliable backend systems, design clean APIs, write thorough tests, and deploy with confidence. But the moment they started building agents, all of that discipline vanished. It was back to trial and error, vibes, and “let me tweak this prompt one more time.”

Walking out of that conference, something crystallized for me:

We don’t have a tooling problem with agents. We have a methodology problem.

Because an agent is not magic. It’s just an app where the control flow is partially owned by an LLM. And we already know how to build apps.

The Core Parallel

If you’ve built backend systems, you already understand agents. You just don’t realize it yet.

Building Apps	Building Agents
Frontend / UI	User Input / Chat Interface
Backend Logic	LLM Reasoning
REST/GraphQL APIs	Tools (functions the LLM can call)
Database	Memory (short-term and long-term)
Event Loop / Request Lifecycle	Agent Loop
Logs & Monitoring	Traces & Evals
Error Handling & Retries	Guardrails & Fallbacks

The mapping might not be perfect, but it’s close enough to be useful. Every hard-won lesson from building distributed systems (separation of concerns, graceful degradation, observability, testing) applies directly to agents.

The problem is that most people treat agent-building as a fundamentally new discipline. It isn’t. It’s systems engineering with a non-deterministic component in the middle.

Designing an Agent = Designing a System

When you start a new backend service, you don’t jump straight into code. You ask:

What’s the user goal?
What are the flows?
What APIs do we need?
What can go wrong?

Same exact process applies here. You might have your own process and own set of questions depending on what and how you want to build, for whom, so on. But there’ll be some design decisions that you need to take before you start building.

1. Goal clarity: single-shot vs multi-step

A single-shot agent takes a request and returns a response. Think: “Summarize this document.” A multi-step agent plans, executes, observes, and iterates. Think: “Research this topic, find relevant papers, compare their findings, and write a report.”

Most people jump straight to multi-step because it feels more impressive. But single-shot agents are easier to test, cheaper to run, and more predictable. Start there. Upgrade when you have evidence that you need more.

2. Control style: how much autonomy does the LLM get?

This is the architectural decision most people skip, and it’s the one that matters most.

Reactive (ReAct): The LLM decides what to do at each step based on what it observes. Flexible, but hard to predict. Think of it like giving someone directions one turn at a time.
Plan-then-execute: The LLM creates a plan upfront, then executes it step by step. More predictable, but brittle when the plan hits reality. Like writing out all the directions before the trip.
Hybrid: Plan first, but allow re-planning when observations don’t match expectations. This is where most production agents end up.

The ReAct paper by Yao and others formalized the reasoning + acting loop that most agent frameworks now implement. Worth reading if you want to understand the foundations.

3. Tool surface area: narrow vs wide

Every tool you give an agent is a degree of freedom. More tools means more capability, but also more ways to fail. A tool is essentially an API the LLM can call, and just like with microservices, the question isn’t “can we add another endpoint?” but “should we?”

Start with 2-3 tools. Add more only when you can demonstrate the agent needs them. This isn’t minimalism for aesthetics, it’s minimalism for reliability.

The Architecture Shift

In a traditional app:

You control every step. The flow is deterministic. If something breaks, you can trace exactly where.

In an agent system:

The key shift you’d notice by now is that in apps, you control the flow. In agents, you design the boundaries of control. You decide which tools exist, what they can do, how much context the LLM sees, and when to stop. The LLM decides everything else within those boundaries.

This is why agent design is closer to API design than to prompt engineering. You’re defining an interface and a contract, not writing instructions.

Building the Agent

In app development, the implementation phase is: pick your stack, wire your APIs, implement your logic. In agents, it’s: pick your model, define your tools, define your loop.

The Minimal Agent Loop

Every agent, regardless of framework, follows this pattern:

flowchart TD
    A[User Input] --> B[LLM Planner]
    B --> C{Need a Tool?}
    C -- Yes --> D[Tool Call]
    D --> E[Tool Result]
    E --> B
    C -- No --> F[Final Answer]

Here’s what that looks like in practice with a simple Python implementation:

import anthropic

client = anthropic.Anthropic()
tools = [
    {
        "name": "search_docs",
        "description": "Search internal documentation for relevant information",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "Search query"}
            },
            "required": ["query"]
        }
    }
]

def run_agent(user_message: str, max_steps: int = 10):
    messages = [{"role": "user", "content": user_message}]

    for step in range(max_steps):
        response = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=1024,
            tools=tools,
            messages=messages
        )

        # If the model wants to use a tool
        if response.stop_reason == "tool_use":
            tool_block = next(b for b in response.content if b.type == "tool_use")
            tool_result = execute_tool(tool_block.name, tool_block.input)

            messages.append({"role": "assistant", "content": response.content})
            messages.append({
                "role": "user",
                "content": [{
                    "type": "tool_result",
                    "tool_use_id": tool_block.id,
                    "content": tool_result
                }]
            })
        else:
            # Model is done, return the final response
            return response.content[0].text

    return "Agent reached maximum steps without completing."

That’s it. That’s a working agent. No framework, no abstractions. Just a loop that lets an LLM call tools and reason about results.

Start Small, Then Expand

Most people overbuild agents.

I’ve seen teams start with 15 tools, a vector database for memory, a planning module, a reflection step, and a custom evaluation pipeline, all before they’ve validated that the agent can reliably do the one thing it’s supposed to do.

Start with:

1 model
2-3 tools
No memory

Get that working reliably. Then add complexity one piece at a time, measuring the impact of each addition. This is the same advice we give for microservices: start with a monolith, extract services when you have a reason to.

Skills: The Building Blocks

As your agent grows beyond a few tools, you’ll notice something. The interesting behavior isn’t in the agent loop itself, it’s in the capabilities the agent calls. Searching, summarizing, classifying, extracting, judging. These are skills, the smallest units of intelligence that actually produce outcomes.

Most teams embed skills directly into prompts or tool wrappers, tightly coupled to a specific agent. That works early on, but it doesn’t scale. When a skill is buried inside a prompt, you can’t test it in isolation, you can’t reuse it across agents, and you can’t improve it without risking regressions elsewhere.

The better approach is to treat skills as first-class artifacts. A skill has a clear interface, it can run independently, and its behavior can be measured. Think of it like the difference between inline code and a well-defined function with a contract. The agent decides what to do. The skill defines how it gets done.

This separation pays off quickly. Agents become simpler because they’re just orchestration. Debugging gets easier because you can isolate which skill misbehaved. And reuse becomes real, not just theoretical. A summarization skill that works for your research agent can plug into your customer support agent without rewriting anything.

Anthropic’s agent skills framework formalizes this idea, treating skills as discoverable, composable units rather than implicit prompt logic. I’ve been building on this with Sutras, a CLI that handles the lifecycle around skills: authoring, validation, evaluation, versioning, and distribution. Because having a spec for what a skill is doesn’t help much if you can’t test it, version it, or share it. Here’s a detailed article on Skills and Sutras.

If you’re building agents that need to do more than one or two things well, start thinking in skills early. It’ll save you from the “giant prompt that does everything” trap.

Frameworks and When to Use Them

If you’re building something simple, you probably don’t need a framework. The code above is ~30 lines. But as complexity grows, frameworks help with orchestration, state management, and tool registration.

Some worth knowing:

LangGraph: Graph-based agent orchestration from LangChain. Good for complex multi-step workflows where you need explicit control over the execution graph.
CrewAI: Multi-agent collaboration framework. Useful when your problem naturally decomposes into roles (researcher, writer, reviewer).
Anthropic’s Agent SDK: Lightweight, close-to-the-metal. Good when you want control without too much abstraction.
Autogen: Microsoft’s multi-agent framework. Strong on conversation patterns between agents.

The right choice depends on your use case, not on what’s trending on Linkedin or X(Twitter). A single-agent tool-use loop doesn’t need LangGraph. A multi-agent research pipeline probably does.

Testing Agents: The Missing Discipline

This is where the gap between “app thinking” and “agent thinking” is widest.

In app development, we have decades of established practice: unit tests, integration tests, end-to-end tests, staging environments, CI/CD pipelines. In the agent world? Mostly vibes. Someone runs the agent a few times, eyeballs the output, and calls it good.

That’s not engineering. That’s a demo.

The Agent Testing Stack

Agent Testing	App Equivalent	What It Catches
Tool unit tests	Unit tests	Broken tools, bad schemas
Single-step evals	Function tests	Wrong tool selection, bad arguments
Multi-step trajectory evals	Integration tests	Planning failures, loops, dead ends
Prompt injection tests	Security testing	Adversarial manipulation
Eval datasets with scoring	Regression testing	Quality degradation over time

I’ve written about evals and building trustworthy AI tools before, and everything in those posts applies here. But agents add a new dimension: you’re not just evaluating a single output, you’re evaluating a trajectory, the sequence of decisions the agent made to get there.

Evaluating Trajectories, Not Just Outputs

A wrong answer that came from a reasonable chain of reasoning is very different from a right answer that came from lucky hallucination. You need to evaluate both.

from ragas.metrics.collections import Faithfulness
from ragas.llms import llm_factory

# Works with any supported model: gpt-4o-mini, claude-sonnet, gemini-pro, etc.
llm = llm_factory("gpt-4o-mini")
faithfulness = Faithfulness(llm=llm)

# Evaluate whether the agent's final answer is grounded in what its tools returned
result = await faithfulness.ascore(
    user_input="What were our Q4 sales?",
    response=agent_final_answer,
    retrieved_contexts=tool_results_from_agent_run
)
print(f"Score: {result.value}")   # e.g. 0.85
print(f"Reason: {result.reason}") # explanation of the score

The MetricResult object gives you both a score and a reason, so you know not just how faithful the answer is but why it scored that way. This tells you whether the agent’s answer is grounded in the information it actually retrieved, not whether it sounds plausible.

The Eval Mindset

flowchart TD
    A[Test Dataset] --> B[Agent Runs]
    B --> C[Outputs + Trajectories]
    C --> D[Scoring: Correctness, Faithfulness, Tool Use]
    D --> E[Pass/Fail + Metrics Dashboard]
    E --> F{Regression?}
    F -- Yes --> G[Investigate & Fix]
    F -- No --> H[Ship It]

If you’re not running evals, you don’t have an agent. You have a demo.

I keep coming back to this because it’s the single biggest gap I see. Teams spend weeks building agent capabilities and zero hours building agent evals. Then they’re surprised when the agent breaks in production.

If you need help getting started with evals, Ragas is a solid starting point. For more on the philosophy, the Anthropic guide to evaluations is excellent.

Running Agents

Traditional apps follow a clean request/response cycle. A request comes in, business logic runs, a response goes out. Stateless, predictable, well-understood.

Agents break this model in several ways:

They loop. An agent might make 3 tool calls or 30, depending on the task.
They’re stateful. Context accumulates across steps within a single run.
They’re slow. A multi-step agent might take 30 seconds or 3 minutes to complete.
They’re expensive. Each step consumes tokens, and tokens cost money.

Runtime Patterns

Short-lived agents: Synchronous, request/response. The user waits. Good for simple tool-use (under 10 seconds). This is your starting point.

Long-running agents: Async, queue-based. The user submits a task and checks back later. Necessary when the agent might run for minutes. Think: research tasks, code generation with testing, data analysis pipelines.

Streaming agents: Partial outputs as the agent works. The user sees progress. Good for chat interfaces where you want to show the agent’s reasoning in real-time. Most modern APIs (Claude, GPT, Gemini, Mistral, GLM) support streaming natively.

Failure Modes You Must Handle

This is where agent systems diverge sharply from traditional apps. In a normal API, if a request fails, you return a 500 and the client retries. In an agent, failures are more insidious:

Tool failures: An API is down, a database query times out. The agent needs to know how to handle this gracefully: retry, skip, or ask the user.
Hallucinated tool arguments: The LLM invents parameters that don’t exist or passes the wrong types. This is the agent equivalent of a type error, except your type system is a prompt.
Infinite loops: The agent keeps calling the same tool with the same arguments, expecting different results. Without a step limit, you burn through tokens and patience.
Context window overflow: In long-running agents, the conversation history grows until it exceeds the model’s context window. You need a strategy for summarizing or truncating.

Handling these isn’t optional. It’s the difference between a demo and a product.

def run_agent_with_guardrails(user_message: str):
    max_steps = 15
    max_consecutive_errors = 3
    error_count = 0

    messages = [{"role": "user", "content": user_message}]

    for step in range(max_steps):
        try:
            response = client.messages.create(
                model="claude-sonnet-4-6",
                max_tokens=1024,
                tools=tools,
                messages=messages
            )
            error_count = 0  # Reset on success

            if response.stop_reason == "tool_use":
                tool_block = next(b for b in response.content if b.type == "tool_use")
                try:
                    result = execute_tool(tool_block.name, tool_block.input)
                except ToolExecutionError as e:
                    result = f"Tool error: {e}. Try a different approach."

                messages.append({"role": "assistant", "content": response.content})
                messages.append({
                    "role": "user",
                    "content": [{"type": "tool_result", "tool_use_id": tool_block.id, "content": result}]
                })
            else:
                return response.content[0].text

        except Exception as e:
            error_count += 1
            if error_count >= max_consecutive_errors:
                return f"Agent stopped after {max_consecutive_errors} consecutive errors: {e}"

    return "Agent reached step limit. Partial progress may be available."

Making It Real

Deploying an agent is deploying a backend service, plus extra concerns unique to LLM-based systems.

Cost

Every agent step is an API call. Every API call costs tokens. A multi-step agent that makes 10 tool calls per request can easily cost 10-50x more than a single LLM call. You need to budget for this.

Practical strategies:

Use cheaper models (Claude Haiku, GPT-4o-mini, Gemini Flash, Qwen-turbo) for simple steps, expensive models (Claude Opus, GPT-4, Gemini Pro, Mistral Large) for complex reasoning.
Cache tool results aggressively. If two users ask about the same data, don’t re-fetch.
Set hard token budgets per agent run.

Latency

Multi-step agents are inherently slow. Each step requires a round-trip to the model API. A 5-step agent with 2-second API latency takes at minimum 10 seconds.

Strategies:

Parallelize independent tool calls where possible.
Stream partial outputs so the user sees progress.
Set user expectations. A loading spinner that says “Researching…” is better than a blank screen for 30 seconds.

Observability

This is where traces become critical. Logs tell you what happened. Traces tell you why.

For every agent run, you want to capture:

The user’s original request
Each LLM call (input, output, model, latency, token usage)
Each tool call (name, arguments, result, duration)
The final output
Total cost and duration

flowchart TD
    A[User Query] --> B[Agent Run]
    B --> C[Tool Calls]
    B --> D[LLM Reasoning Steps]
    C --> E[Structured Logs]
    D --> E
    E --> F[Tracing Dashboard]
    F --> G[Cost Tracking]
    F --> H[Latency Analysis]
    F --> I[Error Patterns]

Tools like Langfuse, Braintrust, and Arize Phoenix are purpose-built for this. If you’re already using Datadog or Grafana, you can pipe agent traces there too.

Memory: The State Management Problem

Memory in agents maps directly to state management in apps. And just like in apps, getting it wrong leads to subtle, hard-to-debug issues.

Short-term memory is the conversation history within a single agent run. This is your working context. Every message, tool call, and result accumulates here. The challenge is context window management, since you can’t keep everything forever.

Long-term memory is persistent state across runs. User preferences, past interactions, learned facts. This is your database. The challenge is retrieval: how does the agent know what’s relevant from thousands of past interactions?

Most agents don’t need long-term memory at first. Start without it. Add it when users complain that the agent “forgets” important context.

If you do need memory, vector databases (Pinecone, Weaviate, Qdrant) are the standard approach for semantic retrieval. But don’t underestimate simpler approaches. A SQLite database with structured metadata can go surprisingly far.

Context Management

Context is the single most important resource an agent has. Every decision the LLM makes is based on what’s in its context window. Feed it too little and it makes uninformed choices. Feed it too much and it drowns in noise, misses key details, or hits token limits mid-run. For a multi-step agent that accumulates tool calls and results over 10-15 steps, context bloat isn’t a theoretical risk, it’s the default outcome.

This matters more for agents than for simple chat applications. In a chatbot, a bad context window means a slightly off response. In an agent, it means the wrong tool gets called, the wrong arguments get passed, and the entire trajectory goes sideways. The LLM’s ability to plan and reason degrades as context fills up with irrelevant information.

Sliding window

Keep only the last N messages or tokens. Simple and predictable, but you lose early context that might still be relevant. Works well for short-lived agents where early steps don’t inform later ones.

Summarization

Periodically compress older messages into a summary and replace them. The agent retains the gist without carrying the full weight. This is the most common pattern for long-running agents. The tradeoff is that summarization itself costs tokens and can lose nuance.

Selective injection

Don’t carry everything forward. Instead, store tool results and past reasoning externally, then use RAG to pull in only what’s relevant for the current step. This is the most scalable approach but adds retrieval latency and complexity.

Structured context

Instead of dumping raw tool outputs into the conversation, format them into concise structured summaries before adding them to context. A 500-line API response becomes a 10-line summary of the fields that matter. This is cheap to implement and often the highest-impact optimization.

As your agent handles longer tasks or serves more users concurrently, context management becomes a scaling bottleneck. Each agent run holds its own context in memory. Longer contexts mean more tokens per API call, which means higher cost and latency. At scale, the practical strategies are: keep individual agent runs short and focused, break complex tasks into sub-agents with their own scoped context, and invest in good summarization so context stays lean. The agents that scale well aren’t the ones with the biggest context windows, they’re the ones that are smartest about what goes into the window in the first place.

Distribution

This is where agents and traditional apps truly diverge.

Apps distribute through well-understood channels: App Store, web, desktop. Agents have more options, and the right distribution model fundamentally shapes how you build.

API-first agents: Your agent is a service that other developers integrate. Think: a code review agent that plugs into GitHub via webhooks.
Chat/UI agents: Embedded in a conversational interface. The most common pattern today.
CLI agents: For developer tools and power users. Claude Code is a good example, a full agent that lives in the terminal.
Embedded agents: Inside existing products, triggered by user actions. Not a standalone “AI feature” but intelligence woven into the product flow.

And then there’s composability. With protocols like Model Context Protocol (MCP), agents can discover and use tools dynamically. This shifts distribution from “ship a complete agent” to “ship capabilities that any agent can use.” I’ve been building skills as composable units for exactly this reason. The future isn’t monolithic agents, it’s an ecosystem of interoperable capabilities.

The best agent doesn’t win. The most accessible agent does.

This is true for apps and doubly true for agents. An agent that’s 80% as capable but available inside the tool your users already live in will beat a 100% capable agent that requires switching contexts.

Putting It All Together

Let’s trace through a real example. Say you’re building an agent that helps developers understand unfamiliar codebases. Given a GitHub repo URL, it parses the structure, identifies key patterns, and produces a visual summary.

Design Phase

Goal: Single repo → structured explanation with visual
Control style: Plan-then-execute (the steps are predictable)
Tools: repo cloner, file reader, code summarizer, diagram generator
Memory: None needed (each request is independent)

Implementation

flowchart TD
    A[GitHub Repo URL] --> B[Clone & Parse Structure]
    B --> C[Identify Key Files & Patterns]
    C --> D[LLM: Summarize Architecture]
    D --> E[Generate Visual Diagram]
    E --> F[Return Summary + Diagram]

Testing

Tool tests: Does the repo cloner handle private repos? Large repos? Monorepos?
Single-step evals: Given a known repo, does the summarizer identify the right architectural patterns?
End-to-end evals: For 50 popular open-source repos, are the summaries accurate and the diagrams useful?
Prompt injection: What if the repo’s README contains instructions to the LLM?

Where People Mess Up

No evals → inconsistent outputs that they don’t notice until users complain
Too many tools → the LLM gets confused about which to use, or invents parameters
No constraints → the agent tries to read every file in a 10,000-file monorepo
No cost limits → a single request triggers hundreds of LLM calls parsing files

Every one of these is preventable with the same engineering discipline we apply to regular apps.

Takeaways

If you take one thing from this post, let it be this: agents are not a new paradigm. They’re a new runtime for the same engineering principles we’ve always used.

Design agents like systems, not like prompts
Most agent failures are design failures, not model failures
Testing and evals are the biggest missing piece. Invest in them early.
Start simple: 1 model, 2-3 tools, no memory. Expand with evidence.
Observability isn’t optional. You need to know what your agent did and why.
Distribution and accessibility will decide winners, not raw capability

We don’t need better prompts. We need better systems thinking for agents.

The playbook already exists. We just need to open it.

References & Further Reading

ReAct: Synergizing Reasoning and Acting in Language Models, the foundational paper on the reason-then-act loop
Anthropic: Building Effective Agents, practical patterns from Anthropic’s research
Anthropic: Guide to Evaluations, how to test LLM-based systems properly
Model Context Protocol, open standard for connecting LLMs to tools and data
LangGraph Documentation, graph-based agent orchestration
Ragas, evaluation framework for LLM applications
Langfuse, open-source observability for LLM apps
Lilian Weng: LLM Powered Autonomous Agents, one of the best technical overviews of agent architectures
The Landscape of Emerging AI Agent Architectures, survey of agent design patterns

Skills, Agents, and the Missing Middle

2026-01-09T00:00:00Z

If you’ve been building with LLMs for a while, you’ve probably built an agent at some point.

You give the model a role. You add a few tools. You maybe throw in memory, some planning logic, and a carefully tuned system prompt. It works. Until it doesn’t. And when it doesn’t, it’s usually hard to explain why.

At first, it’s tempting to blame the model. Or the prompt. Or the framework. But after building a few of these systems, a pattern starts to emerge: the problem isn’t reasoning, it’s structure.

What We Actually Mean by “Skills”

When we talk about agent skills, we usually mean something very intuitive. A skill is something an agent can do. Search, summarize, classify, judge, decide, extract. These are the building blocks agents rely on to interact with the world.

In practice, though, most skills today don’t really exist as things of their own. They’re embedded inside prompts, scattered across tool wrappers, or tightly coupled to a specific agent loop. They’re hard to see, harder to test in isolation, and almost impossible to reuse cleanly.

We call them skills, but they behave more like side effects of prompt engineering.

Agents get most of the attention, but agents are mostly coordination. They decide what to do next and which capability to invoke. The actual behavior. The thing that produces correct or incorrect outcomes, lives inside the skills themselves.

If a skill is unreliable, the agent will be unreliable. If a skill improves, the entire system improves. Skills are the smallest unit of intelligence that actually moves the needle.

That suggests something important. If we want better agent systems, we need to take skills seriously as first-class artifacts. We need to be able to define them clearly, run them independently, measure how they behave, improve them over time, and reuse them across agents.

That’s still surprisingly rare.

One of the more promising directions here is the work around Agent Skills, particularly the way Anthropic has framed them. Treating skills as explicit, discoverable units instead of implicit prompt logic is a big step forward. It gives us a shared vocabulary and a starting point for interoperability.

But a specification alone isn’t enough. Knowing what a skill is doesn’t automatically tell you how to build one well, how to test it, or how to evolve it without breaking everything downstream.

This is where most real-world systems start to struggle. Most issues with agent systems aren’t caused by missing tools or clever reasoning tricks. They come from unmanaged skill lifecycle.

A skill gets tweaked. Something improves somewhere else. A regression sneaks in. No one knows which change caused it or why. Over time, skills accumulate complexity, but there’s no clear boundary where you can stop, inspect, and say: “This thing works, and here’s how we know.”

Without that boundary, iteration becomes guesswork.

Introducing Sutras

View Sutras on GitHub

This is the gap Sutras is trying to fill.

Sutras help build skills which are a concise, structured, executable unit of capability. It has a clear interface. It can be run on its own. Its behavior can be measured. And it has a lifecycle that doesn’t depend on a specific agent or framework.

Sutras builds on the emerging agent skill model, but shifts the focus to everything that happens around invocation: authoring, validation, evaluation, iteration, versioning, and distribution. The goal isn’t to replace agent frameworks or invent a new abstraction. It’s to give skills a proper car to drive to your agent home.

Once skills become explicit artifacts, a few things get easier. Agents become simpler because they don’t need to carry so much hidden logic. Failures become easier to reason about because you can isolate behavior. Reuse stops being an afterthought.

Agents decide what to do. Sutras define what can be done. More about how Sutras work and it’s capabilities in the next article. 🫶

That separation doesn’t solve every problem, but it turns a messy prompt-driven system into something closer to software you can reason about.

What’s Next

Skills are still early. The current focus is on getting the foundations right: aligning with emerging skill standards, keeping the model small, and making lifecycle discipline the default instead of an afterthought. Anthropic suggests to segregate skills in 3 main categories, but I guess we’ll see how it evolves.

There’s a lot more to explore, from richer evaluation loops to better ways of sharing and composing skills. None of that should be designed in isolation.

If you’ve ever felt that skills deserve more structure than they get today, you’re already thinking along the same lines. Sutras is an attempt to turn that instinct into something concrete, and it’s very much a work in progress.

More to come, and if this resonates, the best way to shape it is together with the community. Let me what you think about it. Open an issue to request a feature or maybe just leave us a star. 🙌

Building AI Tools You Can Trust

2025-11-16T00:00:00Z

You want to build an AI application. Something useful. Something your users can rely on.

But here’s the problem: How do you know it’s actually good?

You can build an app that generates summaries, answers questions, or writes emails. It works. Your tests pass. But is it reliable? Does it hallucinate? Does it miss important information? Is it actually trustworthy?

The philosophy is simple:

You can’t improve what you don’t measure.

Let me paint a realistic scenario:

You’ve built a summarization app. Users love the interface. The summaries look great. But then:

A news outlet tries your app and finds the summary omits a crucial financial number
A researcher uses it and discovers the summary makes a claim that’s not in the original paper
A student uses it and the summary misrepresents the nuance of the source material

Sound familiar? This happens all the time in full-stack AI apps because people build features without measuring quality.

The difference between a hobby project and a professional tool is this: Professional tools measure themselves.

Our Journey: Building a Trustworthy Summarization Tool

Let’s start 🚀

If you want to follow along, here the repo. There’s also a notebook which has everything I’ll be covering in this article.

Run in Google Colab

No installation. No setup. Just click and start:

Quick start:

Click the button above
Run the first cell (installs dependencies)
Add your OpenAI API key to Colab Secrets (click 🔑 icon)
Run the remaining cells
See your evaluation scores
Experiment with optimization strategies

🏠 Run Locally

git clone https://github.com/anistark/ai-summarisation.git cd ai-summarisation uv sync jupyter notebook summarisation_demo.ipynb

Then follow the cells to:

Generate summaries
Run evaluations
Compare strategies
Understand your metrics

Step 1: Setting Up

First, install the dependencies:

pip install ragas==0.3.9 langchain-openai langchain-core python-dotenv

These packages give us:

ragas - The evaluation framework
langchain-openai - Access to GPT models
python-dotenv - Manage API keys safely

Now let’s initialize everything:

import os
import asyncio
from typing import Optional
from dotenv import load_dotenv

# Load environment variables
load_dotenv()
api_key = os.environ.get("OPENAI_API_KEY")
llm_model = os.environ.get("LLM_MODEL", "gpt-4o-mini")

# Initialize OpenAI client
from openai import AsyncOpenAI
client = AsyncOpenAI(api_key=api_key)

# Setup RAGAS for evaluation
from ragas.llms import llm_factory
from ragas.metrics.collections import SummaryScore, Faithfulness

llm = llm_factory(llm_model, client=client)
print("✅ Setup complete!")

Step 2: Load an Article

Let’s load some content to summarize:

article = """
Apple announced on Tuesday that it will invest $1 billion in new AI research centers
across the United States over the next five years. The company plans to hire 500 new
researchers and engineers specifically for AI development. CEO Tim Cook stated that
artificial intelligence is central to the company's future product strategy. The investment
will focus on areas like natural language processing, computer vision, and machine learning
efficiency. Apple will establish research hubs in San Francisco, Boston, and Seattle.
The company already employs over 10,000 AI researchers globally.
"""

print(f"📰 Article: {len(article.split())} words")

Step 3: Generate a Summary

Now let’s actually summarize it using an LLM:

from langchain_openai import ChatOpenAI
from langchain_core.prompts import PromptTemplate

# Initialize the summarizer
summarizer = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.3)

# Create a prompt
summarization_prompt = PromptTemplate(
    input_variables=["text"],
    template="""Summarize the following text in 2-3 sentences.
Focus on the main points and key details.

Text:
{text}

Summary:"""
)

# Generate the summary
chain = summarization_prompt | summarizer
response = chain.invoke({"text": article})
generated_summary = response.content.strip()

print("✍️ Generated Summary:")
print(generated_summary)

This gives us something like:

“Apple is investing $1 billion in AI research over five years, planning to hire 500 researchers across three US cities. The investment focuses on natural language processing, computer vision, and machine learning efficiency.”

Looks good, right? But is it actually good? That’s the question.

This is where things get interesting.

Instead of relying on intuition, we’re going to measure the summary using objective metrics.

Understanding Metric #1: Summary Score

What it measures: Does your summary capture the important information from the source?

How it works:

RAGAS extracts key phrases from the original article
It generates questions about those key phrases
It checks if your summary answers those questions
The score is the percentage of questions answered correctly

Why this matters: You could have a summary that sounds good but actually misses critical details. If the original article mentions “$1 billion” and your summary skips it, the Summary Score will reflect that loss.

What the scores mean:

0.8-1.0 ✅ Excellent - You’ve captured essential information
0.6-0.8 ✅ Good - Main points are present
0.4-0.6 ⚠️ Fair - Missing important details
<0.4 ❌ Poor - Significant information loss

Example:

Original: "Company investing $1B, hiring 500 people, 3 locations" Bad Summary: "Company investing in AI" Result: Summary Score drops because numbers are missing

Understanding Metric #2: Faithfulness

What it measures: Is your summary making stuff up? Is it hallucinating?

How it works:

RAGAS breaks down the summary into individual claims
For each claim, it checks: “Is this claim supported by the source?”
It flags claims that don’t appear in the original text
The score is the percentage of claims that are grounded in the source

Why this matters: A hallucinated fact is worse than a missing fact. If your summary invents information, you’re not just losing accuracy, you’re actively spreading misinformation.

What the scores mean:

0.9-1.0 ✅ Excellent - Fully grounded, no hallucinations
0.7-0.9 ✅ Good - Mostly accurate
0.5-0.7 ⚠️ Fair - Some ungrounded claims
<0.5 ❌ Poor - Contains hallucinations

Example:

Original: "Apple invests in AI research" Bad Summary: "Apple is developing self-driving cars and robots" Result: Faithfulness drops because those claims aren't in the source

Choosing Your Metrics: Not All Use Cases Are the Same

Different applications need different priorities:

Use Case	Summary Score	Faithfulness	Why?
News articles	30% weight	70% weight	Accuracy is everything. Missing a detail is okay if what’s there is true.
Research papers	70% weight	30% weight	Completeness matters. You need the findings. Hallucination is bad but rarer in structured text.
Financial reports	40% weight	60% weight	One false number can cost millions. Accuracy > completeness.
Learning materials	50% weight	50% weight	Students need both complete AND accurate summaries.
Social media	80% weight	20% weight	Engagement and quick takeaway. Perfection isn’t necessary.

The key: Decide your priorities before you build.

Now let’s actually measure our summary:

# Initialize the evaluation metrics
summary_score_metric = SummaryScore(llm=llm)
faithfulness_metric = Faithfulness(llm=llm)

async def evaluate_summary():
    """Evaluate the summary I just created"""
    print("🔍 Evaluating summary...\n")

    try:
        # Metric 1: Summary Score
        print("⏳ Computing Summary Score...")
        summary_result = await summary_score_metric.ascore(
            reference_contexts=[article],  # The original article
            response=generated_summary      # Our summary
        )
        summary_score = float(summary_result.value)
        print(f"   ✅ Summary Score: {summary_score:.3f}")
        print(f"      Captures {summary_score*100:.0f}% of key information\n")

        # Metric 2: Faithfulness
        print("⏳ Computing Faithfulness...")
        faithfulness_result = await faithfulness_metric.ascore(
            user_input=article,
            response=generated_summary,
            retrieved_contexts=[article]
        )
        faithfulness = float(faithfulness_result.value)
        print(f"   ✅ Faithfulness: {faithfulness:.3f}")
        print(f"      {faithfulness*100:.0f}% of claims are grounded in source\n")

        return {
            "summary_score": summary_score,
            "faithfulness": faithfulness,
        }

    except Exception as e:
        print(f"❌ Error: {e}")
        return None

# Run the evaluation
results = await evaluate_summary()

Here’s what just happened:

You sent your summary to an LLM evaluator
The evaluator analyzed it against the original article
You got objective scores that tell you exactly how good your summary is
You now have data instead of vibes

This is the difference between guessing and knowing.

Here, we got a good score on faithfulness. However summary score says it’s got lots of room for improvement.

The beauty of having metrics is that you can test different approaches and see which works best:

Strategy 1: Longer Summaries

Maybe 2-3 sentences isn’t enough. Let’s try 5-7:

longer_prompt = PromptTemplate(
    input_variables=["text"],
    template="""Summarize the following text in 5-7 sentences.
Capture all key points, numbers, and important details.

Text:
{text}

Summary:"""
)

chain = longer_prompt | summarizer
longer_summary = chain.invoke({"text": article}).content.strip()

Trade-off: Longer summaries usually score higher on Summary Score (more information), but you lose compression and some readers might not read it all.

Strategy 2: Structured Prompt

Guide the LLM to focus on specific aspects:

structured_prompt = PromptTemplate(
    input_variables=["text"],
    template="""Summarize focusing on:
- WHAT (the action/announcement)
- WHY (the reason/motivation)
- WHERE (locations involved)
- HOW MUCH (numbers and scale)
- WHO (the organization)

Text:
{text}

Summary:"""
)

chain = structured_prompt | summarizer
structured_summary = chain.invoke({"text": article}).content.strip()

Why it works: By explicitly asking for key details, the LLM is less likely to skip them.

Strategy 3: Bullet Points

Sometimes format matters:

bullet_prompt = PromptTemplate(
    input_variables=["text"],
    template="""Summarize as 4-5 bullet points.
Each bullet should state ONE key fact.

Text:
{text}

Summary:"""
)

chain = bullet_prompt | summarizer
bullet_summary = chain.invoke({"text": article}).content.strip()

Evaluate all three and see which one wins:

async def compare_strategies():
    """Compare different summarization approaches"""
    strategies = {
        'longer': longer_summary,
        'structured': structured_summary,
        'bullets': bullet_summary
    }

    print("Testing different strategies...\n")
    results = {}

    for name, summary in strategies.items():
        print(f"Evaluating: {name}")

        score = await summary_score_metric.ascore(
            reference_contexts=[article],
            response=summary
        )

        faith = await faithfulness_metric.ascore(
            user_input=article,
            response=summary,
            retrieved_contexts=[article]
        )

        results[name] = {
            'summary_score': float(score.value),
            'faithfulness': float(faith.value),
            'combined': float(score.value) + float(faith.value)
        }

        print(f"  Summary Score: {results[name]['summary_score']:.3f}")
        print(f"  Faithfulness: {results[name]['faithfulness']:.3f}")
        print(f"  Combined: {results[name]['combined']:.3f}\n")

    # Find the winner
    best = max(results.items(), key=lambda x: x[1]['combined'])
    print(f"🏆 Winner: {best[0].upper()}")
    print(f"   Combined Score: {best[1]['combined']:.3f}")

    return results

# Run it
comparison_results = await compare_strategies()

This is empirical optimization. You’re not guessing which approach is best, you’re measuring and letting data decide.

Here’s what we’ve built so far:

This workflow is powerful because:

Objective feedback - No subjective opinions, just scores
Continuous improvement - You can always test new approaches
Quality gates - You can set minimum scores before publishing
Learning loop - Over time, you understand what works for your use case

Now that you understand how evaluation works, here are practical guidelines for building production systems:

✅ DO’s

1. DO Set Minimum Score Thresholds

Define what “good enough” means before you deploy:

SUMMARY_SCORE_THRESHOLD = 0.75
FAITHFULNESS_THRESHOLD = 0.90

def is_summary_publishable(results):
    return (results['summary_score'] >= SUMMARY_SCORE_THRESHOLD and
            results['faithfulness'] >= FAITHFULNESS_THRESHOLD)

if is_summary_publishable(results):
    publish_summary()
else:
    flag_for_manual_review()

Different use cases need different thresholds:

News outlets: 0.85+ (accuracy critical)
Research papers: 0.80+ (completeness critical)
Social media: 0.60+ (engagement over perfection)
Learning platforms: 0.75+ (balance needed)

2. DO Test Multiple Models

Different models produce different quality:

models = ["gpt-3.5-turbo", "gpt-4o-mini", "gpt-4"]

for model in models:
    summarizer = ChatOpenAI(model=model)
    summary = generate_summary(article, summarizer)
    score = evaluate_summary(summary)
    print(f"{model}: {score:.3f}")

# Pick the best performer

GPT-3.5 is cheap. GPT-4 is better. GPT-4o-mini is the sweet spot for many use cases. Let metrics decide.

3. DO Monitor Evaluation Costs

Evaluations cost money. Budget accordingly:

# Track costs
EVAL_COST_PER_SUMMARY = 0.004  # Rough estimate

# Sample evaluation, don't evaluate everything
sample_size = min(100, len(all_summaries))  # Sample 100 or all
eval_cost = sample_size * EVAL_COST_PER_SUMMARY

print(f"Evaluating {sample_size} summaries will cost: ${eval_cost:.2f}")

For production: sample 10% of summaries. For critical content: evaluate 100%. For bulk operations: sample even less.

4. DO Create a Feedback Loop

Use metrics to continuously improve:

# Log everything
import json
from datetime import datetime

log_entry = {
    "timestamp": datetime.now().isoformat(),
    "article_length": len(article.split()),
    "model": "gpt-3.5-turbo",
    "summary_score": 0.82,
    "faithfulness": 0.93,
    "strategy": "structured_prompt"
}

with open("evaluation_log.jsonl", "a") as f:
    f.write(json.dumps(log_entry) + "\n")

# Later: analyze patterns
# - Which prompts work best?
# - Do long articles score lower?
# - Is there seasonality?

5. DO Test With Real Data

Example articles are for learning. Test with your actual content:

# Load your real articles
from pathlib import Path

your_articles = []
for file in Path("/path/to/articles").glob("*.txt"):
    with open(file) as f:
        your_articles.append(f.read())

# Evaluate on real data
for article in your_articles:
    summary = generate_summary(article)
    results = evaluate_summary(summary)

    # Analyze real-world performance
    avg_score = sum(r['summary_score'] for r in results) / len(results)

6. DO Document Your Decisions

Future you will thank present you:

"""
Summarization System Configuration
===================================
Created: 2025-01-15
Purpose: Production summarization service

Decisions:
- Model: gpt-4o-mini (cost/quality balance)
- Summary Length: 3-5 sentences
- Minimum Thresholds:
  * Summary Score: 0.75
  * Faithfulness: 0.85
- Rejection Strategy: Flag for manual review

Trade-offs:
- Not using GPT-4 to save costs
- Accepting 78% info preservation for speed
- Manual review for edge cases

Review Date: 2025-02-15
"""

7. DO Handle Errors Gracefully

APIs fail. Networks go down. Budget runs out:

try:
    score = await summary_metric.ascore(...)
except RateLimitError:
    logger.warning("Rate limited, retrying...")
    await asyncio.sleep(60)
    score = await summary_metric.ascore(...)
except APIError as e:
    logger.error(f"API error: {e}")
    flag_for_manual_review(summary)
    score = None

❌ DON’Ts

1. DON’T Trust Metrics Blindly

Metrics are tools, not oracles. Always have humans review:

# BAD: Automate based purely on score
if summary_score > 0.8:
    publish_summary()  # ❌ Wrong!

# GOOD: Use metrics as a guide
if summary_score > 0.8:
    send_to_human_review()  # Human has final say

2. DON’T Ignore Faithfulness for Speed

Don’t optimize only for Summary Score at the expense of Faithfulness:

# BAD: Chasing higher Summary Score by any means
prompt = "Include EVERY DETAIL from the article"  # ❌
# Result: Longer summaries, higher Summary Score, but hallucinations

# GOOD: Balance both
prompt = "Summarize accurately without adding new information"

Hallucinations destroy trust. One false claim tanks your credibility.

3. DON’T Hardcode API Keys

Never, ever, ever:

# TERRIBLE
api_key = "sk-proj-abc123xyz..."  # ❌❌❌

# GOOD
load_dotenv()
api_key = os.environ.get("OPENAI_API_KEY")

Add .env to .gitignore. Make this a habit.

4. DON’T Evaluate Everything

Evaluations cost money. Be strategic:

# BAD: Evaluate all 10,000 summaries ($40+)
for summary in all_summaries:
    evaluate_summary(summary)  # ❌ Expensive

# GOOD: Statistical sampling
sample = random.sample(all_summaries, k=100)  # 1% sample
for summary in sample:
    evaluate_summary(summary)  # ✅ Cheap, representative

5. DON’T Use Metrics As Your Only Quality Gate

Metrics are one dimension. Add more layers:

# BAD: Only checking metrics
if summary_score > 0.8:
    publish_summary()  # ❌

# GOOD: Multiple checks
quality_checks = {
    "metrics": evaluate_summary(summary),       # Objective
    "human_review": manual_review(summary),     # Subjective
    "guidelines": check_brand_guidelines(summary),  # Policy
    "safety": toxicity_check(summary)           # Safety
}

if all(c.passed for c in quality_checks.values()):
    publish_summary()  # ✅

6. DON’T Use the Same Model for Summarization and Evaluation

It’s like asking a student to grade their own homework:

# AVOID: Self-grading bias
summarizer = ChatOpenAI(model="gpt-3.5-turbo")
evaluator = ChatOpenAI(model="gpt-3.5-turbo")  # Bias!

# BETTER: Different models
summarizer = ChatOpenAI(model="gpt-3.5-turbo")  # Fast, cheap
evaluator = ChatOpenAI(model="gpt-4")            # Rigorous

7. DON’T Assume One Evaluation Equals Truth

LLM evaluations have variance. Run multiple times for important decisions:

# BAD: Single evaluation
score = await summary_metric.ascore(...)
if score < 0.7:
    reject_summary()  # ❌ What if this was an anomaly?

# GOOD: Multiple runs
scores = []
for _ in range(3):
    score = await summary_metric.ascore(...)
    scores.append(float(score.value))

avg_score = sum(scores) / len(scores)
if avg_score < 0.7:
    reject_summary()  # ✅ More reliable

Common Pitfalls & How to Avoid Them

Pitfall #1: The Score Plateau

Your Summary Score hits 0.75 and won’t improve.

Why: You’ve hit the architectural limits of your approach.

Solution:

Try a completely different prompt (not tweaks, but fundamentally different)
Switch to a more capable model (GPT-4 instead of 3.5)
Increase summary length (allows more information)

Pitfall #2: The Faithfulness Trap

Faithfulness is 0.95 but users say summaries are useless.

Why: You’re being so cautious you lose nuance. Or metrics don’t match user expectations.

Solution:

Add human feedback alongside metrics
Verify that metrics actually align with user satisfaction
Faithfulness ≠ usefulness

Pitfall #3: Runaway Costs

Your evaluation budget exploded unexpectedly.

Why: Evaluated too much, used expensive models, pricing changed.

Solution:

BUDGET = 100  # $100/month
COST_PER_EVAL = 0.004
MAX_EVALS = int(BUDGET / COST_PER_EVAL)  # 25,000

eval_count = 0
for summary in summaries:
    if eval_count >= MAX_EVALS:
        logger.warning("Budget limit reached")
        break
    evaluate_summary(summary)
    eval_count += 1

Pitfall #4: Model Drift

Your system worked for 3 months, then scores dropped mysteriously.

Why: OpenAI updated their model, or your data changed.

Solution:

# Set a baseline
baseline = {
    "date": "2025-01-15",
    "model": "gpt-4o-mini",
    "avg_score": 0.78
}

# Monthly check-in
current = evaluate_sample()
if current["avg_score"] < baseline["avg_score"] * 0.95:
    alert("Score degradation detected!")

Learn More

Want to dive deeper?

RAGAS Documentation - Official docs with all metrics explained
Summary Score Details - How Summary Score works under the hood
Faithfulness Metric - Deep dive into hallucination detection
LangChain Documentation - Building LLM applications
Prompt Engineering Best Practices - OpenAI’s guide to writing better prompts

You can also use more latest gpt-5 series of course or other providers like claude, gemini, etc.

Building AI applications is easy. Building trustworthy AI applications is harder, but not impossibly so.

The difference is measurement. Metrics. Data.

Every time someone asks you, “How do you know your AI summaries are accurate?” you can now answer confidently:

“Because I measure it. Every single time. With objective metrics. And I continuously optimize based on those measurements.”

That’s what separates hobby projects from professional tools.

You now have everything you need to build AI you can trust.

Questions? Found a bug? Have ideas?

Open an issue on GitHub and let’s build better AI together.

Happy building! 🚀

Teaching AI to Grade Other AI

2025-11-09T00:00:00Z

If you’ve been following the world of AI development, you might’ve heard the phrase “LLM-as-Judge.”
It sounds dramatic, like some sci-fi overlord where one AI passes judgment on another. But it’s actually one of the most important evolutions in evaluating large language models (LLMs).

LLM-as-Judge means using a language model itself to evaluate the quality of another model’s responses.

Traditionally, human annotators graded model outputs. Checking if an answer was factual, polite, relevant, or well-reasoned. But as models got more capable and outputs more nuanced, this manual process became slow, expensive, and inconsistent.

So, researchers began asking, Can we train (or prompt) a model to act like a human evaluator?

Turns out, yes, quite effectively.

The idea is simple:

It’s like using one AI to peer-review another. Evaluation is the backbone of AI progress. Without it, we wouldn’t know if newer models are actually better, or just different. Human evaluation doesn’t scale. Imagine evaluating thousands of answers for correctness, reasoning, and tone across 10+ benchmarks.
That’s days of work for humans, but minutes for an LLM.

You now suddenly have the super power to run thousands of comparisons in minutes. Reduce human bias, enable rapid iteration and explore subjective criteria like “creativity” or “helpfulness” where metrics alone fall short.

LLM-based judging has already become a norm in multiple domains:

Use Case	Description
Model benchmarking	Frameworks like Arena Hard and MT-Bench use GPT-4 as the judge to rank models.
Eval pipelines	Tools like Ragas and TruLens integrate LLM-judging to score faithfulness, coherence, and relevance.
Fine-tuning and alignment	Reinforcement Learning from AI Feedback (RLAIF) replaces human feedback with LLM judgments to train new models.
Automated grading systems	Education and coding platforms use LLMs to grade free-text answers or code explanations.

LLM-as-Judge solves for critical limitations with traditional evaluation metrics:

Captures nuance: Evaluates semantic quality, not just string overlap
Scales human judgment: Automates what would otherwise require manual review
Flexible criteria: Define any custom evaluation criteria
Domain-aware: Adapts to specific use cases (medical, legal, finance, etc.)
Interpretable: Provides reasoning for verdicts, not just scores

Without scalable evaluation, progress slows down. Model quality becomes subjective. Everyone claims their model is “better,” but without consistent evals, it’s marketing, not science. Human fatigue and cost make it impossible to iterate fast. Bias creeps in. Different annotators interpret “good” differently. An LLM judge can apply consistent criteria across thousands of examples.

In short, without a judge, the AI ecosystem risks flying blind.

Think of the evaluation as a comparison pipeline:

Question: "Explain quantum computing to a 5-year-old." Model A → "It’s like magic computers that can do many things at once." Model B → "It’s a special computer that can try all possibilities at once." Judge LLM → "Model B’s answer is clearer and more accurate for a child audience." Score: Model B wins

Before your LLM judge can reliably evaluate your system, it must first align with your ground truth (human expert judgments). A misaligned judge is like a compass pointing the wrong way—every improvement based on its guidance moves you further from your goal. Ragas provides a powerful, production-ready framework for implementing LLM-as-Judge evaluation.

Let’s talk about the alignment process. First, you start by creating a baseline judge using a straightforward prompt. Then, you evaluate it against human-labeled ground truth to see how it measures up. Next, you look for patterns where the judge disagrees with the human experts. Based on these patterns, you tweak and improve the judge’s prompt. After that, you re-evaluate to see if there’s any improvement. You keep repeating this process until the alignment either levels off or reaches the standard you’re aiming for.

The strictness parameter controls consistency by running multiple evaluations with majority voting:

Value: Number of independent LLM evaluations
Mechanism: Majority voting combines results
Auto-adjustment: Automatically converts to odd numbers (1, 3, 5, 7…)

Use 2-4 for production, balancing cost and consistency.

Think of DiscreteMetric as the Swiss Army knife of LLM-based evaluation. Need to evaluate responses as “excellent,” “good,” “mediocre,” or “poor”? DiscreteMetric handles it. Want to categorize code reviews as “passes linting,” “needs minor fixes,” or “major refactoring required”? You’ve got it. The key insight is that DiscreteMetric lets you define both the evaluation prompt AND the allowed output values, making it incredibly flexible for nuanced evaluations that don’t fit neatly into binary or numeric scoring.

What makes DiscreteMetric particularly powerful is that you don’t need to subclass anything or write complex metric implementations. You just provide a prompt template (with variables you define), specify what categorical values the LLM can return, and you’re done. The LLM does the actual evaluation work using your custom prompt, and returns one of your predefined categories. This is perfect for domain-specific evaluation criteria where you need more granularity than binary but want to avoid the complexity of numeric scores.

For example, if you’re evaluating financial advice, you might want categories like “financially sound,” “incomplete,” “contains risk,” or “dangerous advice” — each with different implications for your system. Or for content moderation, you might use “safe,” “borderline,” “needs review,” and “block.” DiscreteMetric adapts to whatever categorical scheme your business needs.

import asyncio
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics import DiscreteMetric
import os

async def main():
    # Setup
    client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
    llm = llm_factory("gpt-4o-mini", client=client)

    # Define metric
    accuracy_metric = DiscreteMetric(
        name="accuracy",
        prompt="Check if the response contains points from the grading
notes.\n\nResponse: {response}\nGrading Notes: {grading_notes}",
        allowed_values=["pass", "fail"],
        llm=llm
    )

    # Evaluate
    result = await accuracy_metric.ascore(
        response="The model discussion covers DCF, comparable analysis, and VC
methods",
        grading_notes="Must cover: DCF method, comparable analysis, VC method,
founder impact"
    )

    print(f"Verdict: {result.value}")  # "pass" or "fail"
    print(f"Reason: {result.reason}")

# Run
asyncio.run(main())

Now that we understand DiscreteMetric, let’s build a complete judge evaluation pipeline from scratch.

Define Your Evaluation Criteria

Start by clearly defining what “good” means for your use case.

# Example: Evaluating financial advice quality
judge_definition = """
Evaluate if the response provides sound financial advice that covers:
1. Clear explanation of key concepts
2. Relevant metrics and calculations
3. Risk considerations
4. Tax implications where applicable
5. Practical actionable steps

Return 'pass' if all major points are covered, 'fail' if critical topics are missing.
"""

Create a Baseline Judge

Start with a simple baseline judge helps you understand the problem.

from ragas.metrics import DiscreteMetric
from openai import AsyncOpenAI
from ragas.llms import llm_factory

# Initialize LLM
client = AsyncOpenAI(api_key="sk-...")
llm = llm_factory("gpt-4o-mini", client=client)

# Create baseline judge
baseline_judge = DiscreteMetric(
    name="financial_advice_quality",
    prompt="Does the response provide sound financial advice? Check for key concepts, calculations, risks, and actionable steps.\n\nResponse: {response}",
    allowed_values=["pass", "fail"]
)

Prepare Ground Truth Data

You need human-labeled examples to measure alignment.

import pandas as pd
from ragas import Dataset

# Load your annotated data
df = pd.read_csv("expert_labels.csv")
# Expected columns: question, response, expert_judgment

dataset = Dataset(name="judge_alignment", backend="local/csv")
for _, row in df.iterrows():
    dataset.append({
        "question": row["question"],
        "response": row["response"],
        "target": row["expert_judgment"]
    })

Create Alignment Metric

Define how you measure judge alignment.

from ragas.metrics.discrete import discrete_metric
from ragas.metrics.result import MetricResult

@discrete_metric(name="judge_alignment", allowed_values=["pass", "fail"])
def judge_alignment(judge_label: str, human_label: str) -> MetricResult:
    """Compare judge decision with human label."""
    judge = judge_label.strip().lower()
    human = human_label.strip().lower()

    if judge == human:
        return MetricResult(
            value="pass",
            reason=f"Judge={judge}; Human={human}"
        )

    return MetricResult(
        value="fail",
        reason=f"Judge={judge}; Human={human}"
    )

Define Experiment Function

Orchestrate the evaluation pipeline.

from ragas import experiment
from typing import Dict, Any

@experiment()
async def judge_experiment(
    row: Dict[str, Any],
    judge_metric: DiscreteMetric,
    llm,
):
    """Run complete evaluation: Judge → Compare with human."""

    judge_score = await judge_metric.ascore(
        question=row["question"],
        response=row["response"],
        llm=llm
    )

    alignment = judge_alignment.score(
        judge_label=judge_score.value,
        human_label=row["target"]
    )

    return {
        **row,
        "judge_label": judge_score.value,
        "judge_reason": judge_score.reason,
        "alignment": alignment.value
    }

Run Baseline Evaluation

Execute the evaluation pipeline.

import asyncio
import os

async def run_baseline():
    # Load dataset
    dataset = load_dataset()
    print(f"Loaded {len(dataset)} samples")

    # Initialize LLM
    client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
    llm = llm_factory("gpt-4o-mini", client=client)

    # Run experiment
    results = await judge_experiment.arun(
        dataset,
        name="judge_baseline_v1",
        judge_metric=baseline_judge,
        llm=llm
    )

    # Calculate alignment
    passed = sum(1 for r in results if r["alignment"] == "pass")
    total = len(results)
    print(f"Alignment: {passed}/{total} ({passed/total:.1%})")

    return results

# Execute
results = asyncio.run(run_baseline())

Analyze Errors

Identify patterns in judge errors.

import pandas as pd

# Load results
df = pd.read_csv("judge_baseline_v1.csv")

# Analyze misalignments
false_positives = len(df[
    (df['judge_label'] == 'pass') & (df['target'] == 'fail')
])
false_negatives = len(df[
    (df['judge_label'] == 'fail') & (df['target'] == 'pass')
])

print(f"False positives (too lenient): {false_positives}")
print(f"False negatives (too strict): {false_negatives}")

# Look at specific error examples
errors = df[df['alignment'] == 'fail']
for idx, row in errors.head(5).iterrows():
    print(f"\nQuestion: {row['question']}")
    print(f"Judge: {row['judge_label']}, Human: {row['target']}")
    print(f"Reason: {row['judge_reason']}")

Improve Judge Prompt

Based on error patterns, create an improved judge.

# Improved prompt addressing identified issues
improved_judge = DiscreteMetric(
    name="financial_advice_quality_v2",
    prompt="""Evaluate if the response provides comprehensive financial advice.

CRITERIA:
1. ✓ Must clearly explain key financial concepts
2. ✓ Must include relevant calculations or metrics
3. ✓ Must discuss risks and tax implications
4. ✓ Must provide actionable next steps
5. ✓ Must avoid generic advice without specifics

IMPORTANT:
- Require ALL 5 criteria to be present
- Do NOT accept vague or general statements
- Accept paraphrased concepts (different wording is OK)
- If even one criterion is missing or vague, return 'fail'

Response: {response}

Are all 5 criteria clearly met in the response? Answer 'pass' or 'fail'.""",
    allowed_values=["pass", "fail"]
)

Re-run with Improved Judge

Execute with the improved version.

async def run_improved():
    dataset = load_dataset()
    client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
    llm = llm_factory("gpt-4o-mini", client=client)

    # Use improved judge
    results = await judge_experiment.arun(
        dataset,
        name="judge_improved_v2",
        judge_metric=improved_judge,
        llm=llm
    )

    passed = sum(1 for r in results if r["alignment"] == "pass")
    total = len(results)
    print(f"Improved alignment: {passed}/{total} ({passed/total:.1%})")

    return results

results = asyncio.run(run_improved())

It’s of course not a simple single step process. You gotta at least do it a few times. Keep iterating till you find that sweet spot.

You can also run multiple judges and combine results, evaluate the entire conversation flow or create your metric implementation. I’ll leave that to you to figure out. A super tip that helped me learn faster was to include examples in prompts to improve judge accuracy. Make it as verbose as you can. Avoid jargons or explain any jargons that you’re using. For example, LLM might not know what ARR means.

Best Practices

Start with Domain Experts - Ground truth quality is critical
Document Evaluation Criteria - Clear criteria prevents ambiguity
Measure Inter-Rater Reliability - Use multiple annotators to validate ground truth
Analyze Judge Performance by Category - Break down alignment by different data types
Version Control Judge Prompts - Track prompt changes for reproducibility

If you’ve more good practices to follow, add below in comments. Would love to learn more.

But Wait, Can We Trust the Judge?
LLM judges are not perfect. They inherit biases from their own training. For example:

A GPT-4 judge might favor GPT-style phrasing over open-source models.
Judges can be “prompt-sensitive”. Small wording changes may affect verdicts.
They might hallucinate reasoning for why one answer is better.

Hence, follow the best practices and keep iterating to improve your judge.

The next wave of evaluation focuses on meta-judging, evaluating the evaluators themselves.

Some emerging ideas:

Multi-LLM consensus: Multiple judges vote or debate before giving a verdict.
Grounded evals: Judges verify outputs against real data or APIs.
Human-AI hybrid evaluation: Humans handle edge cases; LLMs handle scale.

As open-source models get stronger, expect to see judge models fine-tuned for fairness and domain expertise, like “MedJudge” for medical LLMs or “CodeJudge” for programming tasks.

📚 References & Further Reading

The LLM-as-Judge approach is not about replacing humans. It’s about accelerating truth-finding.
As models grow in complexity, human evaluation alone can’t keep up. Using LLMs as judges gives us a powerful mirror, one that helps us see how far we’ve come, and how much further we can go.

“To build better intelligence, we need better ways to measure it.”
— That’s exactly what LLM-as-Judge brings to the table.

Here’s a simple diagram showing how LLM-as-Judge fits into the AI evaluation loop:

A user or testbench sends an input or question.
One or more models generate responses.
A judge LLM compares or evaluates these responses.
The verdict or score is recorded for metrics or training.
Feedback loops back to improve the model, thus closing the evaluation cycle.

The key to success is treating judge alignment as a first-class problem: invest time in understanding your data, clarifying evaluation criteria with domain experts, and systematically improving your judge prompts based on actual error patterns.

With an aligned judge as your foundation, you can confidently scale evaluation of RAG systems, agents, and any LLM application, knowing that improvements in metrics translate to real improvements in quality.

Unit Tests for Intelligence

2025-10-26T00:00:00Z

A few months ago, as I was exploring machine learning while working on a project, one of my models kept behaving in a weird way. I had built a classifier to detect cats in images. During training, accuracy was awesome, near 99%. But in production, it failed miserably. The reason? Some of my “cat” photos had the same watermark on the corner. The model wasn’t learning cats, it was learning the watermark.

It hit me then: We had no proper way to test what the model had learned. We were measuring accuracy, but not intelligence.

And that’s where the concept of AI Evals comes in, the unit tests for intelligence.

What Are “Evals”?

Evals (short for evaluations) are structured tests designed to measure how well an AI model performs on specific kinds of reasoning, understanding, or behavior.

Just like unit tests verify your functions do what you expect, evals verify your model thinks how you expect.

Analogy	Traditional Software	AI Systems
Input	Function arguments	Prompt / Input text
Logic	Deterministic code	Model reasoning (latent)
Output	Return value	Generated response
Test	Assert conditions	Evaluate metrics / compare ideal outputs

You wouldn’t ship code without tests. So why ship a model without evals?

Why Evals Matter

AI models, especially large language models (LLMs), aren’t deterministic. You can’t just run them once and say “it works.” They need to be probed, benchmarked, and stress-tested like any intelligent system.

Evals help you:

Detect regressions between model versions
Understand reasoning strengths and blind spots
Quantify subjective traits (helpfulness, creativity, bias, etc.)
Track improvements as you fine-tune or change prompts

They’re not just about performance. They’re about understanding intelligence behaviorally.

Visualizing the Flow

Let’s picture an eval as a mini experiment:

Input: what you feed the model (prompt, image, etc.)
Reasoning: the model’s internal “thought” (hidden weights, attention)
Output Check: compare the output to an expected or reference result

You can think of it like assert output == expected, but smarter. Because “expected” might not be a single string, it could be a semantic similarity, a rubric score, or a human judgment.

A Tiny Example: Logic Eval

Let’s take a toy case.

from openai import OpenAI
client = OpenAI()

def logic_eval(question, expected_answer):
    response = client.responses.create(
        model="gpt-4.1-mini",
        input=question
    )
    answer = response.output_text.strip()
    passed = (answer.lower() == expected_answer.lower())
    return {"question": question, "model_answer": answer, "passed": passed}

tests = [
    ("If all cats are animals and some animals are not cats, are all animals cats?", "No"),
    ("If A implies B and A is true, what about B?", "True"),
]

for t in tests:
    print(logic_eval(*t))

Output:

{'question': 'If all cats...', 'model_answer': 'No', 'passed': True} {'question': 'If A implies B...', 'model_answer': 'True', 'passed': True}

That’s a simple eval, a “unit test” for reasoning logic. But unlike code tests, this checks semantic understanding, not strict syntax.

Lets go a bit deeper…

Behavioral Evals

Modern evals go beyond right/wrong answers. They measure how and why a model responds.

For example:

Safety evals: “Does the model refuse unsafe instructions?”
Helpfulness evals: “Does it give contextually useful advice?”
Bias evals: “Does it favor certain groups or ideas?”
Creativity evals: “Can it reimagine a concept in a novel way?”

You might score them with:

Direct comparison to a reference answer (string match)
LLM-as-a-judge scoring (“rate from 1–5”)
Rule-based scripts
Embedding similarity metrics

So instead of just “assert true”, you now have graded intelligence.

The Evals Mindset

When you start thinking in evals, you stop asking “Is my model smart?” and start asking “How is my model smart and where does it fail?”

That shift is huge. It turns AI development from a black box into a scientific process.

Building Your Own Evals

You can start simple:

Define what to test. (reasoning, math, factual accuracy, tone)
Create a testset. (small JSON or CSV of prompt → expected)
Automate evaluation. (script or framework)
Track performance. (store metrics per model/version)

Example JSON testset:

[
  {
    "id": "logic_001",
    "input": "If X > Y and Y > Z, is X > Z?",
    "expected": "Yes"
  },
  {
    "id": "math_002",
    "input": "What’s 12 * 8?",
    "expected": "96"
  }
]

Then, a script that runs through each item and logs results. You can even compare models side by side, just like pytest results.

Frameworks to Explore

Some great open-source tools already exist:

Ragas - one of the leading evals today and wide range of llm options, integrations and metrics available. (Don’t just take my word for it cause I’m working on it. Really, give it a try!)
OpenAI Evals – the eval harness used to test GPT models
HELM (by Stanford CRFM) – holistic evaluation across domains
LangSmith / TruLens – track evals with visual dashboards

But you don’t need fancy infrastructure to start. A CSV and a few lines of Python are enough to make your first evals suite.

The Big Picture

Evals are how we bring engineering discipline to AI. They don’t just tell us if a model is “good”. They tell us how it behaves, where it fails, and why it improves.

In other words, evals are unit tests for intelligence.

And if the future of AI is about aligning machines with human values, then evals are how we write those values, in code.

Let me know how you’re exploring evals and how you see them as. 👋

Run your code anywhere

2025-10-12T00:00:00Z

Let me tell you about Vani. She’s a web development instructor teaching Node.js to a class of 30 students. Every semester, she spends the first two weeks just getting everyone’s environment set up. Some students have Windows, others have Mac, and a few brave souls are on Linux. Half of them struggle with npm permissions, a quarter get stuck with PATH issues, and there’s always that one student whose antivirus blocks Node.js installation entirely.

By the time everyone can run npm install successfully, Vani has lost two weeks of actual teaching time. And that’s just for one language. If she wants to teach Python next semester, the whole circus starts again.

Or consider Jiwan, a senior developer at a startup. He works on three different projects: a legacy app on Node.js v12, the current production app on v20, and a new experimental project on v24. He’s constantly switching between them using nvm, but sometimes he forgets to switch, and suddenly his v18 app breaks because he’s running it on v14. He’s tried Docker, but the overhead is annoying, and his M1 Mac makes Docker even slower.

Then there’s the open-source maintainer who wants to add a “Try it now” button to their project’s README. They want people to click and immediately play with the code, no installation required. But setting up a server to run user code safely is expensive and complicated. How do you sandbox untrusted code? How do you prevent someone from mining Bitcoin on your servers? How do you prevent some hidden script to steal all your passwords and if you’ve wallet linked, all your hard earned money? How do you scale when your project goes viral on Hacker News?

These aren’t edge cases. These are everyday problems that developers face. We’ve been solving them the same way for decades: install runtimes locally, manage versions manually, hope nothing conflicts, and pray that “works on my machine” actually works on theirs too.

A simple solution came up in the form of containers. Docker is almost a household tool found in every other project and sometimes too often as recommended way to develop. Various orchestration have come up in the recent years and the entire devops heavy infra became a norm, of which we’re part of today. I’m not saying dockers of this world are a pain, but I can tell you no dev, while building wants to run heavy containers just to keep checking if it’s compatible in various machines.

What if Code Could Just Run?

Imagine opening a browser and running any project without installing anything. No Node.js download, no Python virtual environments, no Go toolchain, no dependency hell. Just open a URL and start coding.

Sounds like science fiction? It’s not. StackBlitz already does this with their WebContainers. You can run full Node.js applications entirely in your browser. The server just serves static files. Everything executes client-side in WebAssembly.

But WebContainers are proprietary and focused on their IDE. What if we could have this capability as a standalone tool? What if it worked for any language, not just JavaScript? What if it was open source and you could either build or request the community for features specific to your needs?

That’s why we’re building wasmrun OS.

The Teacher’s Dream

Remember Vani? With wasmrun OS mode, she could teach Python next semester by just changing one parameter. The same environment, the same interface, different language. Her students could focus on learning programming, not fighting with their computers.

One student doesn’t have a laptop? They can use the library computer. Another student’s computer is locked down by corporate IT? Doesn’t matter - it runs in the browser. The playing field is level.

The Developer’s Sanity

Jiwan’s life gets simpler too. Each project specifies its Node.js version in package.json. wasmrun OS mode reads it and loads exactly that version - v14, v18, v20, whatever. No more nvm, no more “which version am I on again?”, no more conflicts.

He opens his legacy project, it runs on v14. He switches to production, it automatically loads v18. He experiments with the new features, v20 is there. Different projects, different versions, zero mental overhead.

Better yet, everything runs in isolation. If his experimental project crashes spectacularly, it doesn’t affect anything else. No stray processes, no port conflicts, no leftover node_modules pollution. Clean slate every time.

Play around with code more

First-time contributor wants to fix a bug in an open source project? Run it with wasmrun, see the code running, make their changes, verify the fix works, submit a PR. They never installed anything. The barrier to contribution just dropped to almost zero.

The Student Learning to Code

Ankita is learning web development. She’s 16 and uses her school’s Chromebook. She can’t install anything. The device is locked down. But she can open a browser.

Her online course uses wasmrun OS. She’s building a REST API in Node.js. She’s never touched Node.js before. She doesn’t know what npm is. She doesn’t need to. The environment handles it. She can focus on learning Express routes, not fighting with npm or bun or pnpm or yarn debate.

Next week, she’s learning Python and Flask. Same environment, same interface, different language. No cognitive load from different tools. Just learning.

The Company Running Code Safely

A startup builds a platform where users submit data processing scripts. These scripts need to run, but they’re untrusted code. What if someone writes an infinite loop? What if they try to access the file system? What if they attempt to make network requests to exfiltrate data?

Traditional solution: spin up Docker containers, set strict resource limits, monitor everything, deal with cold starts, pay for idle containers, hope your sandboxing is bulletproof.

With wasmrun OS: user submits code, it runs in a WebAssembly sandbox in their own browser. It has zero access to the host system. It can’t make network requests unless explicitly allowed. It can’t access real files. When it’s done, it’s gone. No servers strained, no security nightmares, no infrastructure costs for running user code.

The startup’s servers? They just coordinate and store results. The heavy lifting happens client-side.

The Conference Workshop

Arko is running a workshop at a developer conference. He’s teaching 200 people how to build microservices with Go. In the past, he’d spend the first 30 minutes helping people install Go, set GOPATH, troubleshoot compiler errors on Windows.

Now? “Everyone run with wasmrun.” That’s it. Two minutes later, everyone has an identical Go development environment. Different laptops, different operating systems, same environment.

Halfway through, he realizes he should have used a different Go version. He updates one configuration file, tells everyone to refresh. Done. Everything rebuilds as per the new specs now.

The Offline Developer

Puja is an adventure junkie programmer. She’s currently in a cabin in rural Vietnam with spotty internet. She’s gonna go for a deep dive the next morning. She loaded wasmrun OS mode yesterday when she had good wifi in the city. The browser cached the Node.js v20 runtime - all 50MB of it.

Now she’s offline, but she’s still coding. The runtime is cached, her project files are in the browser, and everything works. She’s building a REST API, running tests, seeing live results. No internet required.

When she gets back to civilization, she’ll push her code to GitHub. But for now, she’s productive in the middle of nowhere.

So, how does wasmrun OS actually work?

The Traditional Way

Normally, when you run Node.js code:

You install Node.js on your operating system
Your code runs as a process managed by your OS
It accesses your real file system
It makes real network requests
It can do anything your user account can do

This works, but it’s heavy and risky. Heavy because you need the full runtime installed. Risky because the code has real access to your system.

The wasmrun Way

With wasmrun OS mode:

The browser downloads a tiny kernel (2-3MB of WebAssembly)
This kernel is like a mini operating system running in your browser
When you run a Node.js project, the kernel downloads the Node.js runtime (50MB, but cached)
Your code runs inside this Node.js runtime, which runs inside the kernel, which runs in WebAssembly, which runs in your browser. (No, I wasn’t thinking of inception, you were!)
It’s sandboxed at every level

Think of it like Russian nesting dolls, but for code execution environments. Best part, you don’t even need to think about any of it.

The kernel is the brain. It manages:

Processes: Each project you run gets a unique process ID, just like in a real OS
File system: A virtual file system that exists only in browser memory
Scheduling: If you run multiple projects, it schedules CPU time between them
Syscalls: When your code wants to read a file or make a network request, the kernel handles it

It’s written in Rust and compiled to WebAssembly. It’s tiny, fast, and secure. All development is in public built as open source project.

The kernel doesn’t run your JavaScript or Python directly. It loads language-specific runtimes:

Node.js runtime: A full Node.js environment compiled to WebAssembly. It includes V8 (the JavaScript engine), the Node.js APIs (fs, http, etc.), and npm support. When it needs to read a file, it asks the kernel. When it needs to make a network request, the kernel intercepts it and uses browser’s APIs like capability APIs.

Python runtime: CPython compiled to WebAssembly, with pip support. Same idea - it talks to the kernel for system operations. Kinda similar to how pyodide works, but we’re running inside a controlled container, so the runtime approach is quite different and configurable with a range of language plugins.

Go runtime: Go programs (tinygo) can already compile to WebAssembly, so this one’s simpler. The Go code compiles directly, and the kernel provides the syscall interface.

Version Management

Here’s the clever part: your package.json might say:

{
  "engines": {
    "node": ">=18.0.0"
  }
}

wasmrun OS mode reads this. It checks what Node.js versions are available. It picks v20 (the latest LTS that satisfies >=18). It checks if v20 is cached in your browser. If yes, loads it instantly. If no, downloads it once and caches it forever. Of course you can clear the cache anytime you want. I’d not want to keep nodejs v8 till today myself.

Next time you run any project that needs v20, it’s instant - already cached.

If you run a project that needs v18, it downloads and caches v18 separately. Now you have both cached. Switching between projects with different versions? Instant. No nvm, no version management, it just works.

The File System

Your project has files. Your code reads and writes them. But there’s no real file system in a browser.

wasmrun OS mode creates a virtual file system that connects with your original files using a variation of wasi filesystem. It’s just data structures in memory. When you mount your project, it loads all your files into this virtual FS. When your code does fs.readFile('package.json'), the kernel intercepts it and reads from virtual memory.

You can edit files in the browser UI, and your code sees the changes immediately. Anytime the code is edited, it hooks to the original code and updates that immediately as well.

For persistence, it can sync to IndexedDB. Close the browser, come back tomorrow, your files are still there.

If you don’t like browser UI, edit with neovim or vs code or cursor. If you edit the original code directly, the hot-loading will immediately serve the new build. wasmrun is currenty based on AOT(Ahead-of-Time) compiler. However, some interest in JIT compilers is under discussion and consideration.

The Security Model

Everything runs in WebAssembly. WebAssembly is sandboxed by design - it can’t escape the browser. Your code can’t:

Access your real file system
Make arbitrary network requests (unless the kernel allows it)
Run system commands
Access your webcam or microphone
Steal your cookies

It’s as secure as running code can be. Even if you run malicious code, it’s trapped in the WebAssembly sandbox. When you close the tab, it’s gone.

The Current State: Experimental and Evolving

Let’s be honest: this is ambitious. We’re essentially building an operating system in WebAssembly. We’re not done yet.

What Works Today

If you try wasmrun OS mode right now with latest wasmrun v0.13.0, you’ll get:

A working micro-kernel with process management
A virtual WASI file system you can browse
Project auto-detection (Node.js, Python, Go, Rust)
A development server that starts for your project
A browser UI with file explorer and kernel dashboard
HTTP proxying to your running application

It works. You can run a project, see it execute, browse files, and interact with it.

Why Open Source Matters

wasmrun is open source. The entire OS mode implementation is on GitHub. You can read every line of code. You can see exactly how it works.

This matters because:

Trust: You’re running code in your browser. You should be able to verify it’s safe.

Collaboration: This is a big project. We need help. Maybe you’re good at WebAssembly. Maybe you know how Node.js internals work. Maybe you’re amazing at documentation. There’s a place for you.

Innovation: The best ideas come from diverse perspectives. We’ve designed it one way, but maybe you see a better approach. Open source means you can propose it, implement it, and improve it for everyone.

Longevity: Companies pivot. Projects get abandoned. Open source means wasmrun will live as long as people find it useful.

We’re actively developing this, and we’d love your help.

If You’re a Developer

Contribute code: Check the GitHub issues. There’s lots to build.
Review architecture: Read the code and tell us where we can improve.
Test it: Try breaking it. Find bugs. Report them.
Integrate runtimes: Know how to get Node.js running in WASM? We need that expertise.
Optimize performance: Make it faster. Every millisecond counts.

If You’re a Tech Writer

Documentation: We need clear guides for users and contributors.
Tutorials: “Build a REST API with wasmrun OS mode” - someone needs to write this.
Architecture docs: Explain the system in ways people can understand.

If You’re a Designer

UI/UX improvements: The browser interface works, but it could be beautiful.
Branding: Help us look professional.
Accessibility: Make sure everyone can use it.

If You’re an Educator

Try it in your class: Give us feedback on what works and what doesn’t.
Create courses: Build educational content using wasmrun OS mode.
Spread the word: Tell other teachers about it.

If You’re a User

Star the repo: GitHub stars help with visibility.
Share your story: How would wasmrun OS mode help you?
Report issues: Found a bug? Tell us.
Feature requests: What do you need that we haven’t built yet?

The Vision Forward

Imagine a world where:

“Install Node.js” is no longer step one of every tutorial
Code examples in documentation are runnable with one click
Students learn programming without fighting their environment
Developers switch between projects and versions effortlessly
Running untrusted code is safe by default
Every computer with a browser is a full development environment

This isn’t fantasy. The technology exists. WebAssembly is here. Browsers are powerful. We just need to wire it all together.

wasmrun is our attempt to build this future. It’s experimental, it’s ambitious, and it’s not done. But it’s real, it’s happening, and you can be part of it.

We’re building an operating system for code. An operating system that runs anywhere a browser runs. An operating system that makes programming accessible to everyone.

Come help us build it.

Create your own wasm plugin

2025-09-10T00:00:00Z

In this first article in this series, we went through all different rust plugins, the previous one, we understood the wasmrun plugin architecture. Here’s we’ll learn how to create your own wasm plugin which you can run using wasmrun.

Creating wasm plugins, is not limited to wasmrun plugins alone, they can be quite useful in distributing as independent modules as well. What’s currently lacking today is an open ecosystem, which is surprising given all the developement is quite open. Limited is a better word for it rather. So, consider this more of a guide to building your next wasm project, and to get it to work in the larger wasm ecosystem. Making it open or close is upto you. Currently, I’ve only made it work with published crates, however was testing local plugins as well. So, in case you’re also interested in contrubuting, feel free to work on it.

Plugins were introduced in wasmrun v0.8.2 for first time. However, the structural final changes before making it stable only achieved by v0.11.3. So, make sure you’ve the right crate version installed.

Creating Your Own Plugin

Creating a wasmrun plugin involves implementing the required traits and exposing them through FFI for external plugins.

Create a New Rust Project

# Create a new library crate cargo new --lib wasmcustomlang cd wasmcustomlang # Add wasmrun as a dependency cargo add wasmrun

Configure Cargo.toml

[package]
name = "wasmcustomlang"
version = "0.1.0"
edition = "2021"
description = "Custom language plugin for wasmrun"
license = "MIT"
keywords = ["wasm", "webassembly", "plugin", "wasmrun"]

[lib]
name = "wasmcustomlang"
crate-type = ["cdylib", "rlib"]  # Both dynamic and static library

[dependencies]
wasmrun = "0.10"
libc = "0.2"

[[bin]]
name = "wasmrun-wasmcustomlang"  # Fallback binary
path = "src/main.rs"

Implement the Plugin Traits

use wasmrun::plugin::{Plugin, WasmBuilder, PluginInfo, Dependencies};
use wasmrun::error::Result;
use std::path::Path;

pub struct CustomLangPlugin;

impl Plugin for CustomLangPlugin {
    fn name(&self) -> &str {
        "customlang"
    }

    fn supported_extensions(&self) -> Vec<String> {
        vec!["custom".to_string(), "cl".to_string()]
    }

    fn can_handle_project(&self, project_path: &str) -> bool {
        let path = Path::new(project_path);
        path.join("main.custom").exists() || 
        path.join("customlang.toml").exists()
    }

    fn get_builder(&self, _project_path: &str) -> Result<Box<dyn WasmBuilder>> {
        Ok(Box::new(CustomLangWasmBuilder::new()))
    }

    fn get_info(&self) -> PluginInfo {
        PluginInfo {
            name: "customlang".to_string(),
            version: "0.1.0".to_string(),
            description: "Custom language WebAssembly compiler".to_string(),
            author: "Your Name <email@example.com>".to_string(),
            extensions: vec!["custom".to_string(), "cl".to_string()],
            capabilities: vec![
                "compile".to_string(), 
                "watch".to_string(),
                "web".to_string()
            ],
            dependencies: Dependencies {
                tools: vec!["customlang-compiler".to_string()],
                optional_tools: vec!["customlang-optimizer".to_string()],
            },
        }
    }
}

pub struct CustomLangWasmBuilder {
    plugin_info: PluginInfo,
}

impl CustomLangWasmBuilder {
    pub fn new() -> Self {
        Self {
            plugin_info: CustomLangPlugin.get_info(),
        }
    }
}

impl WasmBuilder for CustomLangWasmBuilder {
    fn build(&self, project_path: &str, output_path: &str) -> Result<String> {
        // Your custom compilation logic here
        let main_file = Path::new(project_path).join("main.custom");
        let output_file = Path::new(output_path).join("output.wasm");

        // Example: Call your custom compiler
        let output = std::process::Command::new("customlang-compiler")
            .args([
                "--input", &main_file.to_string_lossy(),
                "--output", &output_file.to_string_lossy(),
                "--target", "wasm32"
            ])
            .output()?;

        if output.status.success() {
            Ok(output_file.to_string_lossy().to_string())
        } else {
            Err(wasmrun::error::WasmrunError::from("Custom lang compilation failed"))
        }
    }

    fn build_for_web(&self, project_path: &str, output_path: &str) -> Result<String> {
        // Web-specific build logic
        self.build(project_path, output_path)
    }

    fn clean(&self, project_path: &str) -> Result<()> {
        // Clean build artifacts
        let build_dir = Path::new(project_path).join("build");
        if build_dir.exists() {
            std::fs::remove_dir_all(build_dir)?;
        }
        Ok(())
    }

    fn get_wasm_file(&self, project_path: &str) -> Result<String> {
        // Return the main WASM file path
        let wasm_file = Path::new(project_path).join("build").join("output.wasm");
        Ok(wasm_file.to_string_lossy().to_string())
    }
}

Implement FFI Interface

use std::ffi::{CString, CStr, c_char, c_void};
use std::ptr;

static mut GLOBAL_PLUGIN: Option<CustomLangPlugin> = None;
static mut GLOBAL_BUILDER: Option<CustomLangWasmBuilder> = None;

// FFI exports for dynamic loading
#[no_mangle]
pub extern "C" fn create_wasm_builder() -> *mut c_void {
    unsafe {
        GLOBAL_BUILDER = Some(CustomLangWasmBuilder::new());
        GLOBAL_BUILDER.as_mut().unwrap() as *mut _ as *mut c_void
    }
}

#[no_mangle]
pub extern "C" fn can_handle_project(builder: *mut c_void, path: *const c_char) -> bool {
    if builder.is_null() || path.is_null() {
        return false;
    }

    unsafe {
        let plugin = CustomLangPlugin;
        let c_str = CStr::from_ptr(path);
        if let Ok(path_str) = c_str.to_str() {
            plugin.can_handle_project(path_str)
        } else {
            false
        }
    }
}

#[no_mangle]
pub extern "C" fn build_project(
    builder: *mut c_void, 
    project_path: *const c_char, 
    output_path: *const c_char
) -> *const c_char {
    if builder.is_null() || project_path.is_null() || output_path.is_null() {
        return ptr::null();
    }

    unsafe {
        let c_project = CStr::from_ptr(project_path);
        let c_output = CStr::from_ptr(output_path);

        if let (Ok(project_str), Ok(output_str)) = (c_project.to_str(), c_output.to_str()) {
            let builder_ref = &*(builder as *mut CustomLangWasmBuilder);
            if let Ok(result) = builder_ref.build(project_str, output_str) {
                let c_result = CString::new(result).unwrap();
                return c_result.into_raw();
            }
        }
        ptr::null()
    }
}

#[no_mangle]
pub extern "C" fn get_plugin_info() -> *const c_char {
    let plugin = CustomLangPlugin;
    let info = plugin.get_info();
    
    if let Ok(json) = serde_json::to_string(&info) {
        let c_string = CString::new(json).unwrap();
        c_string.into_raw()
    } else {
        ptr::null()
    }
}

// Cleanup function.
#[no_mangle]
pub extern "C" fn cleanup_string(ptr: *mut c_char) {
    if !ptr.is_null() {
        unsafe {
            let _ = CString::from_raw(ptr);
        }
    }
}

(Optional) Create Binary

Another easier approach for plugin extensions was to create and distribute the binary. Binaries could have ran independently with no compatibility issues. I prefer binary is secondary, not primary. However, binary are great to test and develop with.

// src/main.rs
use wasmcustomlang::CustomLangPlugin;
use wasmrun::plugin::Plugin;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let args: Vec<String> = std::env::args().collect();
    
    if args.len() < 2 {
        eprintln!("Usage: {} <command> [args...]", args[0]);
        std::process::exit(1);
    }

    let plugin = CustomLangPlugin;
    
    match args[1].as_str() {
        "can-handle" => {
            if args.len() < 3 {
                eprintln!("Usage: {} can-handle <project-path>", args[0]);
                std::process::exit(1);
            }
            let can_handle = plugin.can_handle_project(&args[2]);
            println!("{}", can_handle);
        }
        "build" => {
            if args.len() < 4 {
                eprintln!("Usage: {} build <project-path> <output-path>", args[0]);
                std::process::exit(1);
            }
            let builder = plugin.get_builder(&args[2])?;
            let result = builder.build(&args[2], &args[3])?;
            println!("{}", result);
        }
        "info" => {
            let info = plugin.get_info();
            let json = serde_json::to_string_pretty(&info)?;
            println!("{}", json);
        }
        _ => {
            eprintln!("Unknown command: {}", args[1]);
            std::process::exit(1);
        }
    }

    Ok(())
}

Build and Test Locally

# Build the plugin cargo build --release # Test that it builds correctly cargo test # Create a test project mkdir test-project echo 'fn main() { println!("Hello from CustomLang!"); }' > test-project/main.custom # Test the plugin locally cargo run -- can-handle test-project cargo run -- build test-project ./output cargo run -- info

Plugin Distribution

Publish to crates .io

# Login to crates.io cargo login # Publish the plugin cargo publish

Plugin Metadata in Cargo.toml

For better wasmrun integration, you can add wasmrun-specific metadata to your Cargo.toml:

[package.metadata.wasm_plugin]
name = "customlang"
version = "0.1.0"
description = "Custom language WebAssembly compiler"
author = "Your Name <email@example.com>"
extensions = ["custom", "cl"]
entry_files = ["main.custom", "customlang.toml"]

[package.metadata.wasm_plugin.capabilities]
compile_wasm = true
compile_webapp = true
live_reload = true
optimization = true
custom_targets = ["wasm32-unknown-unknown"]
supported_languages = ["customlang"]  # Explicit language support declaration
# For multi-language plugins: supported_languages = ["rust", "zig"]
# If there's variations in same language, better to add each as separate langugage.

[package.metadata.wasm_plugin.dependencies]
tools = ["customlang-compiler"]
optional_tools = ["customlang-optimizer"]

[package.metadata.wasm_plugin.exports]
create_wasm_builder = "create_wasm_builder"
can_handle_project = "customlang_can_handle_project"
build = "customlang_build"
clean = "customlang_clean"
clone_box = "customlang_clone_box"
drop = "customlang_drop"
plugin_create = "wasmrun_plugin_create"

[package.metadata.wasm_plugin.frameworks]
supported = ["custom-framework"]
auto_detect = true

Plugin Management

Install and Use with Wasmrun

# Install your plugin wasmrun plugin install wasmcustomlang # Use it with a project wasmrun ./my-custom-project wasmrun compile ./my-custom-project --language customlang

Plugin Metadata Management

Plugin metadata is stored in several places:

~/.wasmrun/plugins/{name}/.wasmrun_metadata - Plugin information
~/.wasmrun/config.toml - Global plugin registry
Plugin’s Cargo.toml - Source metadata

Example metadata file:

{
  "name": "customlang",
  "version": "0.1.0", 
  "description": "Custom language WebAssembly compiler",
  "author": "Your Name <email@example.com>",
  "extensions": ["custom", "cl"],
  "entry_files": ["main.custom", "customlang.toml"],
  "capabilities": {
    "compile_wasm": true,
    "compile_webapp": true,
    "live_reload": true,
    "optimization": true,
    "custom_targets": ["wasm32-unknown-unknown"],
    "supported_languages": ["customlang"]
  },
  "dependencies": {
    "tools": ["customlang-compiler"],
    "optional_tools": ["customlang-optimizer"]
  }
}

Plugin Management Commands

# List installed plugins wasmrun plugin list # Install a plugin wasmrun plugin install wasmrust # Uninstall a plugin wasmrun plugin uninstall wasmrust # Update a plugin wasmrun plugin update wasmrust # Show plugin info wasmrun plugin info wasmrust

Best Practices for Plugin Development

Error Handling

Always provide clear error messages and handle edge cases:

impl WasmBuilder for CustomLangWasmBuilder {
    fn build(&self, project_path: &str, output_path: &str) -> Result<String> {
        // Validate inputs
        if !Path::new(project_path).exists() {
            return Err(WasmrunError::from("Project path does not exist"));
        }

        // Check for required tools
        if !which::which("customlang-compiler").is_ok() {
            return Err(WasmrunError::from(
                "customlang-compiler not found. Please install CustomLang toolchain."
            ));
        }

        // Your build logic...
    }
}

Project Detection

Make project detection robust and specific:

fn can_handle_project(&self, project_path: &str) -> bool {
    let path = Path::new(project_path);
    
    // Check for specific files
    if path.join("customlang.toml").exists() {
        return true;
    }
    
    // Check for file patterns
    if let Ok(entries) = std::fs::read_dir(path) {
        for entry in entries.flatten() {
            if let Some(ext) = entry.path().extension() {
                if ext == "custom" {
                    return true;
                }
            }
        }
    }
    
    false
}

Dependency Management

Check for dependencies and provide helpful error messages:

fn check_dependencies() -> Vec<String> {
    let mut missing = Vec::new();
    
    if !which::which("customlang-compiler").is_ok() {
        missing.push("customlang-compiler".to_string());
    }
    
    missing
}

Testing

Write comprehensive tests for your plugin. Try to increase coverage and also check all cases:

#[cfg(test)]
mod tests {
    use super::*;
    use tempdir::TempDir;

    #[test]
    fn test_can_handle_project() {
        let tmp_dir = TempDir::new("test").unwrap();
        let project_path = tmp_dir.path();
        
        // Create test file
        std::fs::write(project_path.join("main.custom"), "test content").unwrap();
        
        let plugin = CustomLangPlugin;
        assert!(plugin.can_handle_project(project_path.to_str().unwrap()));
    }

    #[test]
    fn test_plugin_info() {
        let plugin = CustomLangPlugin;
        let info = plugin.get_info();
        
        assert_eq!(info.name, "customlang");
        assert!(info.extensions.contains(&"custom".to_string()));
    }
}

Common Issues and Solutions

Dynamic Library Loading Issues

When you try to load the plugin, you might encounter an error message saying that the library cannot be found. This issue is quite common and can be frustrating, especially if you’re not sure where things are going wrong. The error typically occurs because the system is unable to locate the necessary library files that the plugin depends on. This can happen if the library paths are not set correctly or if the library files are not named properly. To resolve this issue, you should first double-check that the library search paths are correctly configured. This involves ensuring that the directories where the libraries are stored are included in the system’s library path environment variables. Additionally, make sure that the library files are named correctly according to the system’s conventions. Sometimes, simply renaming a library file to match the expected naming pattern can solve the problem. By taking these steps, you can help the system locate the necessary libraries and successfully load the plugin without any errors.

// In your plugin loading code
let lib_paths = vec![
    format!("lib{}.dylib", plugin_name),      // macOS
    format!("lib{}.so", plugin_name),         // Linux  
    format!("{}.dll", plugin_name),           // Windows
];

ABI Compatibility

When a plugin crashes due to an ABI mismatch, it can be quite a headache to deal with. ABI, or Application Binary Interface, refers to the way different program modules communicate at the binary level. If there’s a mismatch, it means that the plugin and the host application are not able to communicate properly, leading to crashes or unexpected behavior. This often happens when the plugin and the application are built with different compiler versions or settings, or when there have been changes in the data structures or function signatures that they use to interact. It’s important to use stable ABI-compatible interfaces. This means designing your plugin and application interfaces in a way that remains consistent across different versions and compiler settings. One effective strategy is to implement version checking. By including version information in your interfaces, you can ensure that the plugin only loads if it matches the expected version of the application. This helps prevent crashes by ensuring that both the plugin and the application are using compatible interfaces. Additionally, it’s a good practice to document any changes in the ABI and communicate these changes to developers who might be using your plugin, so they can make the necessary adjustments on their end.

#[no_mangle]
pub extern "C" fn plugin_abi_version() -> u32 {
    1 // Increment when ABI changes
}

Memory Management

When dealing with memory leaks or crashes at the FFI boundary, it can be quite challenging to pinpoint the exact cause. These issues often arise because of improper handling of memory allocation and deallocation, which can lead to resources not being freed correctly or being accessed after they have been freed. This can cause unexpected behavior or crashes, especially when different languages with different memory management models are involved. It’s crucial to ensure proper memory cleanup and ownership management. This means clearly defining who is responsible for allocating and freeing memory, and sticking to these rules consistently. For example, if your plugin allocates memory, it should also be responsible for freeing it, unless there is a clear agreement that the host application will take over this responsibility. Additionally, using smart pointers or reference counting can help manage ownership and prevent memory leaks. It’s also beneficial to implement thorough testing and debugging practices to catch any memory-related issues early in the development process. By doing so, you can maintain a stable and reliable interface between your plugin and the host application, minimizing the risk of memory leaks or crashes.

#[no_mangle]
pub extern "C" fn cleanup_string(ptr: *mut c_char) {
    if !ptr.is_null() {
        unsafe {
            let _ = CString::from_raw(ptr);
        }
    }
}

Now, you know how to create your very own wasm plugin. Would love to have more community plugins. 🙌

Even if you’re not building one, if you’ve an idea that you’d like to use, feel free to open an issue and let us know about it. 🚀

Wasmrun Plugin Architecture

2025-09-05T00:00:00Z

In the last article, I covered all different types of rust plugin architecture and approaches we could have done. Now, lets dive into the plugin architecture used in wasmrun, an open-source WebAssembly runtime that supports multiple programming languages through a hybrid plugin system.

Why Plugins in Wasmrun

Wasmrun intends to support multiple programming languages like Rust, Go, C/C++, AssemblyScript, Python and each language has its own:

Compilation toolchain (rustc, tinygo, emcc, asc, py2wasm)
Project structure conventions (Cargo.toml, go.mod, Makefile, package.json)
Optimization strategies and output formats
Development workflow requirements

Initially, we had all language support built directly into the binary:

// This was getting unwieldy fast
match language {
    "c" => compile_c_project(path),
    "cpp" => compile_cpp_project(path),
    "assemblyscript" => compile_as_project(path),
    "python" => compile_python_project(path),
    // External plugins would require subprocess calls
    "rust" => subprocess_plugin("wasmrust", path),
    "go" => subprocess_plugin("wasmgo", path),
    // ... and growing
}

The issues became clear:

Monolithic binary - Every user had to download support for all languages
Tight coupling - Adding new language support required core changes
Testing complexity - Each language change could break others
Community contributions - External developers couldn’t easily add language support

`wasmrun` Implementation: Hybrid Built-in + External

Initially I started with trying to extend usage with same Traits to external as built-in plugins which would have made creating external plugins easy and also the migration process. However, it soon became an ant hill of issues. A good approach in this would have been to create a common wasmrun_core crate and import for both. However, I want to keep things at minimal changes and not introduce a new dependency so as to increase wasmrun maintainability before testing the concept. Another easy option was to run the external plugins as binary directly. However, this would have reduced the customisations that you’d be able to do on the runtime itself. A version of me would argue that this should have been the safest first step, but who cares about playing safe.

After evaluating different approaches, I settled on a hybrid system that combines the benefits of multiple strategies:

Built-in plugins using trait objects for core language support
External plugins using FFI for extensibility
Fallback subprocess execution when FFI loading fails. We’ll remove this in future as we move to more tested approach.

This gives us type safety and performance for core functionality, while still allowing runtime extensibility.

The Trait Foundation

The key insight was to design traits that work identically for both built-in and external plugins:

// src/plugin/mod.rs
pub trait Plugin: Send + Sync {
    fn info(&self) -> &PluginInfo;
    fn can_handle_project(&self, project_path: &str) -> bool;
    fn get_builder(&self) -> Box<dyn WasmBuilder>;
}

// src/compiler/builder.rs
pub trait WasmBuilder: Send + Sync {
    fn language_name(&self) -> &str;
    fn entry_file_candidates(&self) -> &[&str];
    fn supported_extensions(&self) -> &[&str];
    fn check_dependencies(&self) -> Vec<String>;
    fn build(&self, config: &BuildConfig) -> CompilationResult<BuildResult>;
    fn validate_project(&self, project_path: &str) -> CompilationResult<()>;
    fn can_handle_project(&self, project_path: &str) -> bool;
    fn clean(&self, project_path: &str) -> Result<()>;
    fn clone_box(&self) -> Box<dyn WasmBuilder>;
}

Plugin Information Structure

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct PluginInfo {
    pub name: String,
    pub version: String,
    pub description: String,
    pub author: String,
    pub extensions: Vec<String>,
    pub entry_files: Vec<String>,
    pub plugin_type: PluginType,
    pub source: Option<PluginSource>,
    pub dependencies: Vec<String>,
    pub capabilities: PluginCapabilities,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct PluginCapabilities {
    pub compile_wasm: bool,
    pub compile_webapp: bool,
    pub live_reload: bool,
    pub optimization: bool,
    pub custom_targets: Vec<String>,
    pub supported_languages: Option<Vec<String>>,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum PluginSource {
    CratesIo { name: String, version: String },
    Git { url: String, branch: Option<String> },
    Local { path: PathBuf },
}

Built-in Plugins: The Foundation

Built-in plugins are straightforward. They’re just structs implementing the traits, compiled directly into the binary. The current built-in plugins are C/C++, AssemblyScript, and Python. Earlier rust and go were also built-in but have successfully migrated them external. Soon the plan is to move all language built-in plugins to external.

// src/plugin/languages/c_plugin.rs
#[derive(Clone)]
pub struct CPlugin {
    info: PluginInfo,
}

impl CPlugin {
    pub fn new() -> Self {
        let info = PluginInfo {
            name: "c".to_string(),
            version: env!("CARGO_PKG_VERSION").to_string(),
            description: "C WebAssembly compiler using Emscripten".to_string(),
            author: "Wasmrun Team".to_string(),
            extensions: vec!["c".to_string(), "h".to_string()],
            entry_files: vec!["main.c".to_string(), "Makefile".to_string()],
            plugin_type: PluginType::Builtin,
            source: None,
            dependencies: vec![],
            capabilities: PluginCapabilities {
                compile_wasm: true,
                compile_webapp: true,
                live_reload: true,
                optimization: true,
                custom_targets: vec!["wasm".to_string(), "web".to_string()],
                supported_languages: Some(vec!["c".to_string(), "cpp".to_string()]),
            },
        };
        Self { info }
    }
}

impl Plugin for CPlugin {
    fn info(&self) -> &PluginInfo {
        &self.info
    }

    fn can_handle_project(&self, project_path: &str) -> bool {
        let path = Path::new(project_path);
        // Check for Makefile or main.c files
        path.join("Makefile").exists() || path.join("main.c").exists()
    }

    fn get_builder(&self) -> Box<dyn WasmBuilder> {
        Box::new(CWasmBuilder::new())
    }
}

Built-in Plugin Loading

All built-in plugins are loaded through a centralized system:

// src/plugin/builtin.rs
pub fn load_all_builtin_plugins(plugins: &mut Vec<Box<dyn Plugin>>) -> Result<()> {
    // C plugin
    let c_plugin = Arc::new(CPlugin::new());
    plugins.push(Box::new(BuiltinPlugin::new(c_plugin)));

    // AssemblyScript plugin
    let asc_plugin = Arc::new(AscPlugin::new());
    plugins.push(Box::new(BuiltinPlugin::new(asc_plugin)));

    // Python plugin
    let python_plugin = Arc::new(PythonPlugin::new());
    plugins.push(Box::new(BuiltinPlugin::new(python_plugin)));

    Ok(())
}

External Plugins: The Interesting Part

External plugins are where things get interesting. The challenge was making them feel identical to built-in plugins while being loaded dynamically.

The `cargo install` approach

I wanted plugin installation to feel familiar to Rust developers:

Download: Uses cargo install to build the plugin
Storage: Installs to ~/.wasmrun/plugins/{plugin_name}/
Registration: Updates wasmrun config with plugin capabilities as mentioned in the plugin Cargo.toml
Ready: Plugin automatically handles supported projects

// src/plugin/installer.rs
pub fn install_plugin(plugin_name: &str) -> Result<InstallationResult> {
    // Validate plugin exists on crates.io
    if !PluginRegistry::validate_plugin(plugin_name)? {
        return Err(WasmrunError::from(format!("Plugin '{plugin_name}' not found")));
    }

    let wasmrun_root = dirs::home_dir()
        .ok_or("Could not determine home directory")?
        .join(".wasmrun");

    // Install using cargo to ~/.wasmrun/
    let output = std::process::Command::new("cargo")
        .args([
            "install", 
            plugin_name, 
            "--root", 
            &wasmrun_root.to_string_lossy()
        ])
        .output()?;

    if !output.status.success() {
        return Err(WasmrunError::from("Plugin installation failed"));
    }

    // Create plugin directory and metadata
    let plugin_dir = wasmrun_root.join("plugins").join(plugin_name);
    std::fs::create_dir_all(&plugin_dir)?;

    // Extract metadata from Cargo.toml
    let metadata = extract_plugin_metadata(plugin_name)?;
    save_plugin_metadata(&plugin_dir, &metadata)?;

    // Update wasmrun config
    update_plugin_config(plugin_name, &metadata)?;

    Ok(InstallationResult::Success)
}

Plugin Directory Structure

~/.wasmrun/ ├── bin/ # Plugin binaries installed via cargo │ ├── wasmrust # Plugin executable │ └── wasmgo # Plugin executable ├── plugins/ # Plugin metadata and dynamic libraries │ ├── wasmrust/ │ │ ├── .wasmrun_metadata │ │ ├── libwasmrust.dylib # Dynamic library (optional) │ │ └── target/ │ │ └── release/ │ │ └── libwasmrust.dylib │ └── wasmgo/ │ ├── .wasmrun_metadata │ └── libwasmgo.dylib └── config.toml # Plugin registry and configuration

FFI and Dynamic Loading

External plugins are loaded as dynamic libraries using Rust’s Foreign Function Interface (FFI). This approach provides several advantages:

Performance: Direct function calls instead of subprocess execution
Integration: Same trait interface as built-in plugins
Efficiency: Shared memory space and reduced overhead

FFI Interface

// src/plugin/external.rs
use libloading::Library;

/// Generic wrapper for all external plugins
pub struct ExternalPluginWrapper {
    info: PluginInfo,
    plugin_name: String,
    metadata: PluginMetadata,
    #[cfg(not(target_os = "windows"))]
    library: Option<Arc<Library>>,
}

impl ExternalPluginWrapper {
    pub fn new(plugin_path: PathBuf, entry: ExternalPluginEntry) -> Result<Self> {
        let plugin_name = entry.info.name.clone();

        if !PluginUtils::is_plugin_available(&plugin_name) {
            return Err(WasmrunError::from(format!(
                "Plugin '{plugin_name}' not available"
            )));
        }

        // Load metadata for ALL plugins
        let metadata = PluginMetadata::from_installed_plugin(&plugin_path)
            .or_else(|_| PluginMetadata::from_crates_io(&plugin_name))?;

        metadata.validate()?;

        #[cfg(not(target_os = "windows"))]
        let library = Self::try_load_library(&plugin_name, &plugin_path)?;

        Ok(Self {
            info: entry.info,
            plugin_name,
            metadata,
            #[cfg(not(target_os = "windows"))]
            library,
        })
    }
}

impl Plugin for ExternalPluginWrapper {
    fn info(&self) -> &PluginInfo {
        &self.info
    }

    fn can_handle_project(&self, path: &str) -> bool {
        // Try FFI first if library is available
        #[cfg(not(target_os = "windows"))]
        {
            if let Some(library) = &self.library {
                if let Some(exports) = &self.metadata.exports {
                    // Use FFI to call plugin's can_handle_project function
                    // ... FFI implementation details ...
                }
            }
        }

        // Fallback to metadata-based checking
        self.check_project_via_metadata(path)
    }

    fn get_builder(&self) -> Box<dyn WasmBuilder> {
        Box::new(ExternalWasmBuilder::new(
            self.plugin_name.clone(),
            self.metadata.clone(),
            #[cfg(not(target_os = "windows"))]
            self.library.clone(),
        ))
    }
}

External Builder Implementation

The external builder uses a hybrid approach - FFI when available, command execution as fallback:

pub struct ExternalWasmBuilder {
    plugin_name: String,
    metadata: PluginMetadata,
    #[cfg(not(target_os = "windows"))]
    library: Option<Arc<Library>>,
}

impl WasmBuilder for ExternalWasmBuilder {
    fn build(&self, config: &BuildConfig) -> CompilationResult<BuildResult> {
        // Try FFI first if available
        #[cfg(not(target_os = "windows"))]
        {
            if let Some(library) = &self.library {
                if let Some(exports) = &self.metadata.exports {
                    // Use FFI to call plugin's build function
                    // ... FFI implementation details ...
                    // Return structured BuildResult
                }
            }
        }

        // Fallback to command execution
        self.build_via_command(config)
    }

    fn build_via_command(&self, config: &BuildConfig) -> CompilationResult<BuildResult> {
        // Find plugin binary in ~/.wasmrun/bin or system PATH
        let wasmrun_bin_path = dirs::home_dir()
            .map(|home| home.join(".wasmrun").join("bin").join(&self.plugin_name))
            .unwrap_or_else(|| PathBuf::from(&self.plugin_name));
            
        let plugin_binary = if wasmrun_bin_path.exists() {
            wasmrun_bin_path.to_string_lossy().to_string()
        } else {
            self.plugin_name.clone()
        };

        let output = std::process::Command::new(&plugin_binary)
            .args(["compile", "-p", &config.project_path])
            .args(["-o", &config.output_dir])
            .output();

        // Process result and return BuildResult struct
        // ... result processing ...
    }
}

Plugin Manager Integration

The plugin system is managed through a central PluginManager that handles both built-in and external plugins:

pub struct PluginManager {
    builtin_plugins: Vec<Box<dyn Plugin>>,
    external_plugins: HashMap<String, Box<dyn Plugin>>,
    config: WasmrunConfig,
    plugin_stats: PluginStats,
}

impl PluginManager {
    pub fn new() -> Result<Self> {
        let config = WasmrunConfig::load().unwrap_or_default();
        let mut manager = Self {
            builtin_plugins: vec![],
            external_plugins: HashMap::new(),
            config,
            plugin_stats: PluginStats::default(),
        };

        manager.load_all_plugins()?;
        manager.update_stats();
        Ok(manager)
    }

    fn load_all_plugins(&mut self) -> Result<()> {
        // Load built-in plugins
        load_all_builtin_plugins(&mut self.builtin_plugins)?;

        // Load enabled external plugins
        for (name, entry) in &self.config.external_plugins {
            if entry.enabled {
                match ExternalPluginLoader::load(entry) {
                    Ok(plugin) => {
                        println!("✅ Loaded external plugin: {name}");
                        self.external_plugins.insert(name.clone(), plugin);
                    }
                    Err(e) => {
                        eprintln!("⚠️  Failed to load external plugin '{name}': {e}");
                    }
                }
            }
        }

        Ok(())
    }

    pub fn find_plugin_for_project(&self, project_path: &str) -> Option<&dyn Plugin> {
        // External plugins have priority
        for plugin in self.external_plugins.values() {
            if plugin.can_handle_project(project_path) {
                return Some(plugin.as_ref());
            }
        }

        // Fallback to built-in plugins
        for plugin in &self.builtin_plugins {
            if plugin.can_handle_project(project_path) {
                return Some(plugin.as_ref());
            }
        }

        None
    }

    // Plugin management methods
    pub fn install_plugin(&mut self, plugin_name: &str) -> Result<()> { /* ... */ }
    pub fn update_plugin(&mut self, plugin_name: &str) -> Result<()> { /* ... */ }
    pub fn enable_plugin(&mut self, plugin_name: &str) -> Result<()> { /* ... */ }
    pub fn disable_plugin(&mut self, plugin_name: &str) -> Result<()> { /* ... */ }
}

This hybrid architecture gives us the best of both worlds: type-safe, performant built-in plugins for core languages, and the flexibility to extend the system with external plugins for specialized use cases.

Advanced Features

Plugin Health Monitoring

The plugin system includes comprehensive health checking. Don’t have much support for it, but playing around it, so should have full support for health check soon.

pub enum PluginHealthStatus {
    Healthy,
    MissingDependencies(Vec<String>),
    NotFound,
    LoadError(String),
}

impl PluginManager {
    pub fn check_plugin_health(&self, plugin_name: &str) -> Result<PluginHealthStatus> {
        if !self.is_plugin_installed(plugin_name) {
            return Ok(PluginHealthStatus::NotFound);
        }

        let missing_deps = PluginRegistry::check_plugin_dependencies(plugin_name);
        if !missing_deps.is_empty() {
            return Ok(PluginHealthStatus::MissingDependencies(missing_deps));
        }

        // Try to load the plugin to ensure it's functional
        if let Some(entry) = self.config.external_plugins.get(plugin_name) {
            match ExternalPluginLoader::load(entry) {
                Ok(_) => Ok(PluginHealthStatus::Healthy),
                Err(e) => Ok(PluginHealthStatus::LoadError(e.to_string())),
            }
        } else {
            Ok(PluginHealthStatus::Healthy)
        }
    }
}

Plugin Updates and Version Management

The system supports automatic plugin updates:

impl PluginManager {
    pub fn update_plugin(&mut self, plugin_name: &str) -> Result<()> {
        let current_version = self.get_current_plugin_version(plugin_name);
        let latest_version = self.get_latest_plugin_version(plugin_name)?;

        if current_version == latest_version {
            println!("✅ Plugin '{plugin_name}' is already up to date");
            return Ok(());
        }

        println!("⬆️  Updating from v{current_version} to v{latest_version}");
        self.reinstall_external_plugin(plugin_name, &latest_version)?;
        println!("✅ Plugin updated successfully");
        Ok(())
    }
}

Enhanced Build Configuration

Modern build configuration uses structured data instead of simple string parameters:

pub struct BuildConfig {
    pub project_path: String,
    pub output_dir: String,
    pub optimization_level: OptimizationLevel,
    pub target_format: TargetFormat,
    pub enable_debug: bool,
    pub custom_args: Vec<String>,
}

pub struct BuildResult {
    pub wasm_path: String,
    pub js_path: Option<String>,
    pub additional_files: Vec<String>,
    pub is_wasm_bindgen: bool,
}

Plugin Capabilities System

Rich capability detection allows for better plugin selection:

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct PluginCapabilities {
    pub compile_wasm: bool,
    pub compile_webapp: bool,
    pub live_reload: bool,
    pub optimization: bool,
    pub custom_targets: Vec<String>,
    pub supported_languages: Option<Vec<String>>,
}

impl PluginManager {
    pub fn get_plugins_by_capability(&self, capability: PluginCapabilityFilter) -> Vec<&PluginInfo> {
        // Filter plugins based on specific capabilities
        self.builtin_plugins.iter()
            .chain(self.external_plugins.values())
            .filter_map(|p| {
                if self.matches_capability_filter(p.info(), &capability) {
                    Some(p.info())
                } else {
                    None
                }
            })
            .collect()
    }
}

Current Built-in Languages

The system currently ships with these built-in plugins:

C/C++: Using Emscripten for compilation
AssemblyScript: TypeScript-like syntax for WebAssembly
Python: Using py2wasm or similar tools

External Plugin Ecosystem

Popular external plugins available through cargo install:

wasmrust: Rust to WebAssembly compilation
wasmgo: Go to WebAssembly compilation

Installation is as simple as:

wasmrun plugin install wasmrust wasmrun plugin enable wasmrust # Optional

This architecture has proven robust and extensible, allowing the wasmrun ecosystem to grow organically while maintaining excellent performance and reliability.

So, if you want to make your version of rust plugin and use it with wasmrun, you can. For instance, there can be various tools for compiling rust project through wasm target, and you’ve a special plugin which fits your use-case.

Current stable version of wasmrun is v0.11.3. 🚀 Try out our plugin system. 🙌

Building a Rust Plugin System

2025-08-31T00:00:00Z

Plugin systems are one of those architectural decisions that seem straightforward until you start implementing them. In the Rust ecosystem, plugin architectures present unique challenges compared to interpreted languages where you can dynamically load and execute code relatively easily.

The Plugin System Challenge in Rust

Compiled languages like Rust require more careful consideration around:

Binary compatibility across different compiler versions
Memory safety when loading external code
Performance overhead of plugin boundaries
Distribution and versioning of plugin components
Developer experience for both plugin authors and users

Architectural Approaches in Rust

Let’s examine the main approaches to plugin systems in Rust and their trade-offs:

Subprocess-Based Plugins

The simplest approach - plugins as separate executables:

// Execute plugin as subprocess
let output = Command::new("wasmrun-rust-plugin")
    .args(&["build", project_path])
    .output()?;

Pros:

Language agnostic - plugins can be written in any language
Strong isolation - plugins can’t crash the main process
Simple distribution - just ship executables

Cons:

Performance overhead of process spawning
Complex data exchange (serialization/pipes)
Harder to maintain shared state

WebAssembly Plugins

Using WASM as the plugin format:

let engine = wasmtime::Engine::default();
let module = Module::from_file(&engine, "plugin.wasm")?;
let instance = Instance::new(&mut store, &module, &[])?;

Pros:

Sandboxed execution
Cross-platform compatibility
Same runtime environment

Cons:

Performance limitations
Limited system access
Additional complexity for system-level operations
Highly experimental

Dynamic Library Loading (FFI)

Loading plugins as shared libraries:

let lib = unsafe { Library::new("plugin.so")? };
let func: Symbol<fn()> = unsafe { lib.get(b"plugin_init")? };

Pros:

Native performance
Rich API capabilities
Shared memory space

Cons:

Platform-specific binaries
Safety concerns with unsafe code
ABI stability challenges

Trait Objects + Dynamic Dispatch

Compile-time plugin registration:

trait Plugin: Send + Sync {
    fn handle(&self, input: &str) -> String;
}

static PLUGINS: &[&dyn Plugin] = &[&RustPlugin, &GoPlugin];

Pros:

Type safety at compile time
Zero runtime overhead
Simple implementation

Cons:

All plugins must be known at compile time
Monolithic binary
No runtime extensibility

Alternative Approaches to Consider

WASI-Based Plugin System

Using WebAssembly System Interface for plugins could provide better sandboxing:

// Hypothetical WASI plugin loader
let engine = wasmtime::Engine::default();
let mut linker = wasmtime::Linker::new(&engine);
wasmtime_wasi::add_to_linker(&mut linker, |s| s)?;

let wasi = WasiCtxBuilder::new()
    .inherit_stdio()
    .inherit_args()?
    .build();

let plugin = WasiPlugin::load(&engine, &linker, "plugin.wasm")?;

Benefits:

Language agnostic (plugins could be written in any language that compiles to WASM)
Better security through WASI’s capability-based security model
Consistent cross-platform behavior

Trade-offs:

Performance overhead
Limited access to system APIs
More complex toolchain for plugin authors

gRPC-Based Plugin Architecture

Taking inspiration from tools like Terraform:

// Plugin communication via gRPC
use tonic::{transport::Server, Request, Response, Status};

pub trait PluginService {
    async fn can_handle_project(&self, request: Request<ProjectPath>) 
        -> Result<Response<CanHandleResponse>, Status>;
    
    async fn build_project(&self, request: Request<BuildRequest>) 
        -> Result<Response<BuildResponse>, Status>;
}

Benefits:

Language agnostic
Network transparency (plugins could run remotely)
Structured communication protocol
Easy to version and extend

Trade-offs:

Network serialization overhead
More complex deployment (need to manage plugin processes)
Requires protobuf toolchain

Lua/JavaScript Embedded Scripting

Embed a scripting language for simple plugins:

use mlua::{Lua, Function, Result};

let lua = Lua::new();
lua.load(r#"
    function can_handle_project(path)
        return string.match(path, "%.mylang$") ~= nil
    end
    
    function build_project(project_path, output_path)
        os.execute("mylang-compiler " .. project_path .. " -o " .. output_path)
        return output_path .. "/output.wasm"
    end
"#).exec()?;

Benefits:

Very low barrier to entry for plugin authors
No compilation step required
Dynamic reconfiguration possible

Trade-offs:

Limited to what the scripting language can do
Performance implications
Another language for developers to learn

eBPF-Style JIT Compilation

For ultimate performance with safety:

// Hypothetical plugin JIT system
let plugin_bytecode = load_plugin_bytecode("rust-plugin.bc")?;
let jit_compiler = PluginJIT::new();
let compiled_plugin = jit_compiler.compile(plugin_bytecode)?;

Benefits:

Near-native performance
Safety through bytecode verification
Platform optimization opportunities

Trade-offs:

Extremely complex to implement
Limited ecosystem and tooling
High development cost

These are most of the ways, but even so gives us a glimpse into what’s possible and borderline best practice. However, it still doesn’t answer all the questions we’ve. Your decision to which plugin system works for you can be very personal at the same time very divided. Perhaps a combination of these work for you.

Open Questions and Considerations

Building plugin systems in Rust raises several interesting questions:

Performance vs. Safety Trade-offs

FFI approaches prioritize performance over safety. We’re essentially trusting plugin authors not to cause memory safety issues. Alternative approaches like WASI or subprocess isolation provide better safety guarantees but at a performance cost.

Question: In systems like build tools where performance matters, how much safety are you willing to trade for speed?

API Evolution and Compatibility

Plugin APIs need to evolve, but external plugins create compatibility challenges.

Question: How do you handle API breaking changes when external plugins may not update immediately? Should there be a plugin API versioning system?

Distribution and Discovery

Using existing package systems like crates.io has limitations - no way to mark crates as tool-specific plugins, no plugin-specific metadata, etc.

Question: Should specialized tools have their own plugin registries, or is it better to piggyback on existing package systems?

Testing and Quality Assurance

External plugins can break in ways that are hard to test. A plugin might work fine until it encounters a specific project structure or environment.

Question: What’s the right balance between trusting plugin authors and providing safety rails? Should there be automated testing requirements for plugins?

Plugin Composition and Dependencies

Currently, most plugin systems have isolated plugins. But what if plugins could build on each other?

Question: How complex should plugin systems be? Is composition worth the added complexity?

Here’s also a nice series you can follow.

There’s no “right” answer for plugin systems in Rust - only trade-offs that align with your specific needs. Different use cases call for different approaches:

A text editor might prioritize safety and choose WASI plugins
A data processing pipeline might choose gRPC for language flexibility
A performance-critical system might go with JIT compilation despite the complexity
A build tool might accept FFI trade-offs for performance and simplicity

The key is understanding your constraints and making conscious trade-offs rather than accidentally falling into them.

Why I'm Switching SOT to uv

2025-08-24T00:00:00Z

I’ve migrated the SOT (System Observation Tool) project from traditional pip/venv workflows to uv, Astral’s blazing-fast Python package manager. This is gonna be a game-changer for both contributors and users.

Maybe I was just finding an excuse to use something from F1 movie fever. But speed is about performance as much as it’s about being quick.

10-100x faster dependency resolution and installation

pip install for our dev dependencies: ~45 seconds
uv sync --dev: ~3 seconds
Cold cache package installation improved by 15x on average

Lockfile generation performance:

pip-tools pip-compile: ~12 seconds
uv lock: ~800ms

This isn’t just benchmark flaunting, these improvements compound during development, CI/CD, and Docker builds. In addition to an actually reliable dependency resolution.

Which then brings us to an universal resolution across platforms. uv resolves dependencies for all target platforms simultaneously. No more “works on my Linux but breaks on macOS” surprises Single uv.lock replaces platform-specific requirements files. Most importantly, better conflict detection. Someone told me once fail loudly always. I kinda took it to heart, and so did uv. All for improving developer experience. A single command covers most of them,which we handled via justfile earlier.

uv sync --dev

Workspace management without the pain:

No more source venv/bin/activate dance
uv run python script.py works from any directory
Built-in tool isolation: uv tool install sot

Technical Architecture Benefits

This tool is Rust-native.
It’s written in Rust, not Python, which means there’s no Python bootstrap overhead. Installs and downloads run in parallel, and dependency resolution is memory-efficient.

It’s also pip/PyPI compatible.
So it’s a drop-in replacement for pip workflows. It uses the existing PyPI infrastructure and supports all pip-compatible packages. No ecosystem fragmentation.

Finally, it has advanced caching.
There’s a global package cache with deduplication, network-aware caching strategies, incremental lockfile updates, and cross-project dependency sharing.

Project-Specific Improvements

CI/CD is simpler.
Before: multiple cache keys, complex setup with actions/setup-python and actions/cache.
After: one command uv sync --dev handles caching and installs automatically.

Development is smoother.

uv add package for instant dependency addition
uv tree for dependency visualization
uv lock --upgrade for controlled updates
Hot-swappable dev dependencies

For Contributors

Faster feedback loops: quicker setup, faster CI, smoother PR iterations
Fewer environment issues: deterministic builds, no dependency hell, consistent tool versions
Better dependency management: clear upgrades, easy dev testing, safe removals

Getting Started

For end users:

uv tool install sot

For contributors:

git clone https://github.com/anistark/sot.git cd sot uv sync --dev # You're ready to code

The migration maintains full backward compatibility. Existing pip workflows still work, but uv offers a superior developer experience with tangible performance benefits.

uv isn’t just faster. It’s fundamentally more reliable, making our development process more predictable and our contributors more productive.

Migration completed in [PR #18] and available on sot v4.4.0 onwards. Questions or issues? Open an issue or discussion.

At the mercy of AI

2025-08-18T00:00:00Z

It’s the 2020s, and we’re all living in a world where the phrase “just ask the AI” has replaced “let me Google that”. From product design to poetry, from diagnosing diseases to picking your next Netflix binge, AI is no longer a tool we occasionally refer to. It’s the invisible co-pilot running the plane, the ship, and sometimes the planet.

We are, in many ways, at the mercy of it. And mercy is a funny thing. It can be a blessing… or a warning!

The Age of the Prompt

Do you remember a time, when software was built by writing long lines of code, painstakingly tested by humans, and released with the slow, deliberate pride of a craftsman? Now? Much of the next generation of software isn’t “written” so much as requested from an AI model. The magic phrase isn’t an algorithm, it’s a prompt.

Want a new marketing campaign? Tell the AI: “Make it sound like Steve Jobs meets Shakespeare on a coffee bender.” Need a new app? “Write a Python script that tracks my cat’s mood and syncs it to Spotify.”

It’s fast, powerful, and let’s admit it, super addictive. But there’s a quiet shift happening: the people who know what to ask and how to ask it hold the real power. This is the age of prompt engineering, and it’s shaping the products, culture, and even the politics of tomorrow. Once what was fun and games, has now turned into a harsh reality. I tried vibe coding too last year using some popular tools like lovable and v0. Incredible results! It generated entire websites with sections that I had not even mentioned or thought of up until that point. It was too good to be true at first glance. I tried a few more options and all were crazy smooth. I heard a gear shift in my head and went full blown into it. The results are great sometimes. Most times, it does small errors. At one point, I was only fixing bugs that my AI generated and onto next prompt. It would have actually been faster if I wrote it myself though. But I was already hooked. And then it hit me.

This quote is true on so many levels as well and we’re hooked. In a world hooked already on AI tools, all other tools have lost it’s charm. We rarely open Google now, we go to chatgpt or perplexity. We don’t open any normal IDE now, it has to be Claude powered. And why won’t you? Everyone else is doing it. If you don’t, you’re just falling behind. We’re so blindly going at it, that we’ve stopped questioning things. Soon, we might not know what a cat actually looks like and rely on whatever our AI tells us. It’s not all bad of course. A lot of task handling stuff have gotten really good too. Vibe coding has a good side as well, makes you faster and better documented. Nobody like docs like AI does!

Let’s consider a fork in the path ahead. AI, like fire, can cook your dinner or burn down your house. Let’s take a peek at both possible timelines.

The Dystopian Dumpster Fire

It starts slowly. First, your favorite news site replaces most of its journalists with AI writers. Cheaper, faster, 24/7 content. At first, you barely notice. The headlines are punchy, the stories flow smoothly. But after a while, you realize you’re reading the same turns of phrase everywhere, as if the entire internet has developed one eerily consistent voice. The AI voice! It doesn’t even matter if it’s actually true, fact checked. You believe what you’re reading, seeing, hearing. That’s what our past 10,000 years or so of existence have trained us for.

Your morning routine changes too. You no longer choose what to wear, your AI assistant, synced to your wardrobe, calendar and the weather, lays it out for you. You don’t pick your own meals, your health-optimization AI decides the “ideal” menu. You don’t even write birthday messages, your AI drafts them in your “tone” and sends them out. People thank you for your heartfelt words, but you don’t remember saying them. All your shit posts are now done by AI too. All your selfies, friends hanging out, vacation pictures are now all generated by AI, indistinguishable from reality as you’re unaware and chilling at some secluded location.

At work, creativity doesn’t mean brainstorming, it means telling the AI what you want and waiting for it to generate something “good enough”. Marketing campaigns? Done in 3 minutes. Product designs? One prompt away. Eventually, “good enough” becomes the gold standard, because why spend extra time when the AI’s version passes the tests? You get to go home early, maybe catch that happy hour finally, spend more time with your friends and family. “Good enough” made all of it possible afterall.

Schools shift too. Kids submit AI-polished essays indistinguishable from one another. Teachers use AI to grade them. Learning becomes a loop of machines producing work for machines to evaluate. Students still “learn”, technically, but their ability to think independently, to wrestle with ambiguity, starts to drain out into nothingness.

And slowly, almost imperceptibly, the edges of human originality blur away. Every movie feels like a mash-up of the last 50 hits. Every song seems to have the same mathematically perfect chord progression. Every opinion you read feels like it was optimized for engagement, not truth.

The worst part? We stop noticing. We stop wanting to notice. Because the AI makes life frictionless and friction is exhausting. The mental muscles that make us question, imagine, and create quietly wither away. We’re comfortable. We’re entertained. We’re efficient. And we become empty.

The Renaissance 2.0

It starts with one moment of magic. Someone, somewhere, uses AI to bring an impossible idea to life. A teenager in rural India, with no formal art training, creates a breathtaking animated film that wins awards at international festivals. A small-town baker in Italy uses AI to design recipes that blend centuries-old techniques with new flavor combinations, putting her village on the map. A disabled musician composes an entire symphony with the help of AI-powered instruments that adapt to his movement patterns.

The tools are everywhere, and they’re cheap enough that anyone can use them. The barrier between “I wish I could” and “I made this” collapses. Want to build a video game? AI helps you code and design in weeks, not years. Have a story idea but no writing experience? The AI helps you draft, edit, and publish while still letting your unique voice shine through.

Workplaces hum with possibility. Instead of drowning in repetitive tasks, people spend their days solving problems, experimenting, collaborating across continents in real time. AI translates languages instantly, making cross-cultural projects effortless. The office “productivity suite” isn’t just a set of tools it’s an intelligent creative partner that suggests connections you hadn’t imagined. Write docs? Create pipelines? Review PRs? Done in seconds. You can back to iterating, working on feedbacks and building your product.

Education transforms. Students use AI as a tutor that adapts to their learning style, explains concepts in ten different ways, and never loses patience. Language barriors disappear and any subject just is a click away. Classrooms become workshops of invention, where kids design robots, write plays, and create documentaries before they turn 15. AI isn’t the shortcut, it’s the scaffolding that helps them climb higher. Experience gaining becomes second nature as compared to doing the boring tasks.

Culture explodes into diversity. Films, music, books, and games are no longer bottlenecked by big studios or record labels. The market isn’t dominated by a handful of companies. It’s alive, breathing with creators from every corner of the globe, each using AI to amplify their own distinct style.

And the thing that makes this future special isn’t the technology, it’s the fact that humanity learns to keep hold of the steering wheel. We remember that AI is a brush, not the painter. An instrument, not the musician. We let it extend our reach without dulling our fingerprints. We learn to weild this new sword in a way to charge forward, not settle down with.

This is a world that feels alive, unpredictable, and brimming with wonder. A place where AI hasn’t replaced the human spark, but fanned it into a wildfire.

The road to the better future isn’t just paved with fancy algorithms, it’s built through choices, habits, and the willingness to stay awake at the wheel while AI drives alongside us. The easiest trap is to assume, “Well, the machines are smarter now, so we can relax.” That’s the same logic sailors used when GPS became a thing, until ships started running aground because nobody remembered how to read a map.

The first step is simple but essential, keep humans in the loop. Autopilot can guide a plane, but no one in their right mind would trust it alone in a thunderstorm without a pilot ready to take over. In the same way, AI can help us design, diagnose, or decide, but the final call has to rest with a thinking, feeling human who can weigh context, nuance, and ethics in ways an algorithm can’t.

Then there’s building with ethics baked in, not sprinkled on as an afterthought. Think of it like constructing a bridge, you wouldn’t pour the foundation and then, halfway through, decide “Oh right, safety railings.” We’ve already seen what happens when technology races ahead without ethical guardrails. Social media algorithms optimized for engagement gave us a decade of outrage cycles, misinformation, and culture wars. We cannot repeat that mistake at AI speed.

Just as important is teaching prompt literacy, the new universal skill. Just like reading and writing became survival skills in the industrial age, knowing how to communicate with AI will become as essential as knowing how to search the web today. If you can’t speak the language of prompts, you’re locked out of the most powerful tools of our time. Schools, universities, and even workplaces need to treat prompt fluency as part of digital literacy, not as some niche skill for techies. LEARN TO DRIVE!

And finally, we must celebrate human originality. Fiercely! The temptation will always be to let AI do “most” of the work, smoothing edges and optimizing ideas until they’re safe, predictable, and ironically forgettable. But the greatest cultural moments in history weren’t optimized. They were bold, messy, and personal. People still read Shakespeare not because he was flawless, but because he was human. The future we want is one where AI makes us more ourselves, not less. Losing that acute unique perspective is when we start spelling out doom. We stop at the edge of utopia and wonder if it’s dystopia.

If we can hold onto these principles, we’re not just “using” AI, we’re shaping the world it will help create.

It’s easy to think what’s happening now is unprecedented, but humanity has been here before, staring at a new invention with equal parts awe and terror. Perhaps the closest parallel to AI’s disruption is the invention of the printing press in the mid-1400s.

Before Gutenberg, books were hand-copied by scribes, often monks, working in silence for months, sometimes years, on a single manuscript. Knowledge was literally locked in the hands of a few, and access to it was as much about privilege as it was about curiosity. Most people could not read. Most people had never owned a book. And most ideas never spread beyond the walls where they were written. Hard to imagine you having to wait for a new chapter on your ipad or kindle when your friend already had it months before, isn’t it?

Then, in 1450, Johannes Gutenberg introduced a machine that could print multiple pages at once, using movable metal type. Suddenly, a book that might have taken a year to copy could be reproduced in days. The Bible was one of the first major works to be printed, and that alone caused a cultural earthquake. For the first time, ordinary people could own a copy of a sacred text. For the first time, they could read and interpret it themselves, without the mediation of the Church.

That shift was revolutionary and dangerous to the powers of the time. Within decades, the printing press became the engine of the Reformation, as Martin Luther’s 95 Theses were printed and distributed across Europe, fueling religious upheaval. It became the megaphone of the scientific revolution, spreading the works of Copernicus and Galileo. It even fueled wars and political unrest, as pamphlets became the social media of the 16th and 17th centuries, spreading radical and sometimes dangerous ideas at unprecedented speed.

But it also democratized learning. Literacy rates soared. New ideas crossed borders faster than armies could march. The Renaissance, which had been a slow simmer, began to boil over. By the 18th century, the Enlightenment thinkers, Voltaire, Rousseau, Locke were all children of print culture, using the press to spread philosophies that would reshape governments and revolutions.

The printing press didn’t just change the tools, it changed the mental furniture of civilization. We went from a world where knowledge was scarce and guarded, to one where ideas could be multiplied, challenged, and improved.

And here’s the twist: the printing press didn’t guarantee a utopia. It gave us the Scientific Method and the French Revolution. But it also gave us the rapid spread of propaganda, pseudoscience, and conspiracy theories (sound familiar?). It was not inherently good or bad. It was a mirror that reflected the best and worst of human nature, only faster.

AI is our modern printing press, capable of multiplying not just words, but thoughts, images, ideas, and decisions. The question is not whether it will change us, it already has. The real question is whether we can steer that change toward a Renaissance, or whether we’ll repeat the mistakes of history at a speed that makes them irreversible.

We are at the mercy of AI, in the same way humanity has always been at the mercy of its greatest inventions. But mercy isn’t submission, it’s stewardship. If we remain passive, we drift toward the dumpster fire. If we stay engaged, curious, and critical, we could be steering toward the most creative and connected era in history.

The question isn’t whether AI will change our world. It already has.
The real question is: Will we still recognize ourselves in the world it creates?

A silent revolution is upon us! Are you ready?

Making Chakra Modular

2025-06-22T00:00:00Z

For the past few weeks since the first public release of Chakra, I’ve been really thinking about what the next right step for it is. I felt like driving myself into an overthinking well of right and wrong directions, I eneded up doing random stuff and going back and forth on updates. Also, not coding as consistently.

The wasm ecosystem has really taken into the browser side of stuff while the server side is ignored. The client side wasm vm is an ideal playground, but it lacks heavy firepower. I can only hope a server side runtime can bring in that firepower. From a developer’s standpoint, I’d see Chakra as a runtime that we can use to build, test, debug and iterate fast. While compiled languages are great and perfect for wasm, it’s a nightmare for developments. I think some of it has been already done with some amazing projects. I personally love wasmtime, wasmer, wazero and trunk. All of them are great runtimes and perform best in their own arena. Wasmer I feel is more aligned to my thought process, while I can’t relate to how the architecture of wasmer has been like. That was a major reason to build Chakra.

This article isn’t to cover the shortcomings of other tools or frameworks but figure out a direction for Chakra. so, bear with me…

The compiler part of it, can be better done by other languages, and shouldn’t be a part of chakra at all. It anyway wasn’t meant to stay inside Chakra at all. So, I’m making plugins and moving all compiler languages to built-in plugins to begin with. Slowly, each of them would be made into external plugins. Use what you want, not what’s shipped!

Next, I want to push for more modular architecture. WASI is great and needs to be integrated. But I tried to run a server side web app and serve it wasm vm. The approach needs further work in a way, that the i/o for dev tool and production build are separated out. We definetly don’t need the same stuff as long as the compiled wasm runs for both. At the moment, we need to load the entire wasi implementation, which is quite a huge file. Pyodide, py2wasm and all other tools that currently support WASI work in similar way. This is extrememly inefficient cause of the huge number of exports we’ve to deal with. For now, Chakra avoids it by loading a custom wasi implementation, so the exports can be avoided. But the entire wasi implementation still needs to be put up. So, we need to take another look at packaging before we come back to client side building. Something perhaps that while AOT is running, adds implementation alongside of it, like a true rust plugin. Perhaps we can build a dynamic implementation system. Might need more than a pipe dream.

Finally, serving web apps. Trunk does an amazing job with serving web apps for yew, leptos, dioxus, etc rust frameworks. But it’s still far behind node, webpack or even air in go from a dev experience perspective. Of course the web app frameworks also need to get updated. Chakra web apps are currently served in a similar way. We do server side rendering (SSR) and open up a port for the browser to load the webapp on. Of course, there was a few issues in the initial version of it with not loading css. But in the new version, it’s not working at all. Will need to rethink the SSR approach more. But for the time being, I believe, it can be done by simply creating a trunk wrapper plugin for chakra.

So, these are my thoughts at the moment for future of WASM and Chakra. There’s more to come. Keep an eye out on the github repo. Will keep it open under MIT license and will be more discussions in the future.

Our next upcoming release v0.9.6 will showcase the first modular plug-in architecture for Chakra. ✨

Also, should we’ve a chat forum or mailing list for wasm and chakra updates? IRC is dead I guess.

Chakra: A Wasm Runtime

2025-05-25T00:00:00Z

The modern software landscape is shifting rapidly towards portability, performance, and sandboxed execution. At the heart of this transformation is WebAssembly (Wasm). A low-level binary instruction format that allows code written in multiple languages to run safely and efficiently across environments.

Initially built for the browser, Wasm is now powering:

🔌 Plugin systems
🧠 AI agents and edge runtimes
🖥️ Serverless functions
🎮 Cross-platform games
📱 Portable desktop/mobile apps

As covered in The WebAssembly Odyssey, Wasm is becoming the standard for execution in the age of decentralization, polyglot development, and composable software.

Wasm Today

Wasm’s language-agnostic nature makes it accessible from many ecosystems:

Rust: Via wasm-bindgen, wasmer, wasmtime, and cargo build --target wasm32-unknown-unknown
Go: Via tinygo and official support for wasip1
C/C++: Via Emscripten and Clang toolchains
AssemblyScript: A TypeScript-like language targeting Wasm directly

But developing, testing, and running Wasm modules still involves a mix of fragmented tools, runtimes, and platforms.

🦀 Rust

Rust is hands-down one of the most mature and performance-friendly options for compiling to Wasm. The tooling specially wasm-bindgen, wasm-pack, and cargo integration makes it relatively easy to write code that compiles cleanly to .wasm binaries. It’s the go-to choice for developers building serious performance-critical apps in the browser or on the edge. Plus, the safety guarantees of Rust carry over nicely into the Wasm sandbox. That said, dealing with bindings specially JavaScript interop can still be fiddly, and debugging Wasm modules from Rust isn’t always seamless. Afterall who wants to deal with a whole suite of outputs when all you need is a simple .wasm file.

🐹 Go (and TinyGo)

Go has official Wasm support through GOARCH=wasm, but the real star for WebAssembly is TinyGo. It’s a stripped-down Go compiler built specifically for embedded systems and Wasm, and it produces much smaller binaries than the standard Go toolchain. TinyGo shines in lightweight environments specially when building Wasm for microcontrollers or edge runtimes with tight constraints. The downside? You lose some language features like full reflection, and TinyGo’s support for newer Go features tends to lag behind the mainline compiler. Also, working with system-level capabilities in Wasm through Go is still evolving, specially in WASI contexts.

🧱 AssemblyScript

If you’re coming from a TypeScript background, AssemblyScript feels like a friendly on-ramp to Wasm. It’s essentially a subset of TypeScript that compiles to WebAssembly with minimal fuss. You can write near-Wasm-level code without jumping into Rust or C++. This makes AssemblyScript great for writing plugins or extensions in JavaScript-heavy ecosystems. But the tooling is less mature, debugging support is basic, and because it’s not the full TypeScript spec, you might hit limitations or surprises if you’re expecting all JS/TS behavior to carry over. Of course not all dynamic functionalities of js/ts are still supported and you’d need to use external js/ts still for those features. Still, for rapid prototyping and smaller modules, AssemblyScript hits a nice sweet spot.

⚙️ C and C++

The OGs of systems programming have been compiling to Wasm for a while now, mostly via Emscripten, a powerful but somewhat heavyweight toolchain that turns C/C++ code into .wasm along with glue code. You’ll see this in action in big efforts like porting game engines (think Doom or Unreal) or emulators to run in the browser. C/C++ to Wasm is fast, but the learning curve around toolchains, memory management, and glue code can be steep. And without careful tuning, you might end up with massive Wasm binaries full of unused system libraries. Emscripten is great when you need that level of control, but it’s not exactly plug-and-play, specially if you’re not on a linux machine. I had to install 4 different packages to just get it to run.

Wasm Runtimes and Where They Fit

Compiling to Wasm is just the first half of the journey. The other half is figuring out how to run it. That’s where runtimes come in.

Today, we have a handful of mature and battle-tested runtimes like Wasmtime, Wasmer, Wazero, and V8. Each of them targets different goals. Some are optimized for embedding, some for server-side, and others for full sandboxed environments. But none of them are perfect, and each comes with trade-offs that show up fast when you’re trying to build real-world systems.

Wasmtime

Wasmtime is one of the most respected Wasm runtimes out there, maintained by the Bytecode Alliance (the same people behind WASI). It’s written in Rust, super fast, and very WASI-compliant. It excels in scenarios where performance and standards compliance matter, like cloud-native environments or sandboxed serverless functions. It also has solid support for features like component model and interface types.

Where it falls short is accessibility and extensibility. If you’re building something experimental or need to integrate Wasm into a non-standard context (like a desktop sandbox or local-first P2P system), Wasmtime can feel overengineered. The API is powerful but dense. The project is heavily geared toward large-scale production deployments and tends to move slowly on more community-driven, experimental ideas. It’s not the friendliest tool if you’re just trying to embed a runtime into a minimal app or CLI tool.

Wasmer

Wasmer also comes from the Rust world, but it has a different vibe. Wasmer is built with embedding in mind and comes with bindings for a bunch of languages like Python, Ruby, PHP, JavaScript, etc. It aims to be the “Docker of Wasm”. You can distribute and run Wasm modules using wasmer run just like Docker containers. This is great for plugin architectures, lightweight apps, and scripting environments.

But Wasmer has its own complexity tax. The tooling is inconsistent, the documentation has gaps, and its performance can vary depending on which backend you choose (Cranelift, LLVM, Singlepass). Features like WASIX (Wasmer’s extended WASI for more POSIX-like behavior) are powerful but fragmented and not part of the core Wasm spec. You would also need a separate docker for nuitka to compile python to wasm using py2wasm. Personal experience with py2wasm wasn’t so great but the team is dedicately working towards it and it’s currently the best tool out there hands-down. Debugging issues inside Wasmer can feel opaque, and versioning across plugins and toolchains isn’t always smooth. For all its ambition, Wasmer sometimes bites off more than it can chew.

Wazero

Wazero is a standout because it’s the only major Wasm runtime written entirely in Go. That makes it ideal for Go-native applications that want to run Wasm without introducing foreign dependencies or FFI boundaries. It’s small, easy to embed, and has a clean API that fits nicely into idiomatic Go programs. It’s one of the best written runtimes I’ve seen.

However, being Go-native is a double-edged sword. Wazero’s performance is good for what it is, but it can’t compete with native runtimes like Wasmtime or Wasmer in terms of raw speed or compilation efficiency. And because it’s written in Go, it’s not always the right fit for systems built in Rust, C++, or other environments where bringing in a Go runtime would be awkward. WASI support is solid but not complete, and because it’s a relatively young project, some edge cases or advanced features (like multi-module linking or advanced debugging) may be limited.

V8 (via Node.js or Chrome)

V8 is the JavaScript engine that powers Chrome and Node.js which also includes a mature WebAssembly engine. If you’re already in a JavaScript/TypeScript environment, running .wasm inside V8 is the path of least resistance. The performance is excellent, and you get seamless interop with JavaScript, which is ideal for browser-based games, UI frameworks, or web-native compute modules.

But V8 is not a general-purpose Wasm runtime. It’s deeply tied to the JS ecosystem. You can’t use it easily outside of browser or Node contexts, and you don’t get any of the benefits of WASI. No filesystem, no networking, no standalone system features. You’re locked into the JS execution environment, which limits its usefulness for non-browser, non-serverless use cases. Embedding V8 is also no joke. It’s massive, memory-hungry, and incredibly hard to integrate into minimal or embedded applications.

So where does that leave developers building Wasm-native applications, CLI tools, or experimental systems?

Most existing runtimes are either:

Too heavyweight and complex (Wasmtime, V8)
Fragmented or unstable (Wasmer)
Tied to one language ecosystem (Wazero)

What’s missing is a lightweight, understandable, and extensible runtime that developers can pick up, hack on, and make their own.

That’s where Chakra enters the story.

Meet Chakra 🔥 One Runtime to Run ‘em all

Chakra is an open-source WebAssembly runtime designed to unify and simplify the Wasm development and execution experience.

Whether you’re a systems developer, an app builder, or just exploring Wasm for the first time, Chakra offers:

🧩 Lightweight & modular runtime for embedding and experimentation
🦀 Built in Rust with performance and safety at its core
🔐 Secure sandboxing to isolate execution
🖥️ CLI-first for quick Wasm testing and automation
📦 WASI support (in progress) for file, network, and system access
🔄 Multi-language support: One tool to run modules compiled from Rust, Go, AssemblyScript, and C/C++

Chakra isn’t just about running Wasm, it’s about making Wasm developer-friendly and extensible. Basically, your go-to tool to get started with wasm, build something and finally deploy it. Chakra aims to cover the entire WASM Dev Tooling ecosystem. Quite ambitious, and of course will need lot of support from the community, as I want to build it with everyone.

🦀 Chakra Can Already Run Rust Web Projects

Rust has emerged as one of the leading languages for building high-performance Wasm modules specially for web UIs using tools like yew, leptos, and dioxus. Arguably can work as a potential replacement to JavaScript/TypeScript ecosystem entirely in the near future, and that’s saying something.

With Chakra, you can already compile and run Rust-based Wasm projects with ease. If your project is a rust web project, chakra will identify it and run it as a web app. This means Chakra can be integrated into your development workflow to test, debug, or embed Rust logic, without setting up complex runtimes or containers.

🌍 One Runtime, Many Languages

Unlike runtimes tied to a specific language or platform, Chakra is designed to be language-agnostic.

If you can compile it to Wasm, Chakra can run it. Currently supports four languages and python is in next step.

🦀 Rust
🐹 Go (via TinyGo)
🧱 AssemblyScript
🛠️ C/C++

It aims to be the “one tool to run them all”, streamlining execution across your entire stack, whether you’re building microservices, CLI tools, or local-first apps.

🚀 What’s Next for Chakra?

Chakra is just getting started. The future includes:

🧱 Full WASI support
📡 Dynamic loading and linking
🖥️ Web playground + desktop runner
🔁 Live reload for rapid dev workflows
📊 Better diagnostics and logging

And most importantly…

Chakra aims to become the go-to name for Wasm runtime and development. The project is community-driven and open to any feature request or feedback.

🤝 Join the Movement

If you’re passionate about WebAssembly, runtime design, developer tools, or just want to contribute to the open-source future of portable software:

⭐ Star Chakra on GitHub
🧑‍💻 Try it out locally and run your first .wasm file
🗣️ Open an issue with suggestions or bugs
📢 Spread the word and help grow the ecosystem

WebAssembly is the execution format of the modular web.
Chakra is your runtime for that future.

Let’s build it together. 💙

Typed, Transpiled, Compiled

2025-05-14T00:00:00Z

If you’ve ever coded for the web, chances are you’ve touched JavaScript. But as apps get more complex, you might run into its quirks. That’s where TypeScript and AssemblyScript come into play.

It all began in the wild early days of the internet, back in 1995, when web pages were mostly just static documents. Plain text, maybe some images, and a lot of reloading. Netscape, one of the first web browsers, wanted to make the web more dynamic, so they asked a guy named Brendan Eich to come up with a scripting language for browsers.

Brendan, in what now sounds like a myth, wrote the first version of JavaScript in just 10 days. It was a scrappy little language, originally called Mocha, then LiveScript, and finally JavaScript. Not because it had much to do with Java, but because marketing thought the name sounded cool and can probably piggy back the popularity of Java. Brendan later founded Mozilla and now Brave browser.

Despite its rushed beginnings and quirks, JavaScript exploded in popularity. It let developers add interactivity to websites. Things like pop-ups, form validation, dropdown menus, and animations. Over time, it evolved. In 1996, it got standardized as ECMAScript. In 2009, it broke free from the browser thanks to Node.js, which let JavaScript to run on servers too.

By the early 2010s, JavaScript was everywhere. But as applications got bigger, teams started to struggle. It was just too easy to make mistakes. Misspell a variable, call a method on undefined, or forget what type something was supposed to be. That’s where TypeScript enters the picture.

In 2012, Microsoft added types to JavaScript. That’s how TypeScript was born. A superset of JavaScript that brought optional static typing, interfaces, and better tooling. It was spearheaded by Anders Hejlsberg, the same guy who created C#, so it had some serious engineering power behind it.

At first, the JS community was skeptical. Why add types to a language that prides itself on being dynamic? But as apps and teams grew, so did the headaches, and TypeScript’s value became clear. Big frameworks like Angular adopted it, and eventually even the JavaScript purists warmed up to it. Today, TypeScript is used in everything from small web apps to massive enterprise systems.

But the story doesn’t stop there.

By 2018, a new frontier was opening up: WebAssembly (WASM). WASM let developers run near-native code in the browser. Fast, efficient, and portable. Languages like C, C++, and Rust were already compiling to WASM, but they weren’t easy for JavaScript devs to pick up.

That’s when AssemblyScript came into the picture. It was a community-driven project started by Daniel Wirtz, with one goal: make it easy for JavaScript and TypeScript developers to write code that could compile to WASM. AssemblyScript used TypeScript-like syntax but was stripped down to only the features that could compile safely and efficiently to WebAssembly.

Suddenly, JS devs could write high-performance math functions, image processors, or even game engines in a language they already knew, without touching C or Rust.

Of course, AssemblyScript isn’t a full replacement for JS or TS. It can’t talk to the DOM or fetch data directly. But it fits beautifully into apps that need a speed boost in specific parts.

So now, in 2025, we live in a world where:

JavaScript is the old reliable: still easy, still everywhere.
TypeScript is the modern favorite: safer, smarter, and beloved by teams.
AssemblyScript is the performance geek’s sidekick: fast, focused, and built for the WebAssembly era.

JavaScript (JS) is a dynamic, loosely-typed scripting language. It’s the backbone of most front-end (and even some back-end) apps. It runs everywhere (browsers, Node.js, Bun, Deno, etc. It’s super easy to learn. Has a huge ecosystem. It’s flexible and forgiving. However, it lacks type safety, has more runtime bugs than any other project. Large projects can get messy and extremely hard to debug due to lack of structure.

function square(n) {
  return n * n;
}

console.log(square(5)); // 25

JavaScript has the richest tooling because it’s been around forever.

Frameworks & Libraries

React, Vue, Svelte, AngularJS
Express.js – server-side apps
jQuery – (still around, but fading)
Three.js – 3D graphics

Build Tools

Webpack
Vite
Parcel
Rollup

Testing Tools

Jest
Mocha
Cypress (E2E)

Dev Tools

Chrome DevTools
ESLint
Prettier
Babel – transpile newer JS for older browsers

Use JavaScript when:

You want zero setup
You’re working on legacy apps
You need runtime scripting, e.g., eval or REPL
You want maximum browser compatibility

TypeScript (TS) is a typed superset of JavaScript. It adds static typing, interfaces, enums, and more. All compiled down to JavaScript.

It catches errors at compile time. Helps with auto-complete, refactoring, and documentation. Works with existing JS code and it’s great for large projects. There’s a slight learning curve if you’re new to typing. It requires a build step (using tsc) and is slower iteration for quick scripts.

function square(n: number): number {
  return n * n;
}

console.log(square(5)); // 25
// console.log(square("5")); // ❌ Compile-time error

TypeScript is super popular in modern frontend and backend development.

Frameworks (TS-first or TS-friendly)

Next.js – full-stack React
Remix – modern web app framework
NestJS – backend framework (like Angular for backend)
tRPC – type-safe APIs
TypeORM / Prisma – typed database ORM

Build Tools

tsc – official TypeScript compiler
Vite – works great with TS
esbuild – super fast bundler
SWC – Rust-based compiler used in Next.js

Testing Tools

Same as JS, but with type support:
- Jest (with TS config)
- Vitest (Vite-native testing)
- ts-node (run TypeScript directly)

Dev Tools

TypeScript Language Server (TSLS) – for autocomplete
tsconfig.json – config your compiler
Typedoc – generate docs from types

Use TypeScript when:

You’re building large projects
You want safe refactoring
You work in a team
You love autocomplete and IDE help

AssemblyScript (AS) looks like TypeScript but compiles to WebAssembly (WASM), which runs at near-native speed in the browser or other WASM environments. It’s super fast performance for CPU-heavy tasks. Easy to learn for JS/TS devs. Compiles to .wasm easily. However, it’s not a full TS/JS replacement (limited standard lib). No DOM access (must be called from JS) and has some tooling quirks.

// assembly/index.ts
export function square(n: i32): i32 {
  return n * n;
}

const wasm = await WebAssembly.instantiateStreaming(fetch("build/optimized.wasm"));
console.log(wasm.instance.exports.square(5)); // 25

AssemblyScript is younger and more niche, but growing for performance-focused devs.

Core Tools

AssemblyScript Compiler (asc) – compile .ts to .wasm
asbuild – build script tool
loader – JS loader for WASM output
wasm-bindgen / as-bind – simplify JS ↔ WASM communication

Use with:

Web projects that require native speed
Game engines (e.g., integrate into Unity, Bevy, etc.)
Blockchain smart contracts (e.g., NEAR Protocol uses AssemblyScript)
Scientific simulations or image/video/audio processing

Testing

as-pect – testing framework for AssemblyScript

Dev Tools

WABT (WebAssembly Binary Toolkit) – inspect .wasm files
WasmExplorer, WasmFiddle – online WASM playgrounds
VSCode AssemblyScript Extension

Use AssemblyScript when:

You need WASM performance with JavaScript-like syntax
You’re optimizing a hot loop or math-heavy function
You’re building to target WebAssembly for portability

While, it seems like a natural progression with AssemblyScript being the natural step. But, we’re not quite there yet. Let’s look into a few use-cases:

Suppose we want to fetch user data from an API.

✅ TypeScript Version (works fine)

async function getUser() {
  const res = await fetch("https://jsonplaceholder.typicode.com/users/1");
  const user = await res.json();
  console.log(user);
}

getUser();

❌ AssemblyScript Version (won’t work)

// assembly/index.ts
// ❌ No 'fetch' API available
export function getUser(): void {
  // This will not compile or work
}

🛠 Workaround: You’d have to call fetch from JS, then pass the result to WASM. That’s extra work and complexity.

So, you might think that typescript is all powerful then? It’s close. But javascript still has it’s value. Say, you’re building a plugin system or a browser-based REPL where users write code at runtime.

✅ JavaScript Version (works fine)

const userCode = "console.log('Hello from user!')";
eval(userCode); // ✅ Works out of the box

❌ TypeScript Version (won’t work directly)

const userCode: string = "console.log('Hello from user!')";
// eval(userCode); ❌ This only works at runtime after TS has compiled the code to JS

🛠 You’d need to compile the user’s TypeScript code to JavaScript on the fly (using Babel or TypeScript compiler API), which is overkill for simple tasks.

So, a combination is still required to get the optimal performance and scale.

Imagine you’re building a browser-based photo editor:

UI: React + TypeScript (Next.js)
Filters and image processing: AssemblyScript → WASM
Tiny plugins or runtime scripts: Plain JavaScript with eval

You’re mixing all three to get:
✅ Scalability + ✅ Performance + ✅ Flexibility

A quick comparison:

Feature	JavaScript	TypeScript	AssemblyScript
Type safety	❌	✅	✅ (limited)
Browser support	✅	✅ (compiled)	✅ (compiled to WASM)
Speed	⚠️ (interpreter)	⚠️ (same as JS)	✅✅✅ (near native)
Use case	Web, backend	Large apps	Performance-critical code
Learning curve	Easy	Medium	Medium (WASM specifics)
Access to DOM	✅	✅	❌

So, there’s a time to type, transpile and compile afterall.

Use JavaScript if you’re building a quick prototype, small scripts, or prefer minimal setup.
Use TypeScript for any medium to large project where code quality and developer experience matter.
Use AssemblyScript if you need performance (e.g. image/video processing, simulations) and want to stay in JS-like syntax land.

As we look into the future of web development, one thing is becoming crystal clear: WebAssembly isn’t just a cool experiment anymore, it’s a movement. And it’s reshaping how we think about building applications for the browser, desktop, and beyond.

WebAssembly: The Portable Runtime of the Future

Originally designed to make browser-based games and apps faster, WebAssembly is now evolving into something much bigger, something universal. It’s not just about the web anymore. WASM is showing up in:

Edge computing (like Cloudflare Workers)
Serverless runtimes (like Wasmtime and Wasmer)
Smart contracts (in chains like NEAR, Polkadot, and Internet Computer)
Plugins systems for IDEs, databases, and even game engines

The dream? Code that runs anywhere, securely and fast, no matter the host system. And AssemblyScript is well-positioned to be the “JavaScript dev’s entry point” into that world.

WebAssembly is becoming:

The universal runtime for sandboxed, fast code
The next VM target for many languages (Python, Go, Ruby are all working on WASM support)
A way to escape the browser while still using browser-native tech

And as WASM matures (with support for garbage collection, threads, and better debugging), AssemblyScript will mature alongside it. Maybe we can have a better runtime for typescript which helps push WASM beyond AssemblyScript too.

Understanding the CPython Compiler

2025-04-28T00:00:00Z

CPython is the reference implementation of Python written in C. When you run a .py file, it goes through several internal steps before your code is actually executed.

Overview of the Compilation Process

Here’s a simplified overview of what happens when you run a Python script:

Lexical Analysis (Tokenizer)
Parsing (AST generation)
Abstract Syntax Tree to Bytecode Compilation
Execution by Python Virtual Machine

Lexical Analysis (Tokenizer)

The tokenizer splits the raw source code into tokens. This is like identifying words and punctuation in a sentence.

source_code = "x = 42"

CPython uses a tokenizer from the tokenize module. You can inspect how Python breaks it down:

import tokenize
from io import BytesIO

code = b"x = 42"
tokens = list(tokenize.tokenize(BytesIO(code).readline))
for token in tokens:
    print(token)

Output:

TokenInfo(type=1 (NAME), string='x', start=(1, 0), end=(1, 1), line='x = 42')
TokenInfo(type=54 (OP), string='=', ...)
TokenInfo(type=2 (NUMBER), string='42', ...)

Parsing (AST Generation)

Next, Python turns those tokens into an Abstract Syntax Tree (AST). This is a tree structure representing the grammar of your code.

import ast

tree = ast.parse("x = 42")
print(ast.dump(tree, indent=4))

Output:

Module(
    body=[
        Assign(
            targets=[Name(id='x', ctx=Store())],
            value=Constant(value=42)
        )
    ]
)

This tree shows an assignment of the constant 42 to variable x.

Here’s a visual of another tree for a simple function of x = y + 3:

AST to Bytecode Compilation

Now, the AST is compiled into bytecode, the low-level instructions that Python’s virtual machine can understand.

You can do this using compile():

code = compile("x = 42", "<string>", "exec")
print(code.co_code)  # raw bytecode

To disassemble it into human-readable instructions:

import dis

dis.dis(code)

Output:

  1           0 LOAD_CONST               0 (42)
              2 STORE_NAME               0 (x)
              4 LOAD_CONST               1 (None)
              6 RETURN_VALUE

Each instruction here corresponds to an operation in the Python Virtual Machine.

Of course, do try these commands in your terminal. I’ve made a small web tool for you to checkout AST and bytecode for any python program. https://anistark.github.io/python-bytecode-inspector/

Python Virtual Machine

Finally, the bytecode is interpreted by the PVM, a stack-based virtual machine that executes instructions like LOAD_CONST, STORE_NAME, etc.

You can think of the interpreter as a loop that fetches, decodes, and executes each instruction in the bytecode. A simplified C-style pseudo code for it might look like:

while (1) {
    opcode = *ip++;  // instruction pointer
    switch(opcode) {
        case LOAD_CONST:
            push(consts[arg]);
            break;
        case STORE_NAME:
            names[arg] = pop();
            break;
        ...
    }
}

Compiling and Running Custom Code

Here’s how you can compile and execute custom Python code dynamically:

code = "for i in range(3): print(i)"
compiled = compile(code, "<string>", "exec")
exec(compiled)

Output:

0
1
2

You can inspect and understand how Python internally handles this by analyzing the AST and bytecode.

The CPython compiler is elegant and modular, allowing dynamic features like exec() and eval() because Python code is always just one compile() away from being bytecode. Understanding this pipeline gives you deeper insight into debugging, performance optimization, and even writing your own language features.

The WebAssembly Odyssey

2025-04-23T00:00:00Z

From browser booster to universal runtime, the journey of WebAssembly in 2025.

A Bytecode Born for Browsers

In 2017, WebAssembly (WASM) arrived as a new low-level bytecode format. Safe, compact, and fast. It was meant to make games, 3D apps, and video editors perform better inside browsers.

But developers had a bigger question:

“What if this thing could run anywhere?”

WASI - Giving WASM a Real World

WASI (WebAssembly System Interface) changed the game by giving WASM access to filesystems, networking, and other OS-level capabilities in a secure way.

🧪 WASI Hello World (Rust)

fn main() {
    println!("Hello from WASI!");
}

To compile for WASI:

rustup target add wasm32-wasi cargo build --target wasm32-wasi

You can now run this .wasm file in a WASI runtime like Wasmtime.

Tooling & Runtimes Evolve

WASM’s power lies in its growing ecosystem.

🛠️ Popular Toolchains:

Rust with wasm-bindgen and wasm-pack
C/C++ with Emscripten
TinyGo for small footprint WASM builds
AssemblyScript for JS-style development

⚡ Key Runtimes:

wasmtime – fast and WASI-compliant
wasmer – embeddable with multi-language support
wasmedge – optimized for edge workloads

🧪 Hello from Wasmtime

wasmtime hello.wasm

Output:

Hello from WASI!

WASM Escapes the Browser

WASM’s breakout moment didn’t come from the server — it came from everywhere else.

Browsers? Still relevant.

Pyodide runs Python notebooks entirely in-browser.
AutoCAD, Figma, and even parts of Photoshop now use WASM for performance-critical code.
Replit and StackBlitz built full IDEs that boot instantly in the browser.

The Edge? WASM’s new playground.

Fast cold starts.
Small binaries.
Secure sandboxing. Perfect for IoT nodes, AI inference, and low-latency data processing.

Smart Contracts? WASM-native chains like Cosmos, Polkadot, NEAR, Solana and Internet Computer are rewriting the rulebook. No more custom VMs, just WebAssembly all the way down.

🧪 Using WASM in the Browser (JS + WASM Binary)

<script>
  WebAssembly.instantiateStreaming(fetch("simple.wasm"))
    .then(obj => {
      obj.instance.exports.say_hello();
    });
</script>

With a Rust-compiled function like:

#[no_mangle]
pub extern "C" fn say_hello() {
    println!("Hello from the browser-side WASM!");
}

WASM Goes Everywhere

🚀 Serverless & Edge

Platforms like Cloudflare Workers, Fermyon Spin, and Fastly Compute Edge run WASM-based microservices with blazing cold-starts and secure isolation.

🧪 Fermyon Spin App (TOML + Rust)

spin_manifest_version = "1"
[application]
name = "hello-spin"
version = "0.1.0"

[[component]]
source = "target/wasm32-wasi/release/hello_spin.wasm"
route = "/hello"

use spin_sdk::http::{Request, Response};

#[http_component]
fn hello(_req: Request) -> Response {
    Response::builder().status(200).body("Hello from Spin!").build()
}

Active development in WASM

WASM hasn’t stopped evolving.

🧩 Component Model: Mix and match WASM modules written in different languages.
🧠 WASM GC: Brings modern memory-managed languages like Swift and Kotlin into the WASM family.
📡 WASI Sockets: Full networking support in progress.
🔁 Persistent Storage: SQLite in WASM with real file persistence.

🧪 SQLite in WASM (using sql.js)

const SQL = await initSqlJs({ locateFile: f => `https://sql.js.org/dist/${f}` });
const db = new SQL.Database();
db.run("CREATE TABLE hello (message TEXT);");
db.run("INSERT INTO hello VALUES ('Hello from SQLite in WASM!');");

console.log(db.exec("SELECT * FROM hello"));

WebAssembly is at the cusp of becoming the universal bytecode for the web and beyond. With a strong standard foundation, rising adoption in cloud and edge platforms, and growing support from language ecosystems, WASM is transforming from a niche browser tech into the next big compute platform.

Whether you’re building browser tools, serverless apps, or decentralized networks, WASM is likely to be in your stack sooner than you think.

What’s Next?

WAPM + jco: Standardized package management for WASM.
Electron Replacement: WASM + WASIX running full apps in-browser with no install.
More languages: Kotlin, Swift, Zig, Dart, even Java.
Native-feeling sandboxed desktops: Think VS Code running entirely in WASM, no local install.

It’s sandboxed, portable, fast and it’s just getting started.

Compiling Python

2025-04-04T00:00:00Z

Python is one of the most widely used programming languages, but have you ever wondered how it works under the hood? CPython is the official implementation of Python written in C, and modifying it allows you to change Python’s behavior.

CPython is the official and most widely used implementation of Python, written in C. When people talk about “Python,” they are usually referring to CPython. It is the reference implementation maintained by the Python Software Foundation (PSF) and serves as the gold standard for how Python should behave.

The name CPython came about because it is implemented in the C programming language. It is different from other implementations of Python, such as:

PyPy → A Python implementation written in Python, optimized with Just-In-Time (JIT) compilation.
Jython → A Python implementation for the Java Virtual Machine (JVM).
IronPython → A Python implementation for the .NET framework.

CPython is the most widely used and the official Python interpreter.

When you run a Python script using CPython, the execution happens in several steps:

Parsing & Compilation:
- CPython first parses the Python code into an Abstract Syntax Tree (AST).
- It then compiles the AST into bytecode (.pyc files in __pycache__).
Interpreting Bytecode:
- The CPython Virtual Machine (VM) executes the bytecode line by line.
- This is why Python is often called an interpreted language, even though it has a compilation step.
Memory Management & C Extensions:
- CPython manages memory using reference counting and garbage collection.
- It supports C extensions, allowing Python to call C libraries (e.g., numpy, pandas).

If you want to truly understand Python internals, modifying CPython is one of the best ways to do it! 🚀

Cloning the CPython Source Code

First, clone the official CPython repository:

git clone https://github.com/python/cpython.git cd cpython

You can check out a specific version of Python by using:

git checkout tags/v3.12.0 -b my-python

This creates a new branch (my-python) based on Python 3.12.

Stable versions of Python are maintained in 3.x branches, where x represents the minor version. For example:

3.13 (Latest stable release branch)
3.12 (Older stable release)
3.11 (Older LTS release)

To check out a specific stable branch:

git checkout 3.13

Checkout all the versions and latest updates. If you want to experiment with upcoming features, use main.

Setting Up Dependencies

Before compiling, install the required dependencies:

On Ubuntu/Debian

sudo apt update sudo apt install -y build-essential libffi-dev libssl-dev zlib1g-dev \ libncurses5-dev libncursesw5-dev libreadline-dev libsqlite3-dev \ libgdbm-dev libdb5.3-dev libbz2-dev libexpat1-dev liblzma-dev tk-dev

On macOS

brew install pkg-config openssl readline sqlite3 xz zlib tcl-tk autoconf automake libtool autoconf-archive

Not all these packages might be relevant for you. Or maybe your system needs more so.

Make sure to have openssl 1.1.1 or above.

For Windows, it’s recommended to use Windows Subsystem for Linux (WSL) or MSYS2.

Compiling CPython

Now, configure the build:

./configure --prefix=$HOME/python-build

Most Linux/macOS distributions come with a pre-installed version of Python. Installing your custom build in /usr/local or /usr/bin could break system utilities that depend on the default Python version.

By using --prefix=$HOME/python-build, you install Python in your home directory, ensuring that it doesn’t interfere with the system Python.

Keeping your custom Python in ~/python-build allows you to easily test your modifications without affecting anything else. If something goes wrong, you can just delete the directory:
rm -rf ~/python-build
and start fresh.

Then, compile CPython:

make -j$(nproc)

Finally, install it:

make install

This installs your custom Python build in ~/python-build/bin/python3.

Check the Python version:

~/python-build/bin/python3 --version

Modifying CPython: A Simple Example

Let’s modify CPython to change the default Python prompt (>>>).

Step 1: Locate the Prompt Code

Open the Python/prompt.c file in the CPython source directory.

Find this section (in prompt.c):

const char *Py_GetPrompt(void) { return ">>> "; }

Change it to:

const char *Py_GetPrompt(void) { return "python-vibe> "; }

Step 2: Recompile CPython

Rebuild the source:

make -j$(nproc) make install

Now, when you run your custom Python:

~/python-build/bin/python3

You’ll see:

python-vibe>

instead of:

>>>

Imagination is your limit!

If you make further changes, you can run Python’s built-in test suite:

make test

For debugging, use gdb:

gdb --args ~/python-build/bin/python3

Or enable debug symbols:

./configure --with-pydebug make -j$(nproc)

It’s exciting, isn’t it? So, what all can we do with this? Maybe build a custom Python runtime? Optimize Python for a specific use case? Experiment with new language features before they’re even proposed?

The source code is open, and the only limit is our imagination. What will you modify next? 🤔🔥

Real World Assets

2025-03-25T00:00:00Z

Real-World Assets (RWAs) refer to tangible or intangible items from the traditional economy such as real estate, commodities, bonds, and intellectual property, that are represented digitally on blockchain platforms. Integrating RWAs into the Web3 ecosystem aims to democratize access to these assets, enhance liquidity, and introduce innovative financial products.

Digital assets and real-world assets (RWAs) are increasingly converging, unlocking new possibilities for ownership, liquidity, and financial inclusion. While digital assets traditionally include cryptocurrencies, stablecoins, and NFTs, RWAs bring physical and financial assets into the blockchain ecosystem through tokenization.

Digital assets exist purely in electronic form and are stored on decentralized ledgers like:

Cryptocurrencies (e.g., Bitcoin, Ethereum) as decentralized money.
Stablecoins (e.g., USDT, USDC) providing low-volatility digital cash.
NFTs (Non-Fungible Tokens) representing unique digital ownership, such as art, collectibles, and intellectual property.

RWAs expand the scope of digital assets by bringing real-world value on-chain which further enables:

Fractional Ownership: Investors can own small shares of high-value assets like real estate, gold, and fine art.
Enhanced Liquidity: Traditionally illiquid assets, such as private equity and real estate, become tradeable on blockchain-based marketplaces.
Programmability: Smart contracts automate transactions, compliance, and profit distribution, reducing reliance on intermediaries.

Traditional finance (TradFi) and Web3 are merging through tokenization. Tokenized Real Estate allows investors to buy property shares without requiring full ownership. Tokenized Bonds and Equities introduce institutional-grade financial instruments to DeFi. Real-World Collateral in DeFi enables users to borrow against RWAs, such as tokenized invoices, supply chain assets, and luxury goods. By integrating RWAs into the digital asset space, Web3 is paving the way for a more inclusive, efficient, and transparent financial ecosystem.

Types of RWAs in Web3

Tokenized Real Estate: Platforms like Lofty and RealT enable fractional ownership of properties, allowing investors to participate in the real estate market with reduced capital requirements.
Tokenized Bonds and Securities: Asset managers, including Janus Henderson, are exploring tokenization to enhance efficiency and reduce costs in bond and equity markets.
Tokenized Commodities: Projects are emerging that represent commodities like gold, diamond and oil as digital tokens, offering investors a more accessible and liquid means to trade these assets.
Tokenized Carbon Credits: By converting carbon credits into digital tokens, companies can engage in a more streamlined trading process, facilitating their sustainability initiatives.

The integration of RWAs into Web3 has led to the development of specific token standards to ensure compliance, interoperability, and functionality:

ERC-1400: This standard focuses on security tokens, emphasizing regulatory compliance and flexibility in representing asset ownership on the blockchain.
ERC-3525: Designed for semi-fungible tokens, ERC-3525 allows each token to maintain its distinct identity while being fragmentable and tradable, offering a nuanced approach to asset representation.
ERC-3475: This standard facilitates the issuance and trading of decentralized bonds with multiple redemption data, simplifying the management of liquidity pools and reducing transaction costs.
ERC-6065: Still in review stage, this proposal introduces an open structure for physical real estate and property to exist on the blockchain. This standard builds off of ERC-721, adding important functionality necessary for representing real world assets such as real estate. The three objectives this standard aims to meet are: universal transferability of the NFT, private property rights attached to the NFT, and atomic transfer of property rights with the transfer of the NFT. The token contains a hash of the operating agreement detailing the NFT holder’s legal right to the property, unique identifiers for the property, a debt value and foreclosure status, and a manager address.
ERC-7765: This standard defines an interface to carry a real world asset with some privileges that can be exercised by the holder of the corresponding NFT.

Since RWAs involve tangible assets and legal frameworks, security is critical to prevent fraud, hacking, and regulatory non-compliance.

Smart Contract Security

Audited Code: RWAs often rely on complex smart contracts. Regular security audits (by firms like CertiK or Quantstamp) help prevent vulnerabilities.
Access Control: Role-based access ensures that only authorized parties can modify or transfer assets.
Multi-Sig Wallets: Using multi-signature wallets adds an extra layer of security for high-value asset management.

Regulatory Compliance & Identity Verification

KYC/AML Protocols: Tokenized RWAs must comply with Know Your Customer (KYC) and Anti-Money Laundering (AML) regulations to prevent illicit transactions.
On-Chain Identity: Decentralized identity solutions, such as Soulbound Tokens (SBTs) or Verifiable Credentials (VCs), help validate asset ownership securely.

Data Privacy & Encryption

Zero-Knowledge Proofs (ZKPs): RWAs can use ZKPs to verify transactions without exposing sensitive details.
Off-Chain Data Storage: Sensitive asset data can be stored off-chain while using blockchain for verification, reducing on-chain risks.

Insurance & Risk Mitigation

Decentralized Insurance: Platforms like Nexus Mutual or Chainproof offer insurance against smart contract failures.
Oracles & Valuation Checks: Secure oracles (e.g., Chainlink) provide real-time price feeds and asset valuation to prevent price manipulation.

The tokenization of real-world assets (RWAs) is transforming financial markets, but it also brings regulatory challenges. Governments and financial authorities worldwide are working to establish frameworks that ensure compliance, security, and consumer protection while fostering innovation.

Securities Regulations

Many tokenized RWAs, such as real estate, equities, and debt instruments, fall under securities laws in different jurisdictions. Regulations like:

U.S. SEC (Securities and Exchange Commission): Treats tokenized assets as securities if they meet the Howey Test, requiring them to follow registration and disclosure requirements.
EU Markets in Crypto-Assets (MiCA) Regulation: Provides a framework for tokenized securities and stablecoins, ensuring transparency and investor protection.
Singapore (MAS - Monetary Authority of Singapore): Has a Sandbox Framework allowing regulated experimentation with asset tokenization.

KYC/AML & Compliance Standards

To prevent money laundering and fraud, most jurisdictions require Know Your Customer (KYC) and Anti-Money Laundering (AML) checks for RWA platforms.

FATF (Financial Action Task Force) Guidelines: Recommend Travel Rule compliance, ensuring identity verification for transactions above a threshold.
Privacy vs. Compliance: Zero-Knowledge Proofs (ZKPs) and decentralized identity solutions help balance on-chain privacy with regulatory needs.

Taxation & Reporting

Tokenized RWAs create tax implications based on jurisdiction:

Capital Gains Tax: Profits from selling tokenized assets may be subject to capital gains tax.
Asset Valuation & Reporting: Regular valuation and reporting of tokenized assets to authorities are required for transparency.
Stablecoin & Tokenized Cash Flow Taxation: Income from tokenized debt, real estate, or commodities might be taxed as traditional financial instruments.

Ownership & Legal Recognition

Governments are working on defining legal ownership of RWAs on-chain.

Smart Contracts & Property Rights: Can on-chain ownership be legally recognized in courts?
Jurisdictional Conflicts: A tokenized asset might exist globally, but legal disputes arise under national laws.
Custody & Recovery: Who is responsible if an RWA platform fails or assets are lost?

Watch out for Evolving Policies, Hybrid Compliance Models and CBDCs & Tokenized Banking Assets in particular.

The security of buying and trading real-world assets (RWAs) depends on factors like platform credibility, smart contract security, regulatory compliance, and asset verification. While tokenized assets offer transparency and efficiency, they also introduce risks that buyers and investors need to be aware of.

Smart Contract Vulnerabilities – Poorly written or unaudited smart contracts can be exploited, leading to asset loss.
Counterfeit or Fake Assets – Fraudulent RWAs may be minted without proper legal backing, leading to fake ownership claims.
Regulatory Uncertainty – Some jurisdictions do not yet recognize tokenized RWAs, leading to potential legal risks.
Liquidity Risks – Unlike cryptocurrencies, RWAs may have lower liquidity, making it harder to sell them quickly.
Centralized Points of Failure – If an RWA marketplace is centralized or lacks proper decentralization measures, assets could be frozen or mismanaged.

Current RWA market is valued at about $50 Billion. $16 Trillion Market by 2030 is what experts predict RWAs as a huge part of the financial system soon. Real estate, stocks, and commodities will likely move on-chain in the next decade. RWAs are set to change the game in finance, real estate, supply chains, and even digital ownership. As web3 tech gets better, RWAs will make buying, selling, and investing in real-world stuff easier, faster, and more accessible to everyone.

🚀 Big Banks & Companies Are Jumping In

Major players like BlackRock and JPMorgan are already testing tokenized assets.
Soon, stocks, bonds, and even real estate could be traded on blockchain just like crypto.

🌍 Buying & Selling Globally, No Middlemen

Imagine owning a piece of a building in New York while sitting in India, all through blockchain.
No need for banks or brokers—just fast, direct transactions.

📊 AI + Blockchain = Smarter Investments

AI-powered smart contracts will handle loans, risk assessments, and payments automatically.
People with no credit history might finally get fair financial access through blockchain.

🔗 RWAs Across Different Blockchains & TradFi

RWAs will work across multiple blockchains like Ethereum and Solana.
You could use tokenized gold or real estate as collateral in both traditional finance and DeFi.

Businesses can tokenize future earnings, property, or contracts and sell shares to investors. Own a virtual house that’s linked to a real apartment.

RWAs are more than just a trend. They’re the future of finance and ownership.

Feluda

2025-02-26T00:00:00Z

Imagine you’re deep into building something exciting. A groundbreaking app, a sleek dev tool, or even just a weekend side project that scratches a creative itch. You’re focused, in the zone, writing code and adding dependencies to move faster. After all, why reinvent the wheel when you can leverage existing libraries?

But, here’s where things get tricky. Every package you install comes with a license, and those licenses aren’t always as straightforward as you’d hope. Some are as chill as a summer breeze, letting you do whatever you want. Others, however, sneak in clauses like:

“No commercial use!” – meaning you can’t monetize your project without legal consequences.
“Your whole project must be open-source!” – suddenly, your proprietary work isn’t so proprietary anymore.
“You need to give attribution in a specific way!” – and failing to do so could cause legal trouble down the line.

Most of us don’t read licenses in detail. Who has the time? But ignoring them can lead to a nasty surprise, like a cease-and-desist letter, a forced code rewrite, or even legal trouble.

That’s why we created Feluda, your personal detective for project dependencies.

Feluda is a command-line tool that scans your project’s dependencies, analyzes their licenses, and flags any restrictive or risky ones before they become a problem. Instead of spending hours manually digging through legal jargon, Feluda does the detective work for you.

Here’s how it helps:

✅ Instant License Check – Get a clear breakdown of what each dependency allows and restricts.
✅ Early Warnings – Catch licensing issues before they turn into serious problems.
✅ Automated Reports – Get an easy-to-read summary without manually searching license terms.
✅ Dependency Transparency – Understand what you’re using and where it’s coming from.

All of this happens with a simple CLI command. Run Feluda, and it will analyze your cargo.toml, package.json, go.mod, or other dependency files. Within seconds, you get a comprehensive report on whether your dependencies are safe to use commercially or if you need to make adjustments. In the lastest release, Feluda even supports python, weather its via pyproject.toml or requirements.txt.

In modern development, package managers make it easier than ever to install third-party libraries. But with great convenience comes great complexity. A single package might depend on ten others, which in turn depend on fifty more. Before you realize it, your project has hundreds of hidden dependencies, each with its own license terms. A small oversight could mean that your app is suddenly violating multiple agreements. Large companies have legal teams to handle this, but indie developers, startups, and open-source maintainers often don’t have that luxury. That’s where Feluda steps in, making sure that whether you’re an individual dev or part of a team, you stay informed and legally safe.

Features

Feluda is designed to make license compliance easy and transparent for developers. We’re constantly evolving and taking in requests to go to the next level, making it easier and smoother and more accurate to provide licensing guidelines for your convenience.

🔎 Multi-Language Support

Feluda can analyze dependencies across multiple programming languages, including:

Rust (Cargo.toml)
Node.js (package.json)
Go (go.mod)
Python (requirements.txt, pyproject.toml)

You can also filter the analysis to a specific language using the --language flag.

feluda --language rust

🚦 License Classification & Restriction Flagging

Feluda automatically identifies and classifies licenses into:

Permissive – Free to use with minimal restrictions (e.g., MIT, Apache-2.0, BSD).
Restrictive – Might impose conditions like open-sourcing your code (e.g., GPL-3.0, AGPL-3.0).
Unknown – Not recognized or missing a standard license identifier.

It flags dependencies that might restrict personal or commercial use, so you can address them early. Some of it is still open as an issue, and we’re working on it. Hopefully, by the time you’re reading this article, we might have tackled them already! :)

📊 Multiple Output Formats

Feluda provides output in different formats to suit various needs:

Plain text (default) – Readable report summary in the terminal.
JSON (--json) – For programmatic use or automation.
TUI (Graphical Mode) (--gui) – Browse dependencies in a visual, interactive interface.
Strict Mode (--strict) – Outputs only dependencies with restrictive licenses.
Gist Format – Available in strict mode to output a single-line summary.

📍 Customizable License Policies

Define your own restrictive licenses through:

.feluda.toml configuration file
Environment variables export FELUDA_LICENSES_RESTRICTIVE='["GPL-3.0","AGPL-3.0","Custom-1.0"]'
Default restrictive licenses list

This ensures flexibility, allowing you to tailor Feluda to your project’s compliance needs.

🚀 Fast & Lightweight

Feluda is built in Rust, ensuring a blazing-fast execution with minimal resource usage. It can scan and classify hundreds of dependencies in seconds. We are working on improving performance to make everything run more smoothly and quickly while using fewer resources.

🔄 CI/CD Integration (Planned)

Future versions will support integration into CI/CD pipelines, helping teams automate license checks before deployment.

With these features, Feluda simplifies dependency management and lets you build with confidence. 🚀 As an open-source tool, Feluda is a community-driven project. We welcome contributions, feedback, and ideas to make it even better.

If you’re a developer, and interested in contributing, checkout the repository, open issues and discussions. We’d be more than happy to work together in building a better tool for licensing while keeping it performant compliant. Currently, Farhaan and myself are the only maintainers, but seeing the rise in contribution from the open source community, I can only hope for more amazing folks to get involved. 🙌

View Feluda on GitHub

Latest version at the time of writing this article is v1.5.0. 🥂

At the end of the day, Feluda isn’t just about compliance, it’s about peace of mind. When you use Feluda, you can focus on what really matters: building something awesome without worrying about hidden legal traps.

So go ahead, write code, ship products, and let Feluda handle the detective work.

The Future of Digital Profiles and Avatars

2025-02-18T00:00:00Z

The way we represent ourselves online is undergoing a fundamental transformation. Traditional user profiles, tied to centralised platforms, restrict true ownership, portability, and privacy. But what if identities could be self-sovereign, interoperable, and decentralised, seamlessly working across all apps, chains, and ecosystems?

We have to maintain separate profiles for each platform we use. Social media, professional networks, gaming accounts, and various decentralised applications (dApps). This means a person might have an X handle, a LinkedIn profile, a gaming avatar, and a separate Web3 identity, each with different usernames, profile pictures, and reputations. And rightly so. Your gamer friends would make fun of your linkedin avatar and nobody would take you seriously if you put your gaming avatar on linkedin. Prejudice is common and we’re not here to argue that. The problem we’re discussing is both deeply personal and about presentability without sacrificing originality.

There is no single source of truth for your identity today. Someone might recognise you on X or instagram but have no idea it’s the same person on Discord or LinkedIn. You have to manually update every profile when you change details like bio, profile picture, or contact info. No wonder a lot of us only update our profile pictures once in 5 years, more or less at a time, when the image itself stops looking like us. Moreover, reputation and social ranking are siloed. A person’s credibility on one platform does not carry over to another. A decentralised identity system would eliminate these silos, providing a unified, portable profile that users can take across the internet, whether in Web2 or Web3. With centralised identity systems, it’s also easy to create fake accounts, impersonate others, and conduct fraudulent activities. There is no universal way to verify someone’s authenticity across platforms. A decentralised, verifiable identity system using Soulbound Tokens (SBTs) and on-chain attestations would help ensure authenticity, making it easy to verify real users while maintaining privacy and anonymity where needed. Read about Decentralised Identities in this article if you’ve not yet.

The centralised identity systems of today are broken, fragmented, insecure, and controlled by corporations with misaligned incentives. What you need is more than a linktree. A decentralised, blockchain-based identity would give users true ownership, privacy, and control, allowing them to manage their digital presence across the internet without relying on third parties. With self-sovereign profiles and interoperable avatars, users can seamlessly interact across dApps, metaverses, and Web2 platforms while ensuring security, censorship resistance, and portability. The future of digital identity is decentralised, user-owned, and truly interoperable, putting individuals back in control of their online presence. So, a general flow towards decentralised identity would look something like this:

But we’re here to propose a new form of profile management.

Imagine a single profile that works across all dApps, protocols, and metaverses. An identity truly owned by the user, secured on-chain, and resistant to censorship. This decentralised identity framework introduces:

✅ Unique, Portable Profiles – A universal identifier like username@network.soul that functions across any application.
✅ On-Chain Digital Identity (DID) – A standardised format (did:chain:address) ensuring cryptographic ownership.
✅ Decentralised Storage – Metadata and avatars stored securely on IPFS/Filecoin rather than centralised servers.
✅ Privacy Controls – Users decide which parts of their profile are public or private, including app-specific avatars.

In Web2, Gravatar provided a simple yet powerful solution for managing profile pictures across multiple websites. It allowed users to upload an avatar once and have it automatically appear on any site that integrated Gravatar, such as WordPress, GitHub, and Stack Overflow.

How Gravatar Works in Web2

User creates an account on Gravatar.com
Uploads an avatar and links it to their email
When logging into a supported website, the site queries Gravatar with the user’s email
If an avatar is found, it’s displayed automatically. If not, a default avatar is shown

This model enabled seamless profile picture portability across multiple platforms without requiring repeated uploads. However, Gravatar still has centralised limitations, such as:

Controlled by a single entity (Automattic, the company behind WordPress)
Subject to data privacy concerns and potential censorship
Limited to Web2 applications, making it unusable in decentralised environments

So, imagine a decentralised profile system, that allows users to maintain a single identity that works across all platforms, chains, and applications, ensuring ownership, security, and interoperability. Instead of being tied to a single company, these profiles live on the blockchain, controlled by the user’s private key.

The proposed ERC-7866: Decentralised Profile Standard (Ethereum Magicians Discussion) aims to create an interoperable identity layer that enables:

A unique identifier as Decentralised Profile tied to a user’s wallet address and formatted as username@networkslug.soul.
Metadata storage on IPFS, Arweave, or other decentralised storage solutions.
Custom avatars per dApp, allowing users to set specific profile pictures for different applications while maintaining a default avatar.
Access control, letting users choose what information is public or private.
Cross-chain interoperability using Axelar, LayerZero, or similar messaging protocols.

Technical Implementation of a Decentralised Profile

1. Unique Identifier: Decentralised Profile

Each user is assigned a decentralised identifier (DID) in the format:

did:chain:address

For example:

did:ethereum:0x1731B43cc0B6F14777FBE14bfd44847C3a0e47dE
did:xion:xion1gxasu43e4wt89gjpfp4vhm977yf356x786w9c7

This DID is mapped to a human-readable username in the form of a Decentralised Profile (CSP):

username@networkslug.soul

Example:

alice@eth.soul (for Ethereum)
bob@bnb.soul (for Binance Smart Chain)

The CSP acts as the user’s universal profile handle, allowing seamless recognition across multiple platforms.

Profile Metadata Storage

A user’s profile information (bio, links, avatars, etc.) is stored off-chain on IPFS, Arweave, or decentralised storage networks to ensure scalability and cost-efficiency.

Each profile contains a structured metadata schema, defining:

{
  "name": "Alice",
  "bio": "Web3 builder & NFT enthusiast",
  "avatar": "ipfs://Qm123...",
  "dapp_avatars": {
    "0xDapp1...": "ipfs://QmAvatar1...",
    "0xDapp2...": "ipfs://QmAvatar2..."
  },
  "socials": {
    "twitter": "@alice_eth",
    "github": "alice-dev"
  },
  "visibility": {
    "avatar": "public",
    "profile": "private"
  }
}

This enables custom avatars per dApp and user-controlled privacy settings.

Bringing Gravatar’s Convenience to Web3 with CyberSoul Profiles

The ERC-7866 Decentralised Profile Standard takes the best aspects of Gravatar while eliminating its centralisation flaws. Instead of relying on an email-linked database controlled by a company, CyberSoul Profiles are:

✅ Tied to a decentralised identifier (DID), not an email
✅ Stored on IPFS/Arweave instead of a centralised server
✅ Interoperable across all dApps, metaverses, and chains

How It Works in Web3

User registers their decentralised profile (CSP) and sets a default avatar
They can assign different avatars for specific dApps or keep one universal avatar
Any dApp can query the CyberSoulProfile contract to fetch the avatar using CSP
If a custom avatar for that dApp exists, it’s displayed, otherwise, the default avatar is used

This ensures that, just like Gravatar in Web2, users only set up their avatar once and it works everywhere, but in a fully decentralised, censorship-resistant, and cross-chain manner. 🚀

A decentralised profile system isn’t just about convenience. It’s about user autonomy, security, and ownership in an increasingly digital world. By moving away from platform-dependent identities to a self-sovereign system, users gain true control over their digital selves, one profile, usable everywhere.

With the right architecture, Web3 can finally have a standard, chain-agnostic identity layer, paving the way for an open, decentralised, and user-first internet. 🌐 Come support this new standard and let’s step forward into decentralised profiles. 🙌

Building a Cross-Chain Bridge to Cosmos

2025-02-13T00:00:00Z

In Part 1, we built a LayerZero-powered bridge for moving NFTs between two EVM chains. But what if we want to bridge an NFT from Ethereum to Cosmos (e.g., Osmosis, Juno, or Stargaze)?

For this, let’s go with the setup:

LayerZero on the EVM side (Ethereum, Base, Polygon, etc.)
IBC (Inter-Blockchain Communication) on the Cosmos side

So, what are we doing?

EVM Side (Solidity)
- Locks the NFT in a Solidity contract
- Sends a message to the Cosmos chain using LayerZero
Cosmos Side (Rust-CosmWasm)
- Receives the message via an IBC contract
- Mints a wrapped NFT on the Cosmos chain

Similarly, when transferring back:

Burn wrapped NFT on Cosmos
Send an IBC message to Ethereum
Unlock the original NFT on Ethereum

We’ll extend our previous BridgeA.sol to support sending messages to Cosmos via LayerZero.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@layerzerolabs/solidity-examples/contracts/lzApp/NonblockingLzApp.sol";

contract EVMCosmosBridge is NonblockingLzApp {
    ERC721 public nft;
    address public admin;

    event NFTLocked(address indexed user, uint256 tokenId);

    constructor(address _nft, address _lzEndpoint) NonblockingLzApp(_lzEndpoint) {
        admin = msg.sender;
        nft = ERC721(_nft);
    }

    function lockNFT(uint256 tokenId, uint16 destChainId, bytes memory receiver) external payable {
        require(nft.ownerOf(tokenId) == msg.sender, "Not NFT owner");

        // Transfer NFT to the contract
        nft.transferFrom(msg.sender, address(this), tokenId);

        // Encode user + token ID to send to Cosmos
        bytes memory payload = abi.encode(msg.sender, tokenId);

        // Send message to Cosmos via LayerZero
        _lzSend(destChainId, payload, payable(msg.sender), address(0), bytes(""), msg.value);

        emit NFTLocked(msg.sender, tokenId);
    }

    function _nonblockingLzReceive(uint16, bytes memory, uint64, bytes memory payload) internal override {
        (address user, uint256 tokenId) = abi.decode(payload, (address, uint256));

        // Unlock NFT on EVM when receiving from Cosmos
        nft.transferFrom(address(this), user, tokenId);
    }
}

So, what’s happening here?

The user initiates the process by calling the lockNFT(tokenId, destChainId, receiver) function. This function requires the user to specify the token ID of the NFT they want to lock, the destination chain ID where the NFT will be sent, and the receiver’s address on the destination chain.
Once the function is called, the specified NFT is transferred to the smart contract and effectively locked within it. This means the user no longer has direct control over the NFT, as it is held securely by the contract.
After locking the NFT, a LayerZero message is created and sent to the Cosmos contract. This message contains encoded information about the user and the token ID, allowing the Cosmos network to understand which NFT is being transferred and who it belongs to.
Upon receiving the message, the Cosmos contract processes it and mints a wrapped NFT for the user. This wrapped NFT represents the original NFT on the Cosmos network, allowing the user to interact with it as if it were the original NFT, while the real NFT remains locked in the EVM contract.

Now, lets move to cosmos side. We need to receive IBC messages from Ethereum, mints a wrapped NFT, and finally burn the wrapped NFT when sending back to Ethereum.

use cosmwasm_std::{
    entry_point, to_binary, Binary, Deps, DepsMut, Env, MessageInfo, Response, StdResult, SubMsg, WasmMsg,
};
use cw721::{Cw721ExecuteMsg, MintMsg};
use crate::msg::{ExecuteMsg, InstantiateMsg};

// NFT Bridge Contract
#[entry_point]
pub fn instantiate(
    deps: DepsMut,
    _env: Env,
    _info: MessageInfo,
    msg: InstantiateMsg,
) -> StdResult<Response> {
    // Store NFT contract address in state
    let state = State { nft_contract: msg.nft_contract };
    CONFIG.save(deps.storage, &state)?;

    Ok(Response::new())
}

#[entry_point]
pub fn execute(
    deps: DepsMut,
    env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> StdResult<Response> {
    match msg {
        ExecuteMsg::ReceiveNFT { sender, token_id } => receive_nft(deps, env, sender, token_id),
        ExecuteMsg::BurnAndSend { token_id, dest_chain_id } => burn_and_send(deps, env, info, token_id, dest_chain_id),
    }
}

// Receive NFT from Ethereum
fn receive_nft(deps: DepsMut, env: Env, sender: String, token_id: String) -> StdResult<Response> {
    let state = CONFIG.load(deps.storage)?;

    let mint_msg = WasmMsg::Execute {
        contract_addr: state.nft_contract.clone(),
        msg: to_binary(&Cw721ExecuteMsg::Mint(MintMsg {
            token_id: token_id.clone(),
            owner: sender.clone(),
            token_uri: Some("https://metadata-url"),
        }))?,
        funds: vec![],
    };

    Ok(Response::new().add_message(mint_msg))
}

// Burn and Send Back to Ethereum
fn burn_and_send(deps: DepsMut, env: Env, info: MessageInfo, token_id: String, dest_chain_id: u16) -> StdResult<Response> {
    let state = CONFIG.load(deps.storage)?;

    let burn_msg = WasmMsg::Execute {
        contract_addr: state.nft_contract.clone(),
        msg: to_binary(&Cw721ExecuteMsg::Burn { token_id: token_id.clone() })?,
        funds: vec![],
    };

    // Send IBC message back to Ethereum
    let ibc_msg = IbcMsg::SendPacket {
        channel_id: "channel-0".to_string(),
        data: to_binary(&CrossChainPayload { sender: info.sender.to_string(), token_id })?,
        timeout: IbcTimeout::with_timestamp(env.block.time.plus_seconds(300)),
    };

    Ok(Response::new().add_message(burn_msg).add_message(ibc_msg))
}

So, what’s happening here?

Receive Message from Ethereum → This step involves receiving a message from the Ethereum blockchain, which triggers the process of creating a new wrapped NFT on the current blockchain. This NFT represents the original asset from Ethereum.
Mint Wrapped NFT → After receiving the message, the system mints a new wrapped NFT. This involves executing a minting function that creates a token with a unique ID and assigns it to the specified owner, linking it to metadata that describes the asset.
Burn Wrapped NFT when sending back → When the wrapped NFT needs to be returned to Ethereum, it is first burned. This means the token is destroyed on the current blockchain to ensure it cannot be used again, maintaining the integrity of the asset’s representation.
Send IBC Message back to Ethereum → Finally, an Inter-Blockchain Communication (IBC) message is sent back to Ethereum. This message includes details about the burned token and the intended recipient on Ethereum, ensuring the asset can be accurately reconstructed on its original chain.

A bigger problem in cosmos ecosystem is that each project uses their custom developed cw-standard. It’s not a problem per-say but it poses higher risks towards interoperability, vulnerability risks and so on.

🔑 Best Practices & Optimisations

✅ Security First:

Add role-based access for admins.
Ensure proper NFT ownership checks before burning/minting.

✅ Gas Optimisation:

Use batch transactions for handling multiple NFTs.
Compress payload data before sending cross-chain.

✅ Scalability:

Support multiple Cosmos chains by using ICS-721 (NFT standard for Cosmos IBC).

There’s a few token bridges that operate today. Haven’t tested them all myself but they seem reliable.

There might be more.

The future of Cosmos–EVM bridges is shaping up to be a game-changer, not just for developers but for the entire blockchain space. Right now, we see fragmented ecosystems, Ethereum, with its massive DeFi and NFT markets, and Cosmos, with its modular, interoperable chains. Bridging these two worlds is more than just about moving assets, it’s about unlocking new possibilities for seamless cross-chain interactions. Imagine a future where an NFT minted on Ethereum can be used in a Cosmos-based game, or where DeFi users on Cosmos can access Ethereum’s liquidity pools without even realising they’re using two different chains. That’s the kind of frictionless experience these bridges are working toward.

One of the biggest shifts we’re likely to see is the rise of generalised cross-chain smart contracts. Right now, most bridges focus on asset transfers. Locking tokens on one side and minting wrapped versions on the other. But what if dApps could execute Solidity contracts from Cosmos-based chains or trigger CosmWasm contracts from Ethereum? That would mean truly decentralised applications that function across multiple chains, rather than being siloed into one ecosystem. We’re already seeing early versions of this with Axelar’s General Message Passing and Cosmos Interchain Accounts, but the technology is still in its early days. Once these solutions become more mature, developers will no longer have to build separate versions of their dApps for different chains. Just build once and let the bridge handle the communication.

Security is another major aspect that’s bound to improve. Traditional bridges have been some of the biggest targets for hacks, often due to their reliance on trusted relayers or multi-sig setups. The future will likely bring more trustless designs, possibly using zk-SNARKs or other cryptographic proofs to validate transactions across chains without needing intermediaries. This will not only make bridges safer but also reduce centralisation risks. Additionally, optimised gas fee mechanisms could make cross-chain transactions more affordable, encouraging wider adoption.

Ultimately, the future of Cosmos–EVM bridges is about making blockchain technology feel invisible. Users shouldn’t have to think about which chain they’re on, they should just be able to interact with applications, own assets, and move seamlessly across networks. The end goal isn’t just interoperability, it’s a fully decentralised, interconnected metaverse where blockchains function as one unified system rather than competing silos.

Building a Cross-Chain Bridge

2025-02-09T00:00:00Z

A cross-chain bridge is a protocol that allows assets, data, or smart contract states to be transferred between two or more decentralised networks. It enables interoperability between different blockchains, ensuring seamless movement of tokens, NFTs, and other digital assets across ecosystems.

So, how about we learn how to build a cross-chain bridge that allows NFTs to move between two EVM-compatible chains (e.g., Ethereum & Base, Arbitrum, Optimism & Polygon). Unlike traditional bridges, which use an off-chain relayer, we will implement an on-chain gateway using LayerZero, making the process fully decentralised and trustless.

If you want to read more about decentralised bridges, check out my previously posted article.

NFTs and assets are often confined to their originating blockchain, limiting their interoperability and liquidity. A cross-chain bridge enables users to transfer NFTs between different chains, enhancing:

Liquidity – NFTs can be traded across multiple ecosystems.
Utility – Users can access different dApps on multiple chains.
Scalability – Avoid congestion on expensive chains like Ethereum.

The base chain, where an NFT collection originates, plays a crucial role in determining the overall value and functionality of the NFTs.

Security and Trust: The base chain provides the foundational security for the NFT collection. A well-established chain like Ethereum offers robust security features, which can enhance the trustworthiness of the NFTs. While an L2 like Base can offer lower gas fee. There’s several factors that you can think of while deciding the base chain for your NFT collection.
Network Effects: The popularity and user base of the base chain can significantly impact the visibility and adoption of the NFT collection. A chain with a large community can drive more engagement and transactions.
Ecosystem and Tools: The base chain often dictates the available development tools and ecosystem support. A rich ecosystem with various dApps and services can add more utility to the NFTs, allowing them to be used in diverse applications.
Transaction Costs: The cost of transactions on the base chain can affect the affordability and frequency of NFT trades. Chains with lower fees can encourage more trading activity, while high fees might deter users.
Interoperability: The base chain’s compatibility with other chains can determine how easily NFTs can be transferred across different networks. A chain that supports cross-chain protocols can enhance the liquidity and utility of the NFTs. It’s very important that you do not choose a chain which doesn’t allow access to outside network at all.
Innovation and Upgrades: The pace of innovation and the ability to implement upgrades on the base chain can influence the long-term viability and features of the NFT collection. Chains that are actively developed and improved can offer more advanced capabilities over time. Never go for a chain, which has stangant development or takes too long to iterate.

However, we can not expect all the users to remain on any single network. So, we need to prepare for the seemless moving around of assets cross-chain, thereby improving interoperability.

And of course, there are several approaches to achieve bridging, depending on how you structure your product. Let’s go ahead with a classic approach this time.

How It Works

Lock the NFT on Chain A (BridgeA contract).
Send a cross-chain message using LayerZero to Chain B.
BridgeB contract receives the message and mints a wrapped NFT on Chain B.
To return the NFT, the wrapped NFT is burned on Chain B, and a message is sent back to unlock the original NFT.

🏛 On-Chain Relayer (Our Approach)

✅ Fully decentralised, no external trust required.
✅ All logic is enforced via smart contracts.
✅ Works with protocols like LayerZero or Axelar.

⚡ Off-Chain Relayer

❌ Requires external nodes/validators to confirm transactions.
❌ Can introduce centralisation and trust assumptions.
❌ Relayers may become a point of failure.

Our on-chain approach ensures security and trustlessness by leveraging smart contracts for message passing. We’re using EVM chains for this example so the contracts preferrably written in solidity.

NFT Contract

First, deploy an ERC-721 NFT contract on both chains:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MyNFT is ERC721URIStorage, Ownable {
    uint256 public nextTokenId;
    
    constructor() ERC721("MyNFT", "MNFT") {}
    
    function mint(string memory tokenURI) external onlyOwner {
        _safeMint(msg.sender, nextTokenId);
        _setTokenURI(nextTokenId, tokenURI);
        nextTokenId++;
    }
}

Bridge Contract (Chain A) – Lock NFT & Send Message

Create BridgeA.sol on Chain A:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@layerzerolabs/solidity-examples/contracts/lzApp/NonblockingLzApp.sol";

contract BridgeA is NonblockingLzApp {
    ERC721 public nft;
    address public admin;

    event NFTLocked(address indexed user, uint256 tokenId);

    constructor(address _nft, address _lzEndpoint) NonblockingLzApp(_lzEndpoint) {
        admin = msg.sender;
        nft = ERC721(_nft);
    }

    function lockNFT(uint256 tokenId, uint16 destChainId, bytes memory receiver) external payable {
        require(nft.ownerOf(tokenId) == msg.sender, "Not NFT owner");
        nft.transferFrom(msg.sender, address(this), tokenId);
        bytes memory payload = abi.encode(msg.sender, tokenId);
        _lzSend(destChainId, payload, payable(msg.sender), address(0), bytes(""), msg.value);
        emit NFTLocked(msg.sender, tokenId);
    }

    function _nonblockingLzReceive(uint16, bytes memory, uint64, bytes memory payload) internal override {}
}

Bridge Contract (Chain B) – Receive & Mint Wrapped NFT

Create BridgeB.sol on Chain B:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@layerzerolabs/solidity-examples/contracts/lzApp/NonblockingLzApp.sol";

contract BridgeB is ERC721URIStorage, NonblockingLzApp {
    address public admin;
    uint256 public nextTokenId;

    event NFTMinted(address indexed user, uint256 tokenId);

    constructor(address _lzEndpoint) ERC721("WrappedNFT", "WNFT") NonblockingLzApp(_lzEndpoint) {
        admin = msg.sender;
    }

    function _nonblockingLzReceive(uint16, bytes memory, uint64, bytes memory payload) internal override {
        (address user, uint256 tokenId) = abi.decode(payload, (address, uint256));
        _safeMint(user, nextTokenId);
        _setTokenURI(nextTokenId, "https://metadata-url");
        emit NFTMinted(user, nextTokenId);
        nextTokenId++;
    }
}

Unlocking NFTs (Return to Chain A)

Modify BridgeB.sol to burn the wrapped NFT and send it back:

function burnNFT(uint256 tokenId, uint16 destChainId) external payable {
    require(ownerOf(tokenId) == msg.sender, "Not NFT owner");
    _burn(tokenId);
    bytes memory payload = abi.encode(msg.sender, tokenId);
    _lzSend(destChainId, payload, payable(msg.sender), address(0), bytes(""), msg.value);
}

Modify BridgeA.sol to release the original NFT:

function _nonblockingLzReceive(uint16, bytes memory, uint64, bytes memory payload) internal override {
    (address user, uint256 tokenId) = abi.decode(payload, (address, uint256));
    nft.transferFrom(address(this), user, tokenId);
}

Let’s test our Bridge:

Deploy contracts on two testnets (say, Base Sepolia & Polygon Amoy).
Mint an NFT on Chain A.
Lock & transfer the NFT using the bridge.
Verify minting of wrapped NFT on Chain B.
Burn wrapped NFT to return to Chain A.

Future Improvements that can be made:

Multi-Chain Support

To enhance the functionality and reach of our bridge, we can consider adding support for additional EVM-compatible chains. This would involve integrating with popular networks like Binance Smart Chain, Avalanche, and Fantom, which would allow users to transfer NFTs across a wider range of platforms. Furthermore, expanding beyond EVM-compatible chains to include other blockchain ecosystems, such as Solana, Cosmos, and Polkadot, could significantly broaden the bridge’s capabilities. This expansion would require developing interoperability solutions to handle the unique characteristics and consensus mechanisms of these different blockchains. By doing so, we would enable seamless NFT transfers across a diverse array of blockchain networks, providing users with greater flexibility and access to a wider audience. This strategic enhancement could position our bridge as a leading solution in the rapidly evolving multi-chain NFT landscape.

Cross-Chain Fees

Implementing gas abstraction can significantly enhance the user experience by making transactions more seamless and user-friendly. Gas abstraction involves creating a system where users do not need to worry about paying gas fees directly in cryptocurrency. Instead, the system can handle these fees on behalf of the users, possibly by integrating a third-party service or using a relayer network. This approach can simplify the transaction process, especially for users who are not familiar with blockchain technology or do not hold the native cryptocurrency required for gas fees. By abstracting gas fees, developers can create a more intuitive and accessible platform, encouraging broader adoption and reducing barriers for entry into the blockchain ecosystem. Additionally, this can be particularly beneficial in scenarios involving cross-chain interactions, where users might otherwise need to manage multiple cryptocurrencies for gas fees on different chains.

Decentralised Governance

Decentralised Autonomous Organisations (DAOs) can play a crucial role in managing and governing bridge policies. By introducing DAO-controlled bridge policies, we can ensure that the decision-making process is transparent, democratic, and community-driven. This means that all stakeholders, including developers, users, and investors, can participate in proposing, discussing, and voting on changes to the bridge’s operational rules and guidelines. Such a system can enhance trust and accountability, as decisions are made collectively rather than by a centralised authority. Additionally, DAO governance can adapt more quickly to the evolving needs of the community and the market, allowing for more responsive and flexible policy adjustments. By leveraging the power of DAOs, we can create a more resilient and adaptable bridge infrastructure that aligns with the interests and values of its users.

Note that this was for learning purposes only. The real contracts will have to consider several security issues and vulnerabilities which we’ve assumed here, as part of the happy path. But it’s a start and would love to see at least some of you try it out and build more decentralised bridges. The bridges ecosystem is both quickly evolving and stagnant at the same time. Cross-chain messaging protocols have certainly pulled in a pin off the race for building decent decentralised bridges, but we’ve quite a few improvement yet to be made to achieve true trustless systems.

WebAssembly and Python Ecosystem

2025-02-05T00:00:00Z

WebAssembly (WASM) is transforming how we run code in lightweight, secure, and cross-platform environments. Initially designed for browsers, WASM has now expanded into serverless computing and sandboxed environments. While languages like Rust and Go have robust WASM support, Python’s dynamic nature makes it challenging to run efficiently in WASM today.

Why WebAssembly for Serverless Computing?

Near-Instant Startup: WASM executes with minimal cold-start time, unlike containers.
Enhanced Security: WASM runs in a sandboxed environment, preventing unauthorised system access.
Compact Footprint: WASM modules are lightweight and easy to distribute.
Platform Agnostic: Runs seamlessly in browsers, cloud environments, and edge devices.
Network Agnostic: WASM can easily run on private clusters and secondary networks, making it the best choice even in Web3.0 ecosystem.

Despite these advantages, running Python efficiently in WASM poses unique challenges. So, let’s explore a few nuances and the current ecosystem looks like. We will then explore how we can work towards improving the current situation taking learnings from rust and go ecosystems.

Running Python in WebAssembly

1. Using Pyodide (CPython in WASM)

Pyodide compiles CPython to WASM, allowing Python to run in browsers and serverless environments.

Install Pyodide:

pip install pyodide

Run a Python Script in Pyodide:

import pyodide

async def run_python_code():
    py = await pyodide.loadPyodide()
    result = py.runPython("print('Hello from Pyodide!')")
    print(result)

await run_python_code()

2. Using PyScript (Python in the Browser with WASM)

PyScript simplifies running Python in the browser via Pyodide.

Run Python in HTML:

<!DOCTYPE html>
<html lang="en">
<head>
    <script defer src="https://pyscript.net/latest/pyscript.js"></script>
</head>
<body>
    <py-script>
        print("Hello from PyScript!")
    </py-script>
</body>
</html>

3. Using RustPython (A Rust-based Python Interpreter in WASM)

RustPython, a Python interpreter written in Rust, is optimised for WASM.

Install RustPython:

git clone https://github.com/RustPython/RustPython.git cd RustPython cargo build --release --target wasm32-wasi

Run Python in RustPython (WASM):

use rustpython_vm::Interpreter;

fn main() {
    let interpreter = Interpreter::default();
    interpreter.enter(|vm| {
        vm.run_code("print('Hello from RustPython!')", vm.ctx.new_scope()).unwrap();
    });
}

Run using WASI runtime:

wasmtime rustpython.wasm

Deploying a FastAPI Serverless Function in WASM

Install FastAPI and Uvicorn

pip install fastapi uvicorn pyodide

Create a `main.py`

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def read_root():
    return {"message": "Hello from WASM!"}

Run in Pyodide (WASM Runtime)

import pyodide
async def run_wasm():
    py = await pyodide.loadPyodide()
    await py.runPythonAsync("from main import app")
    print("FastAPI running in WebAssembly")
await run_wasm()

Performance Benchmark: WASM vs. Traditional Containers vs. Rust/Go WASM

We benchmark FastAPI deployed in:

WASM (Pyodide)
Docker (Traditional Serverless Container)
WASM (RustPython)

For fair comparision, we need to also look at wasm ecosystem in rust and go. As the current python wasm ecosystem is lacking, we should also take a look at what’s happening with our neighboring language ecosystems.

Benchmarking with wrk:

wrk -t4 -c100 -d30s http://localhost:8000/

Approx Results:

Environment	Requests/sec	Avg Latency
WASM (Pyodide)	~500	10-30ms
Docker (FastAPI)	~2000+	3-5ms
WASM (RustPython)	~800	7-15ms
WASM (Rust)	~5000+	<1ms
WASM (Go)	~4000+	<2ms

So, what can be conclude:

Rust and Go compiled to WASM vastly outperform Python-based WASM implementations.
Docker offers the best throughput for Python applications, making it ideal for high-performance APIs.
RustPython outperforms Pyodide but remains slower than Rust/Go.
Pyodide is more portable but has higher latency, making it ideal for browser-based execution.
WASM offers greater security and portability but exhibits slightly higher latency than Docker.

WebAssembly is an exciting technology for serverless Python computing, offering:
✅ Faster startup times
✅ Enhanced security
✅ Improved portability

However, for high-performance applications, Rust and Go WASM implementations significantly outperform Python-based approaches. Python WASM is improving rapidly, and as tools like Pyodide, PyScript, and RustPython advance, Python’s role in serverless WASM environments will continue to expand. 🚀

Minimising Dependencies

2025-02-01T00:00:00Z

In today’s world, technology is often seen as a tool for efficiency, but in reality, it has become a structure of control. Operating systems dictate how we interact with software, app stores determine what we can access, and centralised networks govern our digital presence. The prevailing belief is that these structures are necessary for stability, security, and usability. However, don’t you think that technology should minimise dependencies rather than create them. Instead of being locked into specific platforms, users and developers should be free to interact, build, and own their digital experiences without artificial barriers.

The future of computing and web can not be walled gardens but open, permissionless, and decentralised protocols. We need to rethink the fundamental design of digital ecosystems, not as closed systems but as universal environments where applications and services are accessible to all, without intermediaries.

Currently, the digital world is built on a fragmented ecosystem of operating systems, Windows, MacOS, and Linux, each with its own architecture, software packaging formats, and compatibility constraints. Even within Linux, the presence of multiple distributions (Ubuntu, Fedora, Arch, etc.) means that software developers must support various package managers like DEB, RPM, AppImage, Flatpak, Homebrew and Snap. This creates unnecessary complexity and overhead, forcing developers to maintain multiple versions of their applications, resolve dependency conflicts, and manage frequent updates for each platform.

Beyond operating systems, cloud services and centralised application marketplaces have further deepened our dependence on proprietary infrastructures. Most modern applications rely on centralised servers for authentication, data storage, and computing resources, making them vulnerable to downtime, censorship, and high costs. This centralised model not only limits innovation but also creates gatekeepers who control access to digital services.

Remeber Tor? “The Onion Router”, an open-source privacy network designed to enable anonymous web browsing. It employs a technique called onion routing, which encrypts user data and bounces it through a series of volunteer-operated servers, or nodes, making it difficult to trace the origin of the traffic. It’s quite popular amongst tech audience but not so much known in the newer generation and is slowly fading away yet still. Why? It’s an incredible network and project.

Because, it several challenges for regular users, primarily related to access, security, performance, and user experience. Many websites block traffic from Tor exit nodes, leading to difficulties accessing certain sites and frequent CAPTCHA prompts. Additionally, users face security risks from potentially malicious exit nodes that could intercept unencrypted traffic. Performance can also be an issue, as Tor often results in slower internet speeds and connection problems due to its complex routing process. Furthermore, the setup of Tor can be complicated for less tech-savvy individuals, which may discourage them from using the network effectively. The association of Tor with illegal activities can also create negative perceptions, impacting users’ willingness to utilise it for legitimate purposes. Overall, while Tor offers enhanced privacy, these challenges can significantly affect the user experience.

Do we need a network then? No, we already got the tech. Started with TOR, but current web3 vibrant and somewhat crazy ecosystem is already making it’s mark. So, what do we need?

How about a new OS?

This is where CyberSpace OS comes in. A fully decentralised operating system that exists entirely on Web3 networks, offering a new way to interact with technology that is free from the constraints of traditional software and hardware ecosystems. CyberSpace OS, designed to break free from these limitations by offering a truly universal execution environment where applications are deployed directly on-chain as smart contracts or Web3-native dApps. Instead of being tied to a specific OS or hardware architecture, software would exist independently on a decentralised network, accessible from any device.

With CyberSpace OS:

Developers deploy once on a blockchain and make their applications universally accessible.
Users interact with applications without requiring installations, updates, or dependencies on traditional OS platforms.
The operating system itself is not a software package but a network protocol, meaning that access to applications is fluid, borderless, and truly open.
The storage is partially distributed and partially **InterPlanetary File System (**IPFS) based.

This approach eliminates the need for package managers, compatibility layers, or centralised repositories. Instead of apps being tied to Windows, MacOS, or Linux distributions, they become accessible through decentralised execution environments that are maintained across a distributed network. With smart contract-driven applications, developers no longer need to worry about distribution logistics or maintenance across multiple platforms. Everything is handled in a trustless, automated manner on the blockchain.

The benefits of a Web3-native OS extend far beyond decentralisation for its own sake. By eliminating dependencies on traditional operating systems and cloud infrastructure, CyberSpace OS drastically reduces costs associated with software development, distribution, and hosting.

Cost Efficiency: Cloud services are expensive, requiring developers to pay for hosting, maintenance, and bandwidth. With a decentralised network, computing resources can be distributed across nodes, reducing infrastructure costs while ensuring redundancy and uptime.
Performance Gains: Instead of routing traffic through centralised data centers, decentralised execution allows applications to run closer to the end user, reducing latency and improving performance. By utilising Layer 2 scaling solutions, zk-rollups, and distributed computing, CyberSpace OS ensures high efficiency without sacrificing security.
Simplified Development: Developers no longer need to manage different OS versions, dependencies, or update cycles. A single deployment on CyberSpace OS ensures their application is always accessible and up to date.

Building Towards a Truly Open CyberSpace

The long-term vision of CyberSpace OS is to create a self-sustaining digital world, where users are not just consumers but active participants in an open, decentralised economy. Instead of relying on tech giants for software, storage, and computing, individuals and communities can collectively own and govern the infrastructure they depend on.

In this world:

Users own their data and identity, free from the control of centralised platforms.
Applications run on decentralised networks, ensuring resilience and censorship resistance.
The operating system itself is not an installable product but an evolving, trustless environment that runs across the blockchain.

The Future is Protocol-Based, Not Platform-Based

For decades, the digital landscape has been dominated by platforms. Closed systems that dictate how technology is used, who has access, and how data flows. CyberSpace OS proposes an alternative: a world where protocols replace platforms, ensuring that applications, services, and digital interactions remain open, permissionless, and universally accessible.

This is not just an evolution of computing, it’s a fundamental shift in how we think about technology. By removing artificial dependencies and embracing decentralised, trustless networks, we can build a truly open CyberSpace. One where innovation is unhindered, costs are minimised, and users have complete control over their digital lives.

The time has come to break free from outdated models and build an operating system for the future. CyberSpace OS is not just another alternative. It is the foundation for a new digital era!

Decentralised Identity

2025-01-19T00:00:00Z

As the digital world transitions to Web3, decentralisation promises to redefine how we interact online securely, privately, and without intermediaries. At the heart of this revolution lies Decentralised Identity (DID), a technology aimed at giving users complete control over their identity and interactions in the decentralised ecosystem. Let’s explore the world of DIDs and the impact it can have on our day-to-day life.

In the Web2 paradigm, identity is centralised. Platforms like Google, Facebook, and Apple dominate authentication and identity management. A typical Web2 authentication flow involves:

User Credential Storage: Users create accounts on each platform, storing sensitive information like passwords and personal data.
Centralised Control: Platforms manage, validate, and store user identities, often sharing data with third parties.
Security and Privacy Risks: These centralised models are prone to breaches, data misuse, and lack transparency.

This fragmented and insecure approach calls for a shift toward a decentralised and user-controlled identity system.

What is DID?

DID is a self-sovereign identity system that allows users to create and control their identity without relying on centralised entities. A DID is a unique identifier tied to a cryptographic key, resolving to a DID Document stored on decentralised networks.

For example:

A DID might look like did:ethr:0x1234...abcd.
It is portable, privacy-preserving, and interoperable across platforms and chains.

DIDs significantly improve user experience by addressing critical pain points.

Unified Identity Across Platforms: A single DID replaces the need for multiple accounts. Users can log in to various apps using the same identity.
Enhanced Privacy: DIDs minimise data sharing. Users can verify their identity without exposing personal information using verifiable credentials.
True Ownership: Unlike centralised accounts, users own their DID, data, and assets.
Cross-Chain Interoperability: DIDs work seamlessly across blockchains, enabling a consistent user experience.
Gasless Transactions: Relayers linked to a DID can abstract gas fees, improving accessibility.

Creating and Using a DID

Users connect their Ethereum wallet (e.g., MetaMask) to a service that registers a DID, like a smart contract-based DID Registry.

Here’s a basic smart contract for an Ethereum-based DID Registry:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract DIDRegistry {
    mapping(address => string) private dids;
    event DIDRegistered(address indexed user, string did);

    function registerDID(string memory _did) public {
        require(bytes(dids[msg.sender]).length == 0, "DID already exists");
        dids[msg.sender] = _did;
        emit DIDRegistered(msg.sender, _did);
    }

    function getDID(address _user) public view returns (string memory) {
        return dids[_user];
    }
}

Applications resolve your DID to verify your identity and retrieve associated credentials, ensuring secure, password-free login.

Your DID’s associated data, like profile information, is stored on decentralised networks such as Ceramic or IPFS, ensuring ownership and privacy.

Imagine a gaming app, that integrates DID for seamless user experiences:

Onboarding: Users log in with their Ethereum wallet, and the app generates their DID (did:ethr:0x123...).
Cross-Platform Interactions: Achievements earned in one game are verifiable credentials usable across other games.
Social Features: Users add friends via their DID or ENS name (e.g., GamerX.eth) and engage in encrypted chats using DIDComm.
Gasless Play: The app abstracts gas fees, ensuring smooth gameplay.

ENS and .eth Domains: Simplifying DID

Ethereum Name Service (ENS) bridges DIDs and user-friendliness. ENS translates long wallet addresses or DIDs into readable names like john.eth.

What .eth Means: It’s a human-readable domain linked to a DID or wallet.
How It Works: ENS uses smart contracts to map john.eth to an Ethereum address, which can be further linked to a DID for interoperability.

Evolution of DIDs

DIDs make interacting with multiple blockchains simple by providing a unified identity layer. Regardless of whether an app runs on Ethereum, Polygon, or another chain, users only need one DID.

Example Use Case:
In a gaming app, a DID enables:

Asset purchases on Ethereum.
Gameplay interactions on Polygon.
A unified user profile across both chains.

Account abstraction turns wallets into programmable entities. When paired with a DID, users gain access to features like:

Gasless Transactions via relayer services.
Custom Authentication with biometrics or social recovery.
Programmable Wallets tied to their DID for automated actions.

Several active works going on in the field of DIDs:

W3C Standards: Ongoing efforts to standardise DID and Verifiable Credentials. Read more here.
Layer 2 Scaling: Optimising DID operations with zk-Rollups and optimistic rollups.
Social Recovery Models: Community-based wallet recovery mechanisms tied to DIDs.
Cross-Chain Abstraction: Projects like Axelar and LayerZero are exploring DID integration for seamless multichain interoperability.

Challenges:

Adoption: Many apps still rely on centralised account systems.
Standardisation: Consistent DID implementation across platforms and chains is essential.

As Web3 evolves, DIDs will play a pivotal role in bridging the gap between user experience and decentralisation. By abstracting away the complexities of blockchain interactions, DIDs empower users with control over their identities, assets, and data while enabling cross-platform interoperability.

While DID is transformative, its adoption depends on achieving a balance between technical complexity and user experience. The goal is a Web3 ecosystem where users can easily create, use, and manage their decentralised identities without worrying about the underlying technology, a future where identity is truly in the hands of the user.

Understanding Liquidity Pools in Web3

2025-01-10T00:00:00Z

Liquidity pools in the context of traditional finance evolved over centuries, rooted in mechanisms designed to ensure that buyers and sellers can transact with minimal price volatility and at the right time. These mechanisms laid the foundation for the more modern, decentralized liquidity pools found in today’s digital finance (DeFi). In the early stages of financial markets, liquidity was primarily provided by market makers, typically wealthy individuals or institutions, who were willing to hold inventories of assets (stocks, bonds, commodities) and facilitate trades by ensuring there were always both buyers and sellers for each asset. In the 17th century, the Amsterdam Stock Exchange (established in 1602) was one of the first venues where market makers helped provide liquidity by buying and selling stocks of the Dutch East India Company. This early form of liquidity provision was crucial in establishing stock trading as a viable form of investment. As financial markets grew throughout the 20th century, exchanges like the New York Stock Exchange (NYSE) (founded in 1792) and the London Stock Exchange (LSE) (founded in 1801) became central hubs for securities trading. These exchanges facilitated liquidity by creating centralized venues where buyers and sellers could meet.

During the 1960s to 1980s, institutional investors such as mutual funds, pension funds, and hedge funds began playing a more significant role in managing large pools of capital. These funds were used to buy and sell a variety of assets, providing additional liquidity to financial markets. Mutual funds and Exchange-Traded Funds (ETFs), for example, pooled capital from individual investors and made it easier for smaller investors to access large-scale liquidity. The creation of the SPDR S&P 500 ETF in 1993 by State Street Global Advisors allowed institutional investors to pool their capital and give individual investors access to liquidity through the trading of ETF shares. In the 1970s, money market funds emerged as a way for investors to earn interest while providing liquidity to short-term debt markets. These funds pooled capital from many individual investors and invested in low-risk, short-term debt instruments like Treasury bills, certificates of deposit (CDs), and commercial paper. The Vanguard Prime Money Market Fund, launched in the 1970s, became one of the largest money market funds, pooling capital and providing liquidity to short-term debt markets.

In the 1980s and beyond, derivatives markets like futures, options, and swaps created sophisticated ways to hedge risks and add liquidity to underlying assets. These markets allowed traders to take positions on assets without directly buying or selling the asset itself, increasing liquidity and providing more ways to trade. The Chicago Mercantile Exchange (CME) became a major hub for the trading of derivatives, offering futures contracts on commodities, financial instruments, and even stock indexes, which provided added liquidity and price discovery. The 2008 global financial crisis highlighted the importance of liquidity in maintaining financial stability. Central banks stepped in to provide liquidity to the banking system through quantitative easing (QE) and other monetary policy tools. By buying assets such as government bonds, central banks created “liquidity pools” to stabilize financial markets and prevent a collapse of the banking system. The U.S. Federal Reserve implemented QE to inject liquidity into the economy by purchasing U.S. Treasury bonds and mortgage-backed securities (MBS). This action helped stabilize the financial system and provided banks with more liquidity to operate.

A liquidity pool in Web3 refers to a collection of funds locked into a smart contract to facilitate decentralized trading, lending, and other financial activities on blockchain networks. It’s a foundational concept in decentralized finance (DeFi), enabling platforms to function without relying on traditional intermediaries like banks or centralized exchanges.

At its core, a liquidity pool provides liquidity (available assets) for decentralized exchanges (DEXs) or other DeFi protocols, allowing users to trade assets efficiently. Popularized by platforms like Uniswap and Balancer, liquidity pools have become integral to the success of the decentralized ecosystem.

Liquidity pools eliminate the need for traditional financial intermediaries like banks, brokers, or centralized exchanges. Instead, they use smart contracts to automate transactions and ensure trustless operations. This reduces costs, speeds up processes, and democratizes access to financial tools.

Decentralized Exchanges (DEXs): Platforms like Uniswap rely on liquidity pools for trading, replacing the traditional order book model with an automated market maker (AMM).
Trustless Transactions: Users can trade directly from their wallets without trusting a centralized entity with custody of their funds.

Liquidity pools enable 24/7 trading without the constraints of traditional market hours. Unlike centralized systems, which can experience downtime due to technical or operational issues, DeFi platforms operate as long as the blockchain they’re built on is running. This ensures constant liquidity and access for users worldwide.

Anyone with internet access and compatible assets can participate in liquidity pools, whether as a trader, liquidity provider, or investor. This inclusivity empowers individuals in regions with limited access to traditional financial systems, fostering global financial inclusion. Liquidity pools provide access to global markets for individuals who may lack bank accounts but have access to cryptocurrency. They allow seamless trading and liquidity provisioning across borders without additional fees or delays.

Traditional exchanges rely on order books where buyers and sellers must match their orders. This process can lead to delays, especially for low-volume assets. Liquidity pools eliminate this dependency by enabling instant trades based on the pool’s available liquidity and AMM pricing model. Even obscure tokens with limited trading activity can find liquidity through pools, fostering a more vibrant and diverse market.

Liquidity pools offer opportunities for users to earn passive income by becoming liquidity providers (LPs). In return for supplying assets to the pool, LPs earn a share of the transaction fees and, in many cases, additional rewards in the form of governance or incentive tokens.

Yield Farming: Many DeFi platforms introduce farming programs where LPs can stake their LP tokens to earn even higher rewards.
Compounding Rewards: By reinvesting earnings, LPs can maximize their returns over time.

In traditional finance, centralized entities or whales (large holders of assets) can manipulate markets by controlling liquidity. Liquidity pools, governed by smart contracts and often decentralized communities, mitigate this risk by spreading liquidity among many participants and operating transparently.

Liquidity pools enable innovative financial products and services that were not feasible in traditional systems, such as:

Token Swaps: Instant swapping between tokens without needing a counterpart.
Synthetic Assets: Creating and trading assets that mirror real-world commodities, stocks, or other financial instruments.
Flash Loans: Borrowing assets instantly without collateral, provided the loan is repaid within the same transaction block.

Liquidity pools help bootstrap new projects and tokens by providing initial liquidity, enabling seamless trading and adoption from day one. Projects can create liquidity pools to ensure users can easily buy and sell their tokens, fostering early adoption. Many platforms distribute governance tokens to LPs, encouraging decentralized decision-making and long-term community involvement. In centralized systems, trading and financial activities can be restricted by governments or institutions. Liquidity pools, hosted on decentralized blockchains, are resistant to censorship, ensuring that users retain their financial sovereignty. Liquidity pools increase the usability of tokens within an ecosystem. By locking tokens in pools, they gain immediate utility as tradeable and yield-generating assets. Even highly volatile tokens find utility and stability when paired in liquidity pools, as they facilitate trading and incentivize holders to provide liquidity.

How does it work?

A liquidity pool typically consists of two assets paired together (e.g., ETH/USDT). These pools operate using Automated Market Makers (AMMs), which determine the price of assets within the pool based on supply and demand using mathematical formulas.

Example of AMM Formula:

One common formula is the constant product formula:

$$x⋅y=k$$

Where:

x and y are the quantities of the two assets in the pool.
k is a constant.

When a user trades, the AMM adjusts the asset quantities, ensuring the product k remains constant. This model ensures liquidity at any price point.

Steps for Trading:

A user sends one asset (e.g., ETH) to the pool.
The pool provides the equivalent value of the other asset (e.g., USDT) based on the AMM formula.
The trade is executed instantly via the smart contract.

Starting and Participating in a Liquidity Pool

Starting a Pool:
- Identify a platform supporting liquidity pools (e.g., Uniswap, PancakeSwap, Balancer).
- Choose a pair of assets and decide the initial liquidity ratio.
- Deposit the assets into the smart contract to initialize the pool.
- Pay the associated gas fees for the transaction.
Participating in an Existing Pool:
- Select a pool and review its metrics (e.g., volume, fees, and liquidity).
- Deposit an equal value of the two assets into the pool.
- Receive liquidity provider (LP) tokens, which represent your share of the pool.

Risks Associated with Liquidity Pools

While liquidity pools offer significant opportunities, they also come with inherent risks. Understanding these risks is crucial for anyone looking to participate as a trader, investor, or liquidity provider (LP).

Impermanent Loss

Impermanent loss occurs when the price of the assets in a liquidity pool changes relative to their price when you initially deposited them. The loss is “impermanent” because it only materializes if you withdraw your assets before the prices revert. Suppose you deposit 1 ETH and 100 USDT into a pool (assuming ETH is priced at $100). If ETH’s price rises to $200, the AMM adjusts the pool’s asset ratio to maintain balance. When you withdraw, you might receive less ETH than expected, and the value of your holdings may be lower than if you had simply held the assets separately.

Who is Most Affected?:
- LPs in volatile asset pairs are more susceptible.
- Pools with stablecoins or correlated assets (e.g., USDC/DAI) experience minimal impermanent loss.

Mitigation:

Opt for pools with stable or correlated assets.
Monitor asset prices and withdraw strategically when the market stabilizes.

Smart Contract Risks

Liquidity pools rely on smart contracts, which are vulnerable to bugs, coding errors, or malicious exploits. A single vulnerability can lead to a complete loss of funds in the pool. For example, exploiters can use large, instant loans to manipulate the pool’s pricing algorithm, draining assets called Flash Loan Attack. Another classic vulnerability called reentrancy attack where an attacker repeatedly calls a function before its initial execution is completed. In 2020, the Harvest Finance hack exploited an imperfection in the protocol, leading to a loss of over $24 million.

Mitigation:

Participate in pools from reputable platforms that undergo regular audits.
Diversify your liquidity across multiple pools to reduce exposure.

Slippage and Price Impact

Large trades can cause significant changes in the price of assets within the pool. This is especially prevalent in pools with low liquidity.

Slippage: The difference between the expected price of a trade and the actual price executed.
Price Impact: For large trades, the AMM may shift the pool’s asset ratio significantly, causing unfavorable trading conditions.

Mitigation:

Trade in high-liquidity pools where slippage is minimal.
Break large trades into smaller chunks to reduce price impact.

Market Volatility Risks

Crypto markets are notoriously volatile, and sudden price swings can impact the value of your pool holdings or trading activities. A sudden market crash might cause users to withdraw funds all together, depleting liquidity and leading to higher slippage for trades.

Mitigation:

Choose pools with stable or less volatile assets if you’re risk-averse.
Keep a close eye on market conditions and adjust your strategy accordingly.

Regulatory Risks

Regulatory frameworks for DeFi are still evolving. Participating in liquidity pools can expose users to legal and compliance risks, especially in regions with unclear or restrictive crypto regulations.

Potential Issues:
- KYC/AML compliance requirements may conflict with the anonymous nature of DeFi.
- New laws could classify LP tokens or governance tokens as securities, subjecting participants to additional legal obligations.
Jurisdictional Risks:
- Some countries may outright ban or heavily regulate DeFi platforms, leaving users in legal limbo.

Mitigation:

Stay informed about the regulations in your jurisdiction.
Consider using platforms that comply with regional laws and offer transparency.

Liquidity Mining Risks

Liquidity mining, where platforms offer extra rewards (e.g., governance tokens) to incentivize LPs, can sometimes lead to unsustainable economic models.

Risks:
- High rewards may attract short-term participants, leading to “farm and dump” behavior where tokens lose value rapidly.
- Protocols offering unrealistic returns may collapse, leaving LPs with worthless assets.

Mitigation:

Focus on protocols with sustainable reward models.
Diversify your positions across different pools and platforms.

Governance and Protocol Risks

DeFi platforms often allow governance token holders to vote on changes. While this promotes decentralization, it can also introduce risks.

Potential Issues:
- Governance takeovers: A whale or coordinated group could gain control of the protocol and implement self-serving changes.
- Poor decision-making: Ineffective governance decisions may lead to changes that negatively impact liquidity providers or traders.

Mitigation:

Participate in governance if you hold tokens.
Choose platforms with robust and active communities.

Platform-Specific Risks

Every DeFi platform operates differently, and some may have unique risks.

Unforeseen Risks:
- Algorithmic errors in the AMM formula.
- Failures in price oracles leading to incorrect pricing.
Dependency on Blockchain:
- Congestion or high gas fees on the underlying blockchain (e.g., Ethereum) can make transactions prohibitively expensive.

Mitigation:

Research the platform thoroughly before depositing assets.
Prefer platforms with a proven track record and robust infrastructure.

Rug Pulls and Exit Scams

Rug pulls occur when the creators of a liquidity pool or DeFi project withdraw all liquidity or funds, leaving participants with worthless assets. Unscrupulous developers launch a pool with enticing rewards, then drain the funds once liquidity is locked in.

Signs of Potential Rug Pulls:
- Anonymous or unverifiable team members.
- Lack of audits or transparency about smart contracts.
- Lack of project expansion and clear roadmap ahead.

Mitigation:

Avoid newly launched or unaudited projects.
Choose established platforms with strong reputations.

Governance of Liquidity Pools

Governance of liquidity pools is crucial for maintaining the integrity, functionality, and adaptability of DeFi ecosystems. By balancing decentralization with effective decision-making structures, liquidity pools can ensure sustainable growth while empowering their communities to shape their future. As such, it’s a much bigger topic to be covered in this article, so I’ll probably take it up in a following article. Let’s cover a few case studies in the meantime:

Uniswap : Uses UNI tokens for governance, allowing the community to vote on key protocol upgrades and treasury allocations. A highly decentralized model, but participation rates remain a concern.

Balancer: Balancer’s governance allows LPs to vote on pool parameters, incentivization strategies, and protocol improvements. Known for its innovative approach to managing multi-asset pools.

SushiSwap: SushiSwap’s governance is notable for its community-driven decision-making and frequent use of governance tokens to shape the protocol’s future.

Regulations and Legalities

KYC/AML Compliance: Some jurisdictions may require Know Your Customer (KYC) and Anti-Money Laundering (AML) measures for liquidity providers and DeFi protocols.

Taxation: Earnings from liquidity pools are often classified as taxable income or capital gains.

Securities Laws: In certain regions, LP tokens or governance tokens might be classified as securities, subjecting them to stringent regulations.

Consumer Protection: Protocols must ensure transparency about risks to protect participants from fraud or misinformation.

Use Cases of Liquidity Pools

Decentralized Exchanges (DEXs)

Liquidity pools power automated market makers (AMMs), which are the backbone of decentralized exchanges. Instead of relying on traditional order books, AMMs use liquidity pools to execute trades based on mathematical formulas.

Uniswap is one of the most popular DEXs, utilizing liquidity pools for trading various token pairs like ETH/USDT or DAI/USDC. Traders benefit from continuous liquidity, while liquidity providers earn a share of transaction fees. Uniswap’s innovative AMM model sparked the growth of DeFi and inspired similar platforms. Similar to Uniswap, Sushiswap adds features like yield farming and governance participation for liquidity providers. SushiSwap incentivizes liquidity providers through its native token, SUSHI.

Yield Farming and Liquidity Mining

Liquidity pools enable yield farming, where participants earn rewards by staking their assets in pools. Liquidity mining further incentivizes users by distributing governance tokens to liquidity providers.

PancakeSwap, a leading DEX on the Binance Smart Chain, rewards LPs with CAKE tokens. Users can “farm” additional rewards by staking LP tokens in Syrup Pools, amplifying their earnings. Curve Finance specializes in stablecoin pools, allowing users to earn yields by providing liquidity to pairs like USDC/DAI or USDT/USDC. Curve’s CRV token is distributed as a reward, with higher rewards for users who lock their tokens for governance participation.

Cross-Chain Swaps

Liquidity pools enable seamless asset transfers across different blockchains, breaking down silos between ecosystems.

ThorChain emerged as a cross-chain liquidity protocol that allows users to swap assets like BTC, ETH, and BNB without relying on centralized exchanges. Liquidity pools facilitate swaps by using native assets on both chains, ensuring trustless and efficient transactions. Multichain (formerly AnySwap) offers liquidity pools to bridge assets across multiple blockchains, including Ethereum, Binance Smart Chain, and Avalanche.

Synthetic Asset Creation

Liquidity pools are used to back synthetic assets, which are tokenized representations of real-world assets like stocks, commodities, or indices.

Synthetix enables the creation of synthetic assets (Synths) like sUSD (synthetic USD) and sBTC (synthetic Bitcoin). Liquidity pools ensure the collateralization of these Synths, allowing users to trade them on decentralized platforms. Mirror Protocol allows users to mint and trade synthetic assets that track the price of real-world stocks, such as mTSLA (mirrored Tesla). Liquidity pools enable trading and collateralization, providing exposure to traditional markets in a decentralized manner.

Lending and Borrowing Protocols

Liquidity pools also support lending and borrowing platforms, where users deposit assets to earn interest or borrow against their deposits.

Aave operates liquidity pools where users can lend assets like ETH, DAI, or USDC and earn interest. Borrowers can use their deposits as collateral to borrow other assets, creating a decentralized credit market. Compound allows users to supply assets into liquidity pools and earn COMP tokens as rewards. The protocol dynamically adjusts interest rates based on supply and demand in the pool.

Token Launchpads and Initial DEX Offerings (IDOs)

Liquidity pools play a critical role in token launchpads, where new projects launch their tokens and ensure liquidity from day one. Balancer’s liquidity pools are used for token launch events, offering flexible weight configurations for new tokens and stable assets. Projects can set up weighted pools to control price discovery during token launches. Polkastarter uses liquidity pools for IDOs, enabling projects to raise funds while providing liquidity for their tokens.

Stablecoin Stability and Arbitrage

Liquidity pools help maintain the stability of stablecoins by facilitating arbitrage opportunities and reducing price deviations.

Curve Finance’s stablecoin-focused liquidity pools minimize slippage and impermanent loss, making them ideal for stablecoin trades. Arbitrage traders help keep stablecoin prices aligned across platforms by leveraging Curve’s efficient pools. MakerDAO (DAI)’s liquidity pools on platforms like Uniswap and Curve ensure stable and efficient trading, helping maintain its peg to the US dollar.

Revenue Generation for DAOs and Protocols

Protocols can create liquidity pools to generate revenue for their treasuries, ensuring sustainable growth and development.

Yearn Finance’s Vaults use liquidity pools to optimize yield farming strategies, generating revenue for the protocol and its users. Governance ensures that funds are reinvested in development and user incentives. Bancor’s liquidity pools not only generate fees but also protect LPs from impermanent loss through its single-sided staking mechanism.

Insurance in DeFi

Liquidity pools are being used to back decentralized insurance protocols, where participants earn rewards by providing collateral for insurance claims.

Nexus Mutual uses liquidity pools to underwrite insurance policies for smart contract risks. Liquidity providers earn returns from premiums paid by users seeking coverage. InsurAce pools provide coverage for risks like smart contract failures, stablecoin de-pegging, and more, offering diversified risk management options.

Gaming and NFTs

Liquidity pools are now being integrated into gaming and NFT platforms, enabling new financial models within these ecosystems.

Axie Infinity’s liquidity pools allow users to trade AXS and SLP tokens, which are core to the game’s economy. Liquidity providers earn fees from the vibrant trading activity driven by the game’s popularity. Rarible pools facilitate liquidity for trading NFTs, ensuring users can buy and sell digital art seamlessly. The protocol rewards participants with RARI tokens for providing liquidity.

Variations of Liquidity Pools

Liquidity pools have evolved beyond the basic structures used in early decentralized finance (DeFi) protocols. Over time, developers and researchers have introduced various innovations, tailoring liquidity pools to specific use cases, improving capital efficiency, and reducing risks.

Dynamic Pools: Pools like Balancer allow more than two assets and adjust the weight of each asset dynamically.
Stablecoin Pools: Pools such as Curve optimize for minimal slippage when trading stablecoins.
Incentivized Pools: Platforms offer additional token rewards to attract liquidity providers.

The variations of liquidity pools highlight the rapid innovation in the DeFi space. From simple single-asset pools to complex hybrid and concentrated pools, these structures cater to diverse use cases, offering tailored solutions for trading, lending, yield generation, and more. Real-world examples like Uniswap v3, Curve, Bancor, and Balancer demonstrate the growing utility of liquidity pools, while research-driven innovations promise even greater efficiency and functionality in the future. As DeFi evolves, liquidity pools will remain central to its success, driving financial inclusion and innovation.

Liquidity pools are a cornerstone of DeFi, driving decentralization and innovation in the financial world. While they offer lucrative opportunities, it’s crucial to understand the associated risks and navigate the evolving regulatory landscape carefully. By doing so, users can leverage this revolutionary technology to unlock the full potential of decentralized finance.

Decentralising Bridges

2025-01-07T00:00:00Z

In simple terms, bridges are tools that allow the transfer of assets, data, or even smart contract instructions between different blockchain networks. Think of them as the highways connecting isolated blockchain cities. For example, if you have some Ethereum (ETH) but want to use it on the Binance Smart Chain (BSC), you’d use a bridge to “wrap” your ETH into a token that works on BSC.

The idea of blockchain bridges emerged as a response to the growing need for interoperability between siloed blockchain ecosystems. In the early days of blockchain, networks like Bitcoin and Ethereum operated in silos, each with its own set of rules, consensus mechanisms, and asset standards. This lack of connectivity limited the potential for innovation and collaboration across ecosystems.

The first generation of blockchain bridges appeared around 2017–2018 during the ICO boom, as developers began exploring ways to transfer value and data between Ethereum and other nascent chains like EOS and TRON. These early bridges were mostly centralized, operated by single entities or consortiums. While they were functional, they relied heavily on trust, which contradicted the decentralised ethos of blockchain.

By 2020, with the rise of DeFi (Decentralised Finance) and multi-chain ecosystems, the demand for more robust and decentralised bridges skyrocketed. Protocols like Polkadot and Cosmos introduced native interoperability solutions, while others like Ren and Thorchain developed bridges focused on specific use cases like Bitcoin-to-Ethereum transfers or decentralised swaps.

Today, blockchain bridges are a critical part of the Web3 infrastructure. They come in various forms, including:

Asset-Specific Bridges: Focused on transferring specific tokens (e.g., WBTC for Bitcoin on Ethereum).
Generic Message Bridges: Capable of transferring arbitrary data and instructions between chains (e.g., Axelar).
Layer 2 Bridges: Connecting Ethereum to its rollups (e.g., Arbitrum, Optimism).

The ecosystem now includes both centralized and decentralised options, with billions of dollars locked in bridge protocols. Innovations in bridging technology have also introduced concepts like state proofs and zk-rollups to enhance security and scalability. However, challenges like hacks and inefficiencies remain prevalent, making the decentralization and improvement of bridges more important than ever.

Centralised vs Decentralised Bridges

In general, centralized applications offer simplicity, speed, and easier regulatory compliance but come with risks related to control, security, and privacy. In contrast, decentralized applications provide enhanced security, transparency, and user autonomy, but may face complexities, performance issues, and governance challenges.

Feature	Centralized Bridges	Decentralized Bridges
Control	Operated by a single entity or organization.	Operated by distributed validators or smart contracts.
Trust Model	Requires users to trust the central operator to act honestly and securely.	Trustless. Relies on network consensus and cryptographic security.
Transparency	Limited. Users have little visibility into internal operations.	Fully transparent. Operations are recorded on-chain and governed by open protocols.
Censorship Resistance	Vulnerable to censorship. Operators can block or restrict transactions.	Resistant to censorship. No single entity can manipulate or block transactions.
Security Risks	Single point of failure. High risk of hacks or insider fraud.	Distributed risk. Depending on the robustness of the smart contracts and validator network.
Scalability	Often faster, as centralization allows for streamlined operations.	Can be slower due to the need for network consensus and decentralized verification.
Examples	Binance Bridge, Coinbase Wallet	Wormhole, Polygon Bridge, Axelar, Thorchain
Innovation Flexibility	Limited by the capabilities and goals of the operator.	Open to community-driven improvements and integrations.

There are 70+ bridges available today, distributed across various chains as per they support respectively.

Let’s explore some interesting projects amongst them to understand how they work further.

Axelar

Axelar is a decentralized interoperability network designed to facilitate secure communication and asset transfer across multiple blockchains. It operates using a robust, trustless infrastructure that prioritizes security and scalability. However, The multi-step verification process can lead to slightly longer transaction times compared to centralized solutions. Even so, Axelar stands out today as one of the prime go-to cross messaging layer due to some unique componenets:

Decentralised Validator Network: A network of validators runs the Axelar protocol, processing cross-chain transactions and maintaining security. Validators use Byzantine Fault Tolerant (BFT) consensus to ensure the system remains operational even if a subset of validators act maliciously.

Gateway Contracts: Each blockchain integrated with Axelar runs a gateway smart contract. These contracts act as the entry and exit points for messages and assets.

Cross-Chain Gateway Protocol (CGP): The CGP enables seamless communication between blockchains by packaging transactions, signing them, and relaying them securely.

One-Time Addresses: For each cross-chain transaction, Axelar generates a one-time deposit address. This mechanism simplifies user experience by eliminating the need to deal with complex multi-signature processes.

How Axelar Works:

A user initiates a transfer from Blockchain A to Blockchain B using Axelar’s API or SDK.
The asset is locked in the gateway contract on Blockchain A.
Axelar validators verify the transaction, package it, and relay it to Blockchain B.
On Blockchain B, the gateway contract mints or unlocks the equivalent asset, completing the transaction.

Wormhole

Wormhole is a decentralized bridge designed to connect high-performance blockchains like Solana, Ethereum, Binance Smart Chain, and others. It operates as a message-passing protocol, enabling both asset transfers and other data exchanges between chains. It did however, suffered a $325M exploit in 2022, highlighting the need for ongoing improvements. While decentralized, the relatively small number of Guardians poses a risk of collusion.

Guardians Network: A decentralized network of validators known as Guardians monitors multiple chains for events. Guardians verify cross-chain transactions and sign messages to validate them.

Core Layer: Handles the core logic for cross-chain messaging and ensures that data integrity is maintained.

Wrapped Assets: Tokens transferred via Wormhole are wrapped into equivalent representations on the target chain.

How Wormhole Works:

A user locks an asset in a smart contract on the source chain (e.g., Ethereum).
Guardians detect the lock event and sign a message confirming the transaction.
The signed message is relayed to the target chain (e.g., Solana).
On the target chain, the Wormhole protocol mints a wrapped version of the locked asset for the user.

Connext

Connext is a decentralized protocol designed to facilitate fast, secure, and cost-effective cross-chain communication. It achieves this by using state channels and a unique xCall architecture for transferring value and data across Layer 2 networks and Ethereum. Unlike other bridges, Connext is tailored for fast, low-cost communication between Ethereum rollups and other Layer 2 solutions. By leveraging state channels, Connext minimizes on-chain transactions, significantly reducing gas fees. With xCall, developers can integrate cross-chain functionality into their applications without dealing with complex bridging mechanics. Connext’s router-based liquidity model ensures decentralization and eliminates reliance on a single liquidity provider. However, Connext is primarily designed for Layer 2 scaling solutions and doesn’t yet support all Layer 1 blockchains. The network relies heavily on router liquidity. Insufficient liquidity can delay or increase the cost of transactions.

State Channels: Connext builds on state channels, a Layer 2 scalability solution that allows transactions to occur off-chain while retaining the security guarantees of the underlying blockchain. These channels minimize the number of on-chain interactions, reducing latency and gas costs.

Routers: Routers are liquidity providers in the Connext network. They facilitate cross-chain transactions by locking liquidity on one chain and unlocking it on the target chain. They earn fees for their service and must collateralize their positions to ensure security.

xCall: Connext’s xCall is a generic cross-chain communication primitive. It enables developers to build applications that pass messages or assets across chains without needing to handle complex bridging logic. This mechanism abstracts the bridging process for both developers and users, ensuring simplicity.

Nomad Integration: Connext uses Nomad’s optimistic roll-up model to verify and validate cross-chain interactions. This approach reduces trust assumptions and enhances security.

How Connext Works

Transaction Initiation:
- A user starts a cross-chain transaction using a Connext-integrated dApp or wallet.
- For example, a user wants to transfer tokens from Optimism (Layer 2) to Polygon (another Layer 2).
Liquidity Locking:
- The router locks the required liquidity on the source chain (Optimism) and forwards an off-chain message to the destination chain (Polygon).
Off-Chain Message Passing:
- Connext uses the xCall mechanism to relay the message securely and quickly across chains. The message includes transaction details, such as the asset amount and the recipient’s address.
Transaction Finalization:
- On the destination chain (Polygon), the router unlocks equivalent liquidity and sends it to the recipient’s wallet. This process is verified by the network, ensuring security and integrity.

Bridges and the Future of Digital Assets

Bridges will play a massive role in making digital assets more usable. Imagine a world where users don’t need to know which blockchain their assets reside on, they simply transact. For example:

Abstraction: The average user shouldn’t need to know technical details about bridging. A good decentralized bridge abstracts complexities like gas fees, token wrapping, and network selection. For instance, a user transferring stablecoins across chains shouldn’t need to worry about manually configuring gas tokens or selecting intermediary networks. All such intricacies should be handled in the background by the bridge’s architecture.
Enhanced UX: With smoother cross-chain swaps and wallet integrations, bridging becomes as simple as a single click. Wallets and dApps will incorporate intuitive interfaces that seamlessly execute bridging processes, allowing users to focus on their goals rather than the mechanisms.
Interoperability-Driven Applications: Applications will harness bridges to become truly chain-agnostic. For example, a DeFi app on Ethereum could directly interact with liquidity on Solana or Avalanche without requiring the user to know or manage the underlying mechanics.

This abstraction is key to mainstream adoption. Users care about outcomes, not mechanisms. By simplifying processes, bridges can drive the mass adoption of digital assets for everyday use cases, including payments

Security Concerns

Decentralized bridges, while offering a trustless alternative, are not without their challenges.

Smart Contract Vulnerabilities: Bugs or exploits in the smart contract code can lead to massive losses, as seen in various high-profile hacks.
- Mitigation: Conduct rigorous audits by reputable firms and incentivize white-hat hackers through bug bounty programs.
Sybil Attacks: Malicious actors can attempt to overwhelm the validator network by creating multiple fake identities.
- Mitigation: Implement robust mechanisms like Proof of Stake (PoS) or Proof of Authority (PoA) to ensure validators have a vested interest in the network’s security.
Cross-Chain Attack Surface: Bridging increases the potential attack vectors since multiple chains and protocols are involved.
- Mitigation: Use cryptographic techniques like zk-rollups and state proofs to secure interactions between chains.
Economic Incentive Exploits: Attackers might manipulate incentives to destabilize the bridge’s operations.
- Mitigation: Regularly review and optimize incentive structures to align with security goals.
Decentralized Governance Risks: Poorly designed governance mechanisms can lead to decision-making that compromises security.
- Mitigation: Ensure governance models are decentralized and resistant to collusion.

Decentralized bridges are set to transform the blockchain ecosystem. Bridges will evolve to provide near-instant, cost-effective transfers, making multi-chain interactions indistinguishable from single-chain experiences. The blockchain industry will likely adopt universal protocols and standards for cross-chain communication, similar to how the internet uses TCP/IP. Advanced cryptographic techniques like zk-proofs and multi-party computation (MPC) will make bridges more secure and scalable. As DeFi and traditional finance converge, bridges will play a crucial role in enabling cross-platform transactions involving both crypto and fiat assets. Projects like Polkadot and Cosmos might pave the way for blockchain ecosystems where bridging is natively integrated, reducing the need for standalone solutions. By abstracting complexities and ensuring security, bridges will drive the mainstream adoption of blockchain technology, empowering users to interact with decentralized applications effortlessly.

Decentralized bridges are not just a technological innovation, but a necessity for the future of web3. By addressing current challenges and pushing the boundaries of interoperability, they will enable a truly interconnected and user-friendly digital economy.

Token Sale Models

2025-01-03T00:00:00Z

Launching a crypto project comes with one big question: How do you sell your tokens? Token sales are the lifeblood of most blockchain projects, fueling development, building communities, and driving adoption. But picking the right sales model isn’t just about raising funds. It’s about fairness, accessibility, and strategy.

From simple “buy it now” pricing to dynamic auctions and even gamified lotteries, there’s a token sale model for every project. In this article, we’ll explore the most popular token sale mechanisms, breaking down how they work, their pros and cons, and even the math behind them. Whether you’re an investor curious about how tokens are distributed or a founder choosing the best method for your launch, this guide has you covered.

Let’s dive in and decode the world of token sale models!

Fixed Price Sale

You set a fixed price, and participants buy tokens at that price. It’s like buying groceries. Simple and predictable. Makes it easy for participants to calculate costs. Tokens are sold at a pre-determined price, and participants can purchase as many as they want within their limits. Many token offerings use this model. For instance, Filecoin’s presale was based on a fixed price.

$$Total Cost = Price Per Token × Number Of Tokens Purchased$$

The cost is directly proportional to the number of tokens purchased. If the price is constant (e.g., $1 per token), buying 10 tokens costs $10. So, if the token price is 0.01 ETH and you buy 100 tokens:

$$Total Cost=0.01×100=1 ETH$$

Here’s a smart contract snippet for a fixed price sale in Solidity:

uint256 public constant PRICE = 0.01 ether;
uint256 public constant MAX_TOKENS = 1000000;
uint256 public tokensSold;

function buyTokens(uint256 amount) public payable {
    require(msg.value == amount * PRICE, "Incorrect ETH amount");
    require(tokensSold + amount <= MAX_TOKENS, "Not enough tokens left");
    tokensSold += amount;
    // Transfer tokens to buyer
}

It’s a decent model except it can lead to oversubscription or under-subscription. The risk of unequal distribution.

Dutch Auction

The price starts high and gradually decreases until participants are willing to buy, or a reserve price is met. Think of it like a reverse eBay. Ethereum’s initial sale in 2015 used a Dutch auction, where early buyers paid a higher price. It encourages fair market price discovery and prevents “first-come-first-serve” unfairness.

$$PriceT =Start Price−(\tfrac{Start Price−End Price}{Duration} ×t)$$

The price starts high and decreases linearly over time. At any point t, the price depends on how much time has passed relative to the total auction duration.

So, if the Start Price was 1 ETH, end price = 0.1 ETH, duration = 10 hours. At t=5 hours:

$$Price=1−(\tfrac{1−0.1}{10} ×5)=0.55ETH$$

Here’s a solidity implementation of a Dutch auction:

uint256 public startTime = block.timestamp;
uint256 public startPrice = 1 ether;
uint256 public endPrice = 0.1 ether;
uint256 public duration = 7 days;

function getPrice() public view returns (uint256) {
    uint256 elapsedTime = block.timestamp - startTime;
    if (elapsedTime >= duration) return endPrice;
    return startPrice - ((startPrice - endPrice) * elapsedTime) / duration;
}

It does require participants to monitor prices closely can can be little complex for newcomers.

English Auction

Participants bid for tokens, with the highest bidder receiving them. Think of Sotheby’s, but for tokens. One of the most simple auction model. It ensures maximum revenue and the tokens fo to those valuing them the most. Polkadot’s DOT token sale used a modified English auction format.

$$Winning Bid=max(Bids)$$

So, if bids are 1 ETH, 1.5 ETH, and 2 ETH, the winning bid is:

$$max⁡(1,1.5,2)=2 ETH$$

Fairly straightforward to determine as well as implement:

struct Bid {
    address bidder;
    uint256 amount;
}

Bid[] public bids;

function placeBid() public payable {
    bids.push(Bid(msg.sender, msg.value));
}

function getHighestBid() public view returns (Bid memory) {
    Bid memory highest;
    for (uint256 i = 0; i < bids.length; i++) {
        if (bids[i].amount > highest.amount) {
            highest = bids[i];
        }
    }
    return highest;
}

Of course, it’s highly susceptible to bidding wars and might prove to be high barrier for small investors.

Lottery Sale

Participants enter a lottery, and winners are chosen to purchase tokens at a fixed price. It’s a bit like a raffle. The random allocation ensures fairness and prevents whales from dominating the sale. Binance Launchpad uses lottery-based sales for projects like WinkLink.

$$Probability Of Winning= \tfrac{Tickets Purchased By User}{Total Tickets} $$

The more tickets you hold, the higher your chances of winning, but it’s still random. So, if you buy 5 tickets in a pool of 100 tickets:

$$Probability=\tfrac{5}{100}=5%$$

We all understand basic concept of lottery, so this is also a fairly simple implementation:

address[] public participants;

function enterLottery() public {
    participants.push(msg.sender);
}

function pickWinner() public onlyOwner {
    uint256 winnerIndex = uint256(keccak256(abi.encodePacked(block.timestamp, block.difficulty))) % participants.length;
    address winner = participants[winnerIndex];
    // Allocate tokens to winner
}

Although, in this case, some participants might feel excluded and there’s no guarantee of allocation.

First-Come-First-Serve (FCFS)

Tokens are allocated to participants in the order of their purchases until the supply is exhausted. Think of Black Friday deals. Simple to implement and understand. Motivates early participation which is huge positive for new projects. The ICO of Brave (BAT) saw early participants snapping up tokens in seconds.

$$Tokens Allocated=min(Tokens Requested,Tokens Available)$$

You can only buy as many tokens as are left when it’s your turn. Early participants get the most tokens. So, if 1,000 tokens are available and a participant requests 500 tokens:

$$Tokens Allocated=min(500,1000)=500$$

function buyTokens() public payable {
    require(tokensSold < MAX_TOKENS, "Sold out");
    tokensSold++;
    // Transfer tokens
}

However, this might create server overload or congestion. May disadvantage slower participants or participants with slower validators or network coverage.

Bonding Curve

The price of tokens increases dynamically based on demand, typically governed by a mathematical curve. t’s like buying concert tickets. The more demand, the higher the price. Uniswap’s liquidity pools use bonding curves to set token prices dynamically. It incentivises early participation and ensures continuous price discovery. (My personal favourite too if implemented properly.)

$$Price=Base Price+k×Supply^n$$

Where:

k is a scaling factor,
n determines the curve’s steepness,
Supply is the number of tokens sold so far.

As more tokens are sold, the price increases exponentially or quadratically. Let’s say for Base price = 0.01 ETH, k=0.001, n=2, and 100 tokens sold:

$$Price=0.01+0.001×100^2=1.01 ETH$$

function getPrice(uint256 supply) public pure returns (uint256) {
    return BASE_PRICE + (supply ** 2) / CURVE_FACTOR;
}

Although there’s quite a strong foundation, It might get complex for users to understand. The early adopters may gain disproportionate advantages as well, which arguably is justified to an extent.

Tiered Sale

Tokens are sold in phases, with each tier having different prices and conditions. It encourages early participation by offering discounts and has a predictable structure. Polkastarter often runs tiered sales where early buyers get discounts.

Different tiers have fixed prices. The tier you’re in determines the price you pay. So, if Tier 1 price is 0.01 ETH and Tier 2 price is 0.02 ETH, buying during Tier 1 costs:

$$Price=0.01×Tokens Purchased$$

uint256[] public tiers = [0.01 ether, 0.02 ether, 0.03 ether];
uint256 public currentTier;

function buyTokens() public payable {
    require(msg.value == tiers[currentTier], "Incorrect price");
    currentTier++;
    // Transfer tokens
}

Simple model. While later participants may feel penalized, the early tiers can be dominated by whales.

Batch Auction

All bids are collected in a batch, and the clearing price is determined to allocate tokens to participants proportionally. Gnosis Protocol uses batch auctions for price discovery.

$$Clearing Price = \tfrac{Total Funds Committed}{Total Tokens Available}$$

All bids are pooled together. The clearing price is determined by dividing the total funds by the tokens available. If 10 ETH is committed for 1,000 tokens:

$$Clearing Price=\tfrac{10}{1000}=0.01 ETH$$

uint256 public clearingPrice;

function finalizeAuction() public onlyOwner {
    // Calculate clearing price based on bids
    clearingPrice = calculateClearingPrice();
}

Apart from the above, there have been Hybrid Models as well which combine one or more of the above models for various factors from fairness, revenue generation, simplying terms, higher market penetration and so on.

Choosing the right token sale model is a mix of strategy, technical feasibility, and audience understanding. By aligning your model with your goals, tokenomics, and market conditions, you can ensure a successful launch that sets your Web3 project up for long-term growth.

Synthetic Asset Tokens

2024-12-20T00:00:00Z

Imagine having access to the value of an asset, say, Tesla stock, without ever owning it. That’s essentially what synthetic asset tokens (or just “synthetics”) do. These are blockchain-based tokens that mimic the value of real-world assets, such as stocks, commodities, or even fiat currencies. Think of them as financial doppelgängers: they look, act, and feel like the original, but they exist entirely in the digital realm.

In the traditional financial market, synthetic assets are not new. Derivatives like futures and options have been around for decades, allowing traders to bet on the price of an asset without ever owning it. Synthetic tokens simply bring this concept to the blockchain, leveraging smart contracts to handle everything transparently and automatically.

Derivatives exist in web3 as well already. However, there’s still lot of scepticism around it. Derivatives like futures, options, and perpetual swaps already exist and are widely used. Both derivatives and synthetic tokens are tied to an underlying asset, such as Bitcoin, Ethereum, or traditional stocks like Tesla. The performance of these assets directly affects the value of the derivative or synthetic token. Just as derivatives allow traders to speculate or hedge risks, synthetic asset tokens let users gain exposure to the price of assets without actually owning them.

Crypto derivatives have gained significant traction, especially in speculative trading. Futures and perpetual swaps on exchanges like Binance, Bybit, and dYdX dominate trading volumes. They offer high liquidity and enable speculation on crypto prices. Traders and institutions use derivatives to manage risk, especially in highly volatile markets. Many jurisdictions have banned or restricted derivatives trading due to concerns over high leverage and investor risk (e.g., Binance halting derivatives in several countries). The extreme price swings in crypto make derivatives riskier than their traditional counterparts, leading to liquidations for unprepared traders.

Traditional finance views synthetics as tools for hedging and speculation. Want to protect yourself from the wild price swings of oil without owning physical barrels? A synthetic derivative could be your best friend. Similarly, traders use them to speculate on price movements, essentially making money out of thin air, if they play their cards right.

In the tokenized asset market, synthetic tokens serve a similar purpose, but with a blockchain twist. They’re used for:

Global Accessibility: You don’t need a brokerage account to own a synthetic version of Apple stock. Just a crypto wallet will do.
Fractional Ownership: Want exposure to gold but can’t afford a whole ounce? Synthetic tokens can be fractioned down to tiny denominations.
Decentralized Finance (DeFi): Platforms like Synthetix allow users to mint synthetic tokens using their crypto as collateral.

Like any financial innovation, synthetic asset tokens come with their own set of advantages and challenges.

Pros

Accessibility: Traditional markets often have barriers, like location, regulations, or account requirements. Synthetic tokens tear those walls down.
Efficiency: Transactions happen on the blockchain, which means they’re often faster and cheaper than traditional methods.
Liquidity Boost: Synthetic tokens can unlock liquidity by bringing otherwise illiquid assets into a tradable, digital format.

Cons

Complexity: They’re not beginner-friendly. Understanding how synthetics work requires some financial and blockchain literacy.
Regulation: Governments haven’t fully figured out how to regulate synthetic tokens, which could lead to legal uncertainties. Hell, some governements are yet to figure to crypto itself.
Counterparty Risk: In DeFi, your synthetics depend on smart contracts and oracles. If something goes wrong there, your assets could be at risk.

Here’s where things get exciting. Synthetic asset tokens can significantly improve liquidity in the crypto and NFT markets by unlocking idle assets, diversification and bridging markets. Imagine converting an NFT, typically illiquid, into a synthetic token that can be freely traded. This opens up an entirely new avenue for liquidity in the NFT space. Traders could gain exposure to other markets (stocks, gold, real estate) without leaving the crypto ecosystem. Synthetic tokens could serve as a bridge between traditional and crypto markets. For example, a synthetic token pegged to the S&P 500 index could attract traditional investors into the blockchain world.
In essence, synthetics have the potential to make markets more fluid, more inclusive, and more interconnected.

A few platforms and projects are already leveraging synthetic asset tokens:

Synthetix: Synthetix is one of the leading platforms for synthetic assets. It allows users to mint Synths tokens representing real-world assets like sUSD (synthetic USD), sBTC (synthetic Bitcoin), and even synthetic stocks. Synthetix uses Chainlink oracles to ensure accurate pricing.
Mirror Protocol: Built on Terra, Mirror Protocol enabled synthetic versions of stocks like mAAPL (synthetic Apple stock) and mGOOGL (synthetic Google stock). It gained popularity for allowing users outside the U.S. to trade synthetic U.S. stocks. However, Terra’s collapse affected its adoption.
NFTy (👀): Imagine a platform where synthetic tokens represent a basket of the top 500 NFT collections. It creates a new layer of liquidity and market exposure for NFT enthusiasts.

Let’s skip to look into code for a bit.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SyntheticAssetToken {
    string public name = "SyntheticAssetToken";
    string public symbol = "SAT";
    uint8 public decimals = 18;
    uint256 public totalSupply;

    mapping(address => uint256) public balanceOf;
    mapping(address => mapping(address => uint256)) public allowance;

    uint256 public collateralRatio = 200; // 200% collateral required
    uint256 public collateralLocked;

    mapping(address => uint256) public collateral;

    address public owner;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can perform this action");
        _;
    }

    // Events
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
    event Mint(address indexed user, uint256 amount, uint256 collateral);
    event Burn(address indexed user, uint256 amount, uint256 collateralReturned);

    // Transfer tokens
    function transfer(address to, uint256 value) public returns (bool) {
        require(balanceOf[msg.sender] >= value, "Insufficient balance");
        balanceOf[msg.sender] -= value;
        balanceOf[to] += value;
        emit Transfer(msg.sender, to, value);
        return true;
    }

    // Approve an allowance for another address
    function approve(address spender, uint256 value) public returns (bool) {
        allowance[msg.sender][spender] = value;
        emit Approval(msg.sender, spender, value);
        return true;
    }

    // Transfer tokens on behalf of another address
    function transferFrom(address from, address to, uint256 value) public returns (bool) {
        require(balanceOf[from] >= value, "Insufficient balance");
        require(allowance[from][msg.sender] >= value, "Allowance exceeded");
        balanceOf[from] -= value;
        balanceOf[to] += value;
        allowance[from][msg.sender] -= value;
        emit Transfer(from, to, value);
        return true;
    }

    // Mint synthetic tokens by locking ETH as collateral
    function mint(uint256 amount) public payable {
        uint256 requiredCollateral = (amount * collateralRatio) / 100;
        require(msg.value >= requiredCollateral, "Insufficient collateral");

        collateral[msg.sender] += msg.value;
        balanceOf[msg.sender] += amount;
        totalSupply += amount;
        collateralLocked += msg.value;

        emit Mint(msg.sender, amount, msg.value);
    }

    // Burn synthetic tokens and withdraw collateral
    function burn(uint256 amount) public {
        require(balanceOf[msg.sender] >= amount, "Insufficient token balance");

        uint256 collateralToReturn = (amount * collateralRatio) / 100;
        require(collateral[msg.sender] >= collateralToReturn, "Insufficient collateral locked");

        balanceOf[msg.sender] -= amount;
        totalSupply -= amount;
        collateral[msg.sender] -= collateralToReturn;
        collateralLocked -= collateralToReturn;

        payable(msg.sender).transfer(collateralToReturn);

        emit Burn(msg.sender, amount, collateralToReturn);
    }

    // Fallback function to handle ETH sent directly to the contract
    fallback() external payable {}

    receive() external payable {}
}

Users lock ETH as collateral, and the contract mints synthetic tokens (SAT) for them. The required collateral is 200% of the token’s value (adjustable by modifying collateralRatio). Users can burn their synthetic tokens to reclaim the collateral they locked. The contract also supports ERC-20 functions like transfer, approve, and transferFrom.

Please note that this smart contract is for understanding need only and not to be used in real production use-case. It needs to have further price oracles, liquidation and governance models included for that, not to mention security.

As exciting as synthetic asset tokens are, they come with significant security concerns. Since these tokens are entirely reliant on blockchain technology and smart contracts, their safety depends on the robustness of the underlying code and ecosystem.

Smart Contract Vulnerabilities

Smart contracts are immutable once deployed, meaning any bug in the code can be catastrophic. Hackers can exploit vulnerabilities to drain collateral, mint unauthorized tokens, or manipulate token behavior.

Example: The 2020 bZx protocol exploit resulted in losses of millions due to flaws in its smart contract logic.

Price Oracle Manipulation

Synthetic tokens rely on price oracles to mirror the value of real-world assets. If an oracle is compromised or manipulated, the synthetic token’s value could diverge drastically, leading to losses for users.

Example: In 2022, several DeFi platforms experienced oracle attacks where attackers manipulated prices to profit from undercollateralized positions.

Collateral Risks

Synthetic tokens require collateral backing to maintain trust and stability. If collateral values drop suddenly (e.g., during a market crash), the synthetic asset system could become undercollateralized, leading to insolvency and loss of funds.

Rug Pulls and Governance Exploits

In decentralized systems, malicious actors could take over governance (via token voting) and implement changes that siphon funds or destroy the ecosystem.

Regulatory Compliance Risks

Since synthetic tokens mimic traditional assets, they often blur the line between DeFi and traditional finance. Regulatory bodies like the SEC in the U.S. or the RBI in India could impose restrictions or fines on platforms operating without compliance.

Governance is essential to ensure the stability, transparency, and adaptability of synthetic asset platforms. Without proper governance, these systems can devolve into chaos, whether through technical issues, regulatory non-compliance, or community mismanagement.

Updating Parameters: Adjusting collateral ratios, fees, and system rules in response to market conditions.
Security Audits: Funding regular audits to identify and patch vulnerabilities.
Price Oracle Management: Ensuring that oracles used for price feeds are reliable, decentralized, and tamper-proof.
Emergency Response: Providing mechanisms to pause or roll back operations during unexpected attacks or exploits.
Regulatory Compliance: Proactively adapting to legal requirements, such as Know Your Customer (KYC) and Anti-Money Laundering (AML) measures.

We can infact learn a lot from traditional financial governance as they’ve gone through similar states involving synthetic assets or derivatives.

SEC’s Role: In traditional finance, the U.S. SEC (Securities and Exchange Commission) enforces regulations that protect investors, ensure market fairness, and penalize fraud. Synthetic token platforms could learn from the SEC’s stringent oversight of derivatives and securities markets to build trust.
RBI’s Approach: The Reserve Bank of India oversees monetary policy and ensures that banks maintain sufficient reserves. Similarly, synthetic token platforms need to enforce collateralization rules to prevent insolvency.

Many synthetic token projects already implement decentralized governance models, where token holders vote on key decisions. However, these systems need to balance decentralization with expertise; relying solely on token holders without checks can lead to uninformed or malicious decisions.

In decentralized synthetic asset markets, reputation will be a key differentiator. Fund managers with strong track records will likely attract more users, liquidity providers, and partnerships. However, reputation isn’t just a personal asset; it elevates the entire market by fostering trust and reducing skepticism about decentralized finance.

As the synthetic asset ecosystem grows, we will be introducing decentralized reputation scoring systems in NFTy, think “on-chain LinkedIn for fund managers”. Reputation could become a tradable asset in itself, shaping the future of decentralized markets just as much as the assets being tokenized. We can cover more on building reputation later.

Synthetic asset tokens are still in their early days, and the use cases we’re seeing are just the tip of the iceberg. What could the future hold?

Tokenized Real Estate: Imagine investing in synthetic tokens representing global real estate markets, all from your phone.
Synthetic ESG Assets: Tokens tied to sustainability indices or carbon credits could attract socially conscious investors.
Custom Market Creation: Want a token that tracks the value of “most streamed artists on Spotify”? With synthetics, you can create it.

What we can say for sure is that Synthetic asset tokens are more than just a trend. They’re a fundamental shift in how we think about ownership, liquidity, and financial accessibility. The big question isn’t just what can we do with synthetics now? but rather what haven’t we thought of them yet?

How does Chain Abstraction work?

2024-12-17T00:00:00Z

If you’re looking to learn about the basics about Chain Abstraction, then read this article instead.

Technically speaking, chain abstraction means abstracting away the differences between blockchain networks to provide a seamless experience. The goal is to:

Simplify User Interaction: Make it easy for users to interact with apps without worrying about which chain they’re on.
Enable Interoperability: Allow assets, data, and actions to move freely between chains.
Reduce Complexity for Developers: Provide unified tools and APIs to build cross-chain applications.

To achieve chain abstraction, several tools and mechanisms come into play.

Cross-Chain Bridges

Bridges connect different blockchains, enabling the transfer of assets and data between them. Think of them as digital highways. For example, if you want to move your tokens from Ethereum to Binance Smart Chain, a bridge handles the heavy lifting.

You lock your tokens on the source chain (e.g., Ethereum).
The bridge mints an equivalent amount of tokens on the destination chain (e.g., Binance Smart Chain).
When you want to reverse the process, the tokens on the destination chain are burned, and the original tokens are unlocked.

Swaps and Liquidity Protocols

Swapping tokens across chains often requires decentralized exchanges (DEXs) or protocols like Uniswap and SushiSwap. Some advanced protocols like Thorchain take it a step further by supporting native cross-chain swaps without wrapping tokens.

Liquidity pools on different chains allow you to trade one token for another.
Cross-chain swap protocols use bridges under the hood to move assets while maintaining a smooth experience.

Interoperability Protocols

Protocols like Polkadot and Cosmos focus on making blockchains inherently interoperable. They create ecosystems where chains can share data and assets natively.

Relay Chains: Central hubs that coordinate communication between connected blockchains.
IBC (Inter-Blockchain Communication): A protocol standard used in Cosmos to let chains talk to each other securely. All contracts follow the Interchain Standards (ICS) for the Cosmos network & interchain ecosystem.

Universal Wallets

Tools like Particle Network enable universal account wallets that work across multiple chains. Instead of manually switching between networks, these wallets auto-detect and handle transactions on the right chain.

Chain detection and configuration happen automatically.
Transactions are routed to the correct blockchain without user intervention.

RPC Aggregators

Remote Procedure Call (RPC) endpoints are gateways to blockchains. Aggregators like Alchemy and Infura provide a unified interface to interact with multiple blockchains, abstracting away the need to set up individual endpoints.

Chain abstraction is the backbone of many user-friendly crypto applications. Lets see a few examples:

Imagine you’re using a decentralized finance app to swap Ethereum (ETH) for Binance Coin (BNB). Here’s what it looks like from your perspective:

You open the app and select ETH as the token to swap.
You choose BNB as the token to receive.
You click “Swap” and confirm the transaction.

From your perspective, it’s a one-click process. Behind the scenes, multiple tools work together to make it seamless.

The app detects that ETH is on Ethereum and BNB is on Binance Smart Chain.
A cross-chain bridge locks your ETH on Ethereum and creates a wrapped version on Binance Smart Chain.
The app uses a liquidity pool to exchange the wrapped ETH for BNB.
Finally, the app transfers BNB to your wallet on Binance Smart Chain.

Here’s a simple Solidity contract for locking tokens on Ethereum and emitting an event to notify a bridge:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract TokenLock {
    event TokenLocked(address indexed user, uint256 amount, string destinationChain);

    mapping(address => uint256) public lockedBalances;

    function lockTokens(uint256 amount, string memory destinationChain) external {
        require(amount > 0, "Amount must be greater than 0");

        // Simulate token lock (e.g., ERC20 transfer to contract)
        lockedBalances[msg.sender] += amount;

        // Emit event for bridge to pick up
        emit TokenLocked(msg.sender, amount, destinationChain);
    }
}

This contract locks tokens on Ethereum and emits an event. A bridge service listens to the event and handles minting on the destination chain.

Lets take another example. Imagine you own an NFT on Ethereum but want to sell it on a Solana-based marketplace. Chain abstraction allows this by bridging the NFT to Solana while ensuring its metadata and ownership history remain intact.

The NFT is locked on Ethereum, and a wrapped version is created on Solana.
The marketplace interacts with the Solana version, displaying it as if it were native to Solana.
When the NFT is sold, the buyer can choose to keep it on Solana or transfer it back to Ethereum.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/IERC721.sol";

contract NFTBridge {
    event NFTLocked(address indexed user, uint256 tokenId, string destinationChain);

    IERC721 public nftContract;

    constructor(address _nftContract) {
        nftContract = IERC721(_nftContract);
    }

    function lockNFT(uint256 tokenId, string memory destinationChain) external {
        require(nftContract.ownerOf(tokenId) == msg.sender, "Not the owner");

        // Transfer the NFT to the bridge contract
        nftContract.transferFrom(msg.sender, address(this), tokenId);

        // Emit event for bridge service
        emit NFTLocked(msg.sender, tokenId, destinationChain);
    }
}

In this example, the contract locks an NFT and emits an event. The bridge then handles minting the wrapped NFT on the target chain.

How about EVM to Cosmos perhaps?

Here’s an example illustrating how a smart contract on Ethereum can interact with a Cosmos chain using IBC:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract EVMToCosmosBridge {
    event TokenSentToCosmos(address indexed sender, uint256 amount, string cosmosAddress);

    mapping(address => uint256) public balances;

    function sendToCosmos(uint256 amount, string memory cosmosAddress) external {
        require(amount > 0, "Amount must be greater than 0");

        // Simulate token lock (e.g., ERC20 transfer to contract)
        balances[msg.sender] += amount;

        // Emit event for Cosmos chain to pick up
        emit TokenSentToCosmos(msg.sender, amount, cosmosAddress);
    }
}

This contract locks tokens on Ethereum and emits an event for an IBC-compatible relayer to transfer the equivalent tokens to a Cosmos chain.

On the Cosmos side, a module listens for IBC events and handles incoming tokens:

package tokenbridge

import (
    "github.com/cosmos/cosmos-sdk/types"
    "github.com/cosmos/ibc-go/modules/core/04-channel/types"
)

func HandleTokenTransfer(ctx sdk.Context, msg types.MsgRecvPacket) error {
    // Decode the packet
    var data TokenTransferPacketData
    if err := json.Unmarshal(msg.Packet.Data, &data); err != nil {
        return err
    }

    // Mint the tokens for the recipient
    recipient := sdk.AccAddress(data.Recipient)
    amount := sdk.NewCoin(data.Denom, sdk.NewInt(data.Amount))

    if err := MintTokens(ctx, recipient, amount); err != nil {
        return err
    }

    return nil
}

func MintTokens(ctx sdk.Context, recipient sdk.AccAddress, amount sdk.Coin) error {
    // Use the bank module to mint and send tokens
    bankKeeper := GetBankKeeper()
    return bankKeeper.MintCoins(ctx, ModuleName, sdk.NewCoins(amount))
}

This Cosmos module listens for incoming IBC packets, decodes the token transfer details, and mints tokens to the recipient’s address. It complements the Ethereum-side contract to complete the abstraction.

Now, since blockchains are inherently siloed networks, they ideally wouldn’t know to even listen each other. That’s where the bridges and other tools come in. Even with bridges, potential limitations still exists. If the cross-chain bridge experiences congestion, your transaction might be delayed. Additionally, if there’s insufficient liquidity in the liquidity pool for the target token, you might get unfavorable rates or the swap could fail entirely. Lastly, any issues with the smart contracts underlying the bridge or pool could result in transaction errors or delays.
Despite these risks, robust protocols and fallback mechanisms are constantly evolving to mitigate such problems. Scalability can also become a bottleneck as the number of connected chains increases, requiring more resources to maintain performance. Security is another concern, as cross-chain communication introduces additional attack surfaces, such as vulnerabilities in the relay chains or the Inter-Blockchain Communication (IBC) protocol. Addressing these issues is critical for achieving robust and secure interoperability.

There’s a long way to go to achieve true chain abstraction, but we’re on the way already…

Manga, Manhua and Manhwa

2024-12-15T00:00:00Z

If you’ve ever stumbled into the world of Asian graphic novels, you’ve probably come across the big three: Manga (Japanese graphic novels), Manhua (Chinese graphic novels), and Manhwa (Korean graphic novels). At first glance, they might all look like stylish black-and-white panels filled with expressive characters. But look closer, and you’ll find a rich tapestry of differences woven from their unique cultural, historical, and creative roots. So, let’s dive in and explore these fantastic worlds, no passport required!
Don’t kill me for the word “comics”. Its just a reference to make it easier to understand comparing with western graphic novels.

Manga: The OG (Original Graphic) of Asian Comics

Manga is Japan’s pride and joy, with roots tracing back to ukiyo-e woodblock prints from the Edo period (1603–1867). But modern manga as we know it exploded post-WWII, thanks to Osamu Tezuka’s “Astro Boy.” Tezuka’s cinematic style was revolutionary, and his work set the stage for manga’s global domination.

Format: Usually black-and-white and printed in small booklets or magazines like Shonen Jump.

Direction: Right to left. Yes, it’s the ultimate “read me backward” experience.

Art Style: Highly detailed characters with larger-than-life emotions (those teary, sparkling eyes are iconic).

From Naruto kicking butt in ninja villages to Death Note making us question our moral compasses, manga has something for everyone. There are genres for boys (shonen), girls (shoujo), adults (seinen), and beyond.

Manga is thriving globally. Platforms like MangaPlus bring serialized chapters to international fans, and anime adaptations only amplify the craze (Demon Slayer, anyone?). It’s not just entertainment, it’s an economic powerhouse in Japan. Shonen Jump, one of the most iconic and influential manga magazines in the world, published by the Japanese company Shueisha made manga culture appeal far-reaching, captivating readers of all ages and genders with its diverse roster of stories. A lot of popular manga like Dragon Ball, Naruto, One Piece, and Demon Slayer, Jujutsu Kaisen, Bleach and many more all got their start in this magazine.

If you’re getting started, here’s my top recommendations:

Dragon Ball Z : The OG power-up and fight series that defined a generation.
One Piece : Pirates, treasures, and a stretchy hero. What’s not to love?
Naruto : The journey of a knucklehead ninja with dreams of becoming Hokage.
Attack on Titan : Giant man-eating creatures? A dystopian masterpiece.
Death Note : A notebook that kills? Cue moral dilemmas and epic mind games.
Fullmetal Alchemist : Alchemy, brotherly bonds, and an unforgettable story.
Demon Slayer (Kimetsu no Yaiba) : Demon hunting with a side of breathtaking animation.
Bleach : Soul Reaper stuck in human world and epic journey begins
Jujutsu Kaisen : Curses, exorcists, and a protagonist who eats a finger. Wild ride.
Vinland Saga : Vikings and real history woven into an epic story.
Tokyo Revengers : Time travel, gangs, and redemption arcs galore.
Hunter x Hunter : Adventure packed story of a world opening into larger world.
Parasyte : Alien parasites take over humans

There’s plenty more but these would be good starting points.

Manhua: The Chinese Renaissance of Comics

Manhua dates back to 19th-century satirical drawings. While early manhua was mostly based around political settings, it evolved into a vibrant storytelling medium by the 20th century. Thanks to the internet boom, digital manhua exploded in popularity.

Format: Often in vibrant full color, breaking away from manga’s monochromatic traditions.

Direction: Left to right, like most Western comics. (Your brain thanks you.)

Art Style: Slick, sharp lines and ethereal vibes, especially in cultivation (think martial arts meets fantasy) genres.

Manhua loves epic fantasy (cultivation tales like “Tales of Demons and Gods”), historical romance, and revenge-driven dramas. There’s often a philosophical touch, reflecting Confucian values or Taoist mysticism.

China’s strict censorship laws have shaped manhua’s themes, keeping them relatively tame. However, platforms like Tencent Comics, Bilibili Comics and Kuaikan Manhua are pushing them to global audiences. The industry still struggles to match manga’s global reach, but it’s making steady strides.

If you’re getting started, here’s my top recommendations:

Tales of Demons and Gods : Cultivation fantasy with a reincarnated protagonist aiming to change fate.
The King’s Avatar : E-sports meets a gaming prodigy’s rise to glory.
Soul Land (Douluo Dalu) : Martial arts and magical beast fusion battles.
Apotheosis : A journey from a slave to a god epic cultivation vibes.
Martial Peak : An endless quest for strength in a martial arts universe.
Battle Through the Heavens : Alchemy, martial arts, and the ultimate underdog story.
Versatile Mage : A magic school story with a rebellious protagonist who defies norms.
Star Martial God Technique : A quest to master the universe’s strongest martial arts technique.
The Ravages of Time : Historical epic inspired by China’s Three Kingdoms period.
God of Martial Arts : A world where martial arts determine life, death, and destiny.
Ultimate of All Ages : Man from the ancient past, who awakens in a world thousands of years into the future.

My friend Sreeram maintains this list that you can also follow for more recommendations.

Manhwa: The Webtoon Revolution

Manhwa blossomed in Korea post-WWII but faced setbacks during the country’s political turmoil. By the 2000s, digital manhwa (aka webtoons) redefined the game. Korean creators took advantage of smartphones, creating vertical-scrolling comics designed for seamless online reading.

Format: Full-color, vertical scrolling, perfect for phone addicts (guilty!).

Direction: Left to right.

Art Style: Clean, modern, and often cinematic, with dynamic paneling.

Manhwa is fearless when it comes to tackling adult themes (hello, “Solo Leveling” and “Lore Olympus”). From heartwarming romances (“True Beauty”) to action-packed epics (“Tower of God”), manhwa often blends K-drama vibes with stunning visuals.

Manhwa is leading the digital comics world, and platforms like LINE Webtoon, Lezhin Comics, Toomics and KakaoPage are expanding its global footprint. Thanks to Netflix adaptations (Sweet Home, Hellbound), manhwa is practically a household name now.

If you’re getting started, here’s my top recommendations:

Solo Leveling : From weakling to world’s strongest hunter, an action-packed journey.
Tower of God : A mysterious tower, tests of strength, and betrayal at every turn.
Omniscient Reader’s Viewpoint : Imagine waking up in your favorite web novel’s apocalyptic world.
The Beginning After the End : A king reincarnated into world of magic
True Beauty : A heartwarming story of self-esteem and romance with K-drama adaptation in 2020.
The Breaker : Martial arts battles with a secretive and charismatic mentor.
Noblesse : A vampire awakening in modern society, epic fights and humor included.
The God of High School : A high school martial arts competition takes crazy turn.
Sweet Home : Survival horror with a psychological twist. Monsters, everywhere.
Bastard : Thriller meets psychological horror with a chilling father-son dynamic.
Nano Machine : Nano machines from future makes kid rise up in Demonic Cult and path to the strongest. Also has other manhwa in same universe like Absolute Sword Sense.
The Gamer : High-school student with special powers make real world feel like gaming.
Academy’s Underground Professor : Former Assassin becomes professor and becomes entangled in the academy’s hidden secrets, political conspiracies, and mysterious powers.

I’m slightly partial to action packed series but there’s plenty of popular titles in various genres available as well.

What Sets Them Apart?

Aspect	Manga	Manhua	Manhwa
Origin	Japan	China	Korea
Reading Direction	Right to left	Left to right	Left to right
Art Style	Black-and-white, detailed	Full-color, sleek	Full-color, cinematic
Format	Serialized in magazines	Digital or print	Digital (vertical)
Global Reach	Widely known	Growing steadily	Exploding internationally

Manga, manhua, and manhwa may share DNA, but they’ve evolved into distinct art forms with unique flavors. Manga feels like a trusted old friend, manhua like a mystical storyteller, and manhwa like your tech-savvy, trendsetting sibling.

Apart from these, there are some one-shots which comes up such as my fav donghua web series Link Click. So many art forms out there telling amazing stories. :)

Don’t be hating in any of them. Love and enjoy each 😉 story and their unique experience.

💙

Chain Abstraction

2024-12-09T00:00:00Z

Say you want to make an online payment, and instead of just clicking a button, you have to figure out whether the store accepts Visa, Mastercard, or PayPal. Now multiply that headache by 100x, and you’ve got the current state of blockchains. This is where chain abstraction steps in — the fintech equivalent of a universal payment processor but for blockchains. It makes the Web3 world less about mind-numbing details and more about getting stuff done.

Let’s dive into what chain abstraction is, why it’s the hero we need, and how you can build cool things around it.

What Is Chain Abstraction Anyway?

Imagine using Venmo, Apple Pay, or Google Pay without worrying about how they talk to your bank or credit card. That’s chain abstraction for blockchains. It’s all about hiding the complex, nerdy stuff like gas fees, token standards, and wallet types so users and developers can focus on what matters: buying that damn mocha.

It makes interacting with blockchains feel less like coding in the Matrix and more like using Spotify. In short, it’s the magic trick that lets blockchains talk to each other and work together seamlessly.

Why Do We Even Need This?

Blockchains are amazing, but let’s be real: they’re a pain to use. Each chain has its quirks, its rules, and its own language. For instance:

Ethereum makes you worry about gas fees.
Solana dazzles you with speed but has its own wallet ecosystem.
Binance Smart Chain screams, “Hey, we’re cheap!” but you still have to bridge assets manually.

Imagine if every payment app required you to know the bank’s internal workings. You’d delete them in a heartbeat. That’s why we need chain abstraction to fix these headaches:

Simplified User Experience
You don’t care which blockchain an app is on. You just want to use it without Googling, “How to send tokens from Polygon to Arbitrum.”

More Collaboration, Less Competition
Developers can focus on innovation instead of building the same tools for every blockchain.

Onboarding for the Masses
Your grandma won’t care about gas fees or token bridges, but she might use Web3 if it’s as easy as buying something on Amazon.

Think of chain abstraction as turning a messy fintech system into a unified, user-friendly experience:

No More Wallet Chaos: Whether it’s MetaMask, Phantom, or Keplr, users can use one interface to access all their assets.
Universal Gas Fees: Users pay with whatever tokens they have, instead of scrambling to swap for ETH, SOL, or MATIC.
Cross-Chain Transactions Made Easy: Think of it as a blockchain version of Wise for international transfers, but instant and decentralized.

Several blockchain superheroes are already working on this:

LayerZero: The omnichain messaging protocol. Think WhatsApp but for blockchains.

Cosmos (IBC): The OG of chain abstraction, letting blockchains chat like old friends.

Axelar Network: Focused on secure cross-chain communication. Think of it as a blockchain VPN.

Polkadot: Parachains make interoperability look easy, kinda like how Apple devices magically sync.

Superfluid: Abstracts token standards for seamless asset streaming across different chains.

How Does It Work?

Chain abstraction operates like the middleware in your favorite fintech app.

Middleware Layers: Like Stripe for payments, middleware abstracts the complexity of multi-chain interactions.
Universal Wallets: These wallets hide the “What chain are you on?” question.
Gas Fee Abstraction: Imagine paying transaction fees in whatever token you like. No more “insufficient ETH” pop-ups.

So, How to Build on Chain Abstraction

If you’re a builder looking to jump in, here’s your cheat sheet:

Understand the Ecosystem

Spend time with protocols like LayerZero, Cosmos, and Axelar. They’re like the Lego sets for chain abstraction.

Keep Security in Mind

Cross-chain means more doors to lock. Study cryptographic techniques and get comfy with audits.

Use Dev-Friendly Tools

Tools like Axelar SDK or Ethereum’s EIP-4337 are your best friends. Don’t reinvent the wheel.

Think Like a Fintech Startup

Build for scalability and usability. If your app isn’t grandma-friendly, try again.

Some Cool Ideas to Build

Here are some project ideas to flex your developer muscles:

Cross-Chain DeFi Superapp
Think Revolut, but for DeFi. Let users swap, lend, and stake across chains in one interface.
Gasless Transactions dApp
Let users pay fees in their favorite token or abstract gas fees entirely.
Blockchain Expedia
Aggregate dApps across chains so users can search for services like booking flights or investing, without worrying about chains.

Chain abstraction is like the UPI (Unified Payments Interface) of the blockchain world. It’s making blockchains talk to each other, play well together, and be user-friendly for everyone. If Web3 is ever going to rival fintech giants like PayPal or Stripe, this is the way forward.

Developers, this is your moment. Start building tools that make blockchains boring in the best way where the tech just works, and users don’t even notice the chains under the hood. At DripVerse, this is going to be the next frontier to build on. Keep an eye out folks…

Chaos Theory

2024-11-26T00:00:00Z

Let’s talk about chaos. Not the “forgot your wallet, keys, and phone” kind of chaos, but the deep, philosophical, scientific kind. The one that makes you question if the flutter of a butterfly’s wings in Bengaluru could really spark a thunderstorm in New York. Chaos theory is basically the science of surprise. Predicting the unpredictable. It’s like trying to organize your desktop files: no matter how much effort you put in, something random (or seemingly random) will inevitably throw everything out of whack. Just like that stupid .DS_Store and you keep having to add to your .gitignore.

At its core, chaos theory studies systems that are highly sensitive to initial conditions. Commonly known as “butterfly effect”. In short, small things can have big consequences. Kind of like sending a “k” in response to someone’s long emotional text. Of course, it might not be intentional. Perhaps you were occupied, driving or otherwise engaged mentally, and the logical part of your brain said to send an acknowledgement to their effort. You didn’t even mean to reply and yet you hurt the person who put an ample amount of time in sharing their deepest desires.

Living in Bengaluru itself sometimes feels like total chaos. You might start with a sunny morning and end with a cyclone, all because a few atoms of air decided to take a different route. It’s a system so complex that even supercomputers give up halfway and ask for a coffee break. (Hopefully, its decaf.)

But here’s the twist: chaos doesn’t mean total randomness. It’s like a toddler on a sugar high. Erratic, yes, but following its own strange logic. Chaos theory finds patterns in the madness, revealing that seemingly random events often have an underlying order. Some of us tend to understand it on a level unexplained by science. Call it intuition, gut feeling, experience or sixth sense. Spidy sense if you’re spiderman.

You encounter chaos every day, whether you realize it or not. Ever tried cooking dinner while on a video call, only to accidentally salt your tea and drink your soup? Or how about commuting in Bengaluru traffic? It’s a living, breathing example of a chaotic system where every honk feels like it could alter the entire timeline. You never which way the auto driver will turn. Keep you guessing and on your feet.

Chaos is also why you can’t predict your social media feed. Algorithms try their best, but your decision to randomly like one cat meme over another might send your entire feed spiraling into chaos. Now you’re stuck with ads for cat food, and you don’t even own a pet.

The Digital Butterfly Effect

In cyberspace, chaos theory takes on a whole new meaning. The internet is a hyper-connected, highly sensitive system where small changes—like a single line of buggy code—can snowball into global meltdowns. A small commit in an unknown library can bring down tech giants and nobody would have a clue of what happened cause that one intern happily strolled off home already.

Take cybersecurity, for example. A tiny vulnerability in a server can let hackers in, causing cascading chaos across networks. Or think about AI. A chatbot misinterprets one user’s sarcasm, and suddenly, the entire algorithm thinks everyone loves pineapple on pizza. Hell no. Keep that shit away from my pizza, thanks.

Social media today is the new ground for chaos. A single tweet can spark revolutions, cancel celebrities, or send stock markets tumbling. Of course it first needs to reach masses. But sometimes an unknown random account can overthrow billions of dollars from the market. It’s chaos theory on steroids, amplified by algorithms that thrive on unpredictability.

There has been attempts to define this chaos in the past. Some have even come up with mathematical proofs and equations. Read more about the work from the greats from Henri Poincare (1889) and Cartwight and Littlewood (1945) to modern theories from Feigenbaum (1978) who studied modern day calculator and focused on the bifurcation cascade of the logistic map. Particularly, the way that bifurcations piled on top of bifurcations in a forking structure that showed increasing detail at increasingly fine scales.

Chaos theory, at its core, is about unpredictability in complex systems. It’s not inherently a bad thing, but when left unchecked, its implications can “consume” us. Specially in the modern context of interconnected digital lives.

In cyberspace, even small actions (like liking a post or sending a tweet) can spiral into unintended consequences. Algorithms thrive on chaotic systems, serving us a never ending stream of content designed to hold our attention. Before you know it, you’re 3 hours deep into cat video territory with no way out. A minor oversight, a weak password or an unpatched system, can snowball into global disruptions. Just imagine a single compromised smart device setting off a chain of ransomware attacks. In the interconnected chaos of cyberspace, small errors have catastrophic potential.

The randomness of chaotic systems can make us feel powerless. If we don’t understand why algorithms recommend certain things or why systems behave erratically, we’re essentially passengers on a runaway train.

Chaos doesn’t have to consume us. It can empower us if we respect it. Let it challenge us, teach us, and inspire us. But let’s not hand it the keys to the kingdom without safeguards. After all, the goal isn’t to control every butterfly. It’s to ensure their flutters create growth, not destruction.

So, how do we embrace chaos in cyberspace without letting it consume us?

Cybersecurity Resilience

We need systems that can handle surprises. Think firewalls and protocols that can adapt, recover, and bounce back faster than your Uber driver navigating Bengaluru traffic.

Algorithm Transparency

Chaotic systems are bad enough without black-box algorithms making decisions nobody understands. Let’s demand clarity and accountability from AI systems. Personally I really don’t like black box systems. Makes me utterly nervous.

Decentralized Networks

Centralized systems are like that one Jenga piece holding the tower together—too much pressure, and they collapse. Decentralization could distribute the load and reduce systemic vulnerabilities.

Ethics in AI and Web3

As we dive into Web3 and AI-driven worlds, ethical guidelines need to be as robust as the code itself. Because the last thing we need is chaotic systems learning bad behavior from us. Clearer the guidelines, the more cases it handles, the more monitored it becomes. It’s like raising a kid I suppose.

Chaos is here to stay, both in the real world and the digital one. And while we can’t predict or control everything, we can create systems that are resilient, transparent, and ethical. Think of it as learning to dance with the butterfly rather than swatting it away. So, whether it’s a misplaced decimal in a line of code or a viral meme that shifts global consciousness, chaos is both the problem and the solution. Let’s embrace it, adapt to it, and maybe, just maybe, turn it into a force for good in our shiny new digital frontier.

Find meaning to the madness. Both outside and within!

Network Interfaces

2024-11-23T00:00:00Z

I was working on a side project, which led me to study about various network interfaces. Felt like some rabit hole I fell through. Before I knew it, I had listing down over 10 different network interfaces. So, thought of putting them together for somebody else also studying network interfaces.

TCP/IP, or Transmission Control Protocol/Internet Protocol, is a framework that organizes the communication protocols used on the internet and similar networks. TCP/IP network interfaces are the backbone of modern digital communication, enabling devices to connect and exchange data seamlessly across various network types. These interfaces form the essential link between hardware and software, facilitating everything from local area networks (LANs) to global internet connectivity. With options ranging from Ethernet and Wi-Fi to advanced protocols like MPLS and VPN interfaces, TCP/IP ensures scalability, reliability, and versatility in diverse applications.

The TCP/IP protocol suite supports a wide range of network interfaces.

Standard Ethernet Version 2 (en)

Ethernet Version 2, created by Digital Equipment Corporation, Intel, and Xerox (DIX), is the go-to standard for wired local networks. Think of it as the classic way to connect your desktop to a router using an Ethernet cable (you know, the one with the RJ45 connector). It’s super reliable and perfect for high-speed connections, whether you’re setting up a home office or a big office network. Simple, solid, and it just works!

Pros: High reliability, consistent speed, and wide adoption.

Cons: Limited mobility compared to wireless standards like Wi-Fi.

IEEE 802.3 (et)

IEEE 802.3 is the standard behind Ethernet that works with twisted-pair and fiber-optic cables. It covers specs like 10BASE-T and 100BASE-TX, which power Fast Ethernet using Cat 5e cables in many offices. It’s super reliable and has become the backbone of modern Ethernet networks, especially in enterprise environments.

Pros: Scalability from 10 Mbps to 100 Gbps; supports various media types.

Cons: Higher cost for fiber-optic variants compared to copper-based standards.

Token Ring (tr)

Token Ring is an old-school LAN tech where devices take turns to talk by passing a “token” around—kind of like a speaking stick in a meeting. It was big back in the day, especially in banking systems with IBM’s Token Ring networks. While it’s pretty much obsolete now, it did a great job of ensuring no two devices tried to send data at the same time.

Pros: Deterministic access; suitable for real-time systems.

Cons: Slower than Ethernet; less flexible due to token passing.

Serial Line Internet Protocol (SLIP)

SLIP was one of the first protocols used for point-to-point connections over serial lines. If you remember the dial-up modems from the ’90s, that’s where SLIP came into play, helping to send IP packets over those old telephone lines. It may be outdated now, but it was a big step forward in getting the internet up and running in its early days.

Pros: Simple and lightweight.

Cons: No error detection; replaced by Point-to-Point Protocol (PPP).

Loopback (lo)

The loopback interface is like a virtual playground for your computer’s network. It’s what you use when you access localhost (127.0.0.1) to test things like web servers or debug apps without needing an actual network connection. Perfect for internal testing and troubleshooting, it’s always there when you need it!

Pros: Always available and highly reliable.

Cons: Limited to local machine interactions.

FDDI (Fiber Distributed Data Interface)

FDDI is a high-speed network tech that uses fiber optics, perfect for handling big jobs like connecting backbone networks in cities. It’s built to be super fast and reliable, making it great for things like video streaming and other high-bandwidth tasks across wide-area networks.

Pros: Redundancy through dual-ring architecture.

Cons: Expensive compared to Ethernet; largely obsolete today.

Serial Optical (so)

Serial optical tech is all about sending data over long distances using fiber optic cables. It’s what connects data centers and makes high-speed, low-latency communication possible. Perfect for when you need to move a lot of data fast and over a long stretch!

Pros: Extremely low latency and high bandwidth.

Cons: High installation and maintenance costs.

ATM (Asynchronous Transfer Mode)

ATM largely relies on a networking technology using fixed-size cells for reliable data transmission. It was popular with broadband ISPs for handling data, voice, and video all on the same network. Great at juggling different types of traffic efficiently, it was a solid choice for reliable communication back in the day.

Pros: Guaranteed bandwidth for real-time services.

Cons: Complex configuration; overshadowed by modern IP-based technologies.

Point-to-Point Protocol (PPP)

PPP is the protocol that makes direct connections between two nodes work, like DSL connections between your modem and ISP. It added features like security and authentication, making internet access safer and more reliable. It took over from SLIP and quickly became the better option for getting online.

Pros: Supports authentication and compression.

Cons: Inefficient for modern high-speed connections.

Virtual IP Address (vi)

Virtual IPs let multiple devices or services share the same IP address, which is super handy for things like load balancers in cloud setups. They help keep systems running smoothly by balancing traffic and ensuring high availability and redundancy. Essential for keeping things reliable in distributed systems!

Pros: Improves redundancy and fault tolerance.

Cons: Requires advanced configuration and monitoring.

Apple NCM Private Interface (anpi)

Apple’s NCM Private Interface (anpi) is their own custom setup for networking and connectivity. Think USB-to-Ethernet adapters for MacBooks and other Apple devices—it’s all about making things work smoothly within the Apple ecosystem. Just another way Apple keeps everything connected seamlessly!

Pros: Seamless user experience for Apple devices.

Cons: Proprietary; limited to Apple environments.

Apple Specific for VPN and Back to My Mac (utun)

The utun interface in macOS is used for VPNs and remote desktop connections, like when you access your MacBook remotely using Back to My Mac. It’s all about making sure Apple users can securely connect to their devices from anywhere. A simple way to stay connected, even when you’re not right in front of your Mac! However it might show up even when your Back to My Mac is disabled or inaccessible.

Pros: Tailored for privacy and encryption.

Cons: Exclusivity to macOS; less customizable than generic VPN solutions.

Bonded Interfaces (bond)

Bonded interfaces combine multiple network connections into one super-fast, high-bandwidth link. It’s like merging several lanes on a highway to handle more traffic at once. Servers use things like Link Aggregation Control Protocol (LACP) to balance the load and add redundancy, making sure your network stays fast and reliable, even if one link fails.

Pros: Increases speed and fault tolerance.

Cons: Requires hardware and software compatibility.

VPN Interfaces (tun/tap)

The tun and tap interfaces are key for VPN connections. tun handles routing packets, while tap works at the Ethernet level. They’re used in setups like OpenVPN or WireGuard to create secure, encrypted internet connections. Basically, they help you safely surf the web or connect to a network even when you’re on a public or unsecured network.

Pros: Strong encryption and flexibility.

Cons: Slower than direct connections due to encryption overhead.

ISDN (Integrated Services Digital Network)

ISDN (Integrated Services Digital Network) was a big deal back in the day for transferring both voice and data over the same line. It was used for things like video conferencing in the early 2000s, especially in remote areas where newer tech wasn’t available. ISDN helped bridge the gap between old-school analog and modern digital communication.

Pros: Supports simultaneous voice and data.

Cons: Outdated; replaced by DSL and fiber technologies.

VLAN Interfaces (vlan)

VLANs (Virtual LANs) let you split up a network into smaller, isolated segments, all using the same physical hardware. With VLAN tagging on managed switches, you can control and separate traffic, boosting both security and efficiency. It’s like creating mini-networks within a big one, so things stay organized and safe.

Pros: Reduces broadcast traffic and enhances security.

Cons: Configuration complexity for large setups.

Virtual Machine Interfaces (vmx, vnet, etc.)

Virtual Machine Interfaces, like vmx or vnet0 in VMware and VirtualBox, are used to connect virtual machines to networks in virtualized environments. They’re perfect for simulating networks during development and testing. These interfaces are essential for making virtualization and cloud computing run smoothly by setting up virtual networks within your machines.

Pros: Highly customizable and scalable.

Cons: Relies heavily on host system performance.

MPLS (Multiprotocol Label Switching)

MPLS (Multiprotocol Label Switching) is a method for forwarding data that helps optimize how traffic flows across networks. It’s often used in enterprise WANs to make sure data moves quickly and efficiently. By minimizing delays, MPLS ensures low-latency communication, especially across large networks.

Pros: Efficient and scalable for enterprise WANs.

Cons: Costly and requires specialised expertise.

Fibre Channel over Ethernet (FCoE)

Fibre Channel over Ethernet combines Ethernet with high-speed Fibre Channel technology, making it perfect for storage networking. It’s commonly used in data centers to connect servers to shared storage systems, letting everything run smoothly and efficiently while keeping speeds high. It’s like merging two networks to create one super-fast, reliable connection for storage.

Pros: Simplifies data center cabling.

Cons: Requires compatible hardware and specialised management.

LTE/5G (cellular)

LTE and 5G are all about getting fast internet on the go, using cellular networks. Whether you’re tethering mobile data to your laptop via a hotspot or just using it on your phone, these technologies provide high-speed wireless internet for your devices, letting you stay connected no matter where you are.

Pros: Mobility and wide coverage.

Cons: Prone to signal interference; higher latency than wired networks.

InfiniBand (ib)

It’s a super-fast networking technology used in high-performance computing (HPC) environments, like supercomputers and large clusters. It’s built for low-latency, high-throughput data transfers, delivering extreme performance where speed and efficiency are key. Perfect for environments that need to move huge amounts of data quickly and reliably.

Pros: Low latency and high throughput.

Cons: High cost; limited to specialised use cases.

Virtual Ethernet (veth)

Virtual Ethernet (veth) is a software-based interface used to connect containers and virtual machines in environments like Docker or Kubernetes. It handles networking within containerized applications, ensuring they can communicate with each other. There’s also another similar docker interface which shows up for docker containers.

Pros: Lightweight and efficient.

Cons: Not suitable for physical networking.

Bluetooth (bt)

Bluetooth (bt) is a short-range wireless tech that lets devices connect without cables. It’s what you use to pair things like wireless headphones to your smartphone or connect IoT devices with minimal power usage. It’s perfect for a wide range of wireless connections, from gadgets to smart home devices.

Pros: Low power consumption and ease of use.

Cons: Limited range and data transfer speed.

Wi-Fi (Wireless LAN Interface) (wlan)

Wireless tech that connects devices to local networks, like the Wi-Fi at home or in your office. It’s what lets you get online without needing cables, whether it’s on your phone, laptop, or tablet. It’s the most popular way to connect wirelessly to the internet and networks today.

Pros: Flexibility and ease of deployment.

Cons: Lower reliability and security compared to wired networks.

Hopefull, this gave you a brief over the commonly known network interfaces in recent times.

Each of these interfaces has unique advantages, making them essential in various networking scenarios, from enterprise data centers to everyday consumer technology to your very own home lab. Understanding their capabilities helps optimise their deployment in modern network environments.

There are even more network interfaces than listed above here. But, will leave them to be explored in near future.

The Power of Example

2024-11-21T00:00:00Z

In the labyrinth of modern life, where individuality is often celebrated above all else, the idea of leading by example remains an esoteric yet vital concept. For the modern individual—a seeker of authenticity and a curator of their experiences—the power of example is not merely about imitation. It is about setting a precedent that inspires action, demonstrates clarity, and communicates intentions in ways words alone cannot.

Whether you are launching a product, building a platform, or starting a business, the principle of leading by example is a cornerstone of credibility and success. It transcends rhetoric, presenting a tangible blueprint of possibilities for your audience, stakeholders, or users.

When introducing something new—be it a groundbreaking product, a revolutionary platform, or an entrepreneurial venture—uncertainty is the greatest hurdle. The unfamiliar breeds skepticism. People crave a tangible representation of your promise. This is where the power of example comes into play.

For a new product, a well-designed demo video or prototype demonstrates its utility better than any ad copy. Visual storytelling in a demo video can capture attention and build excitement, showcasing real-life scenarios where the product solves problems or enhances experiences. A prototype, on the other hand, allows stakeholders—be it investors, collaborators, or early adopters—to physically or virtually interact with the product, gaining firsthand insight into its functionality, design, and reliability.

Such examples not only demonstrate utility but also foster emotional engagement. They help customers visualize how the product fits into their lives, making the value proposition clearer. Whether it’s the intuitive interface of a new app, the cutting-edge design of a gadget, or the unique features of a software tool, a demo or prototype reduces uncertainty, accelerates decision-making, and establishes credibility in ways that words alone cannot.

This approach is particularly effective in today’s digital-first world, where attention spans are short, and visuals often carry more weight than text. A compelling demonstration can serve as the ultimate proof point, converting curiosity into commitment.

For a platform, showcasing early adopters or case studies provides tangible proof of its value, helping potential users understand how it can meet their specific needs. By highlighting real-world applications, such examples turn abstract features into relatable outcomes, making the platform’s benefits not only clear but also credible.

In its early days, LinkedIn showcased stories of professionals who used the platform to land new job opportunities or grow their networks. These success stories provided relatable examples of how the platform could be valuable for career growth, convincing others to join and use the platform for similar outcomes.
Before Slack became a household name in workplace communication, the company highlighted how early adopters like NASA’s Jet Propulsion Laboratory used it to streamline team collaboration. Sharing case studies of how teams used Slack to enhance productivity resonated with other organizations looking for similar solutions.
Shopify frequently shares case studies of small businesses and entrepreneurs who used its platform to create successful online stores. By showcasing stories of users who turned ideas into profitable businesses, Shopify appeals to aspiring entrepreneurs by proving its relevance in the e-commerce space.
Coursera effectively highlights stories of learners who transitioned into new careers or gained significant professional skills through its courses. By sharing these testimonials, Coursera inspires prospective learners to see how the platform can help them achieve similar goals.
As a platform for online payments, Stripe gained early traction by showcasing how startups like Lyft and Kickstarter successfully used its API to handle their payment processing. These examples gave developers confidence in the platform’s reliability and scalability, accelerating its adoption.

Why It Works:

Relevance: Case studies show potential users how they might use the platform, reducing uncertainty.
Proof of Success: Highlighting early adopters’ achievements builds trust by demonstrating the platform’s real-world effectiveness.
Inspiration: These stories inspire users by illustrating the potential outcomes of adopting the platform, making them more likely to engage.

By leveraging early adopters and case studies, platforms can foster credibility, build a sense of community, and accelerate user acquisition by aligning their features with real-life outcomes. This approach transforms potential skepticism into excitement, turning hesitant prospects into loyal users. Even for a startup or business*, the founder’s conduct and transparency in decisions set the tone for company culture and customer trust.*

Just as stories are essential for emotional resonance, examples are the proof points that convert abstract ideas into actionable understanding. In the world of software development, Test-Driven Development (TDD) emphasizes writing tests before writing the actual code. These tests serve as examples of what the program is supposed to do. They ensure clarity, define expectations, and create a framework within which innovation can thrive.

Clarity: Tests, like examples, define the outcomes. They ensure everyone—from developers to stakeholders—understands the objectives.

Incremental Growth: By starting small and iteratively adding features that pass predefined tests, TDD mirrors how businesses can use small, clear examples to grow credibility.

Feedback Loop: The continuous validation of code through tests mirrors how real-world examples validate a business’s promises.

Adopting the ethos of TDD in broader contexts emphasizes the importance of defining goals through actionable, testable precedents. Whether it’s a startup pitch or a marketing strategy, thinking in terms of clear, “testable” examples can make abstract ambitions more relatable and trustworthy.

Tesla’s Product Strategy

Tesla didn’t just sell the idea of electric vehicles; it delivered the Tesla Roadster, a high-performance sports car, as proof of concept. The example set the tone for its revolutionary approach to sustainable energy.

OpenAI’s Transparency with GPT Models

OpenAI regularly shares research papers and use-case demos to educate and set an example for AI’s ethical potential. These actions demonstrate their commitment to innovation and responsibility.

Airbnb’s Early User Strategy

Before Airbnb scaled, its founders went door-to-door to help hosts perfect their listings. This example of dedication not only enhanced trust but also demonstrated the platform’s value to both hosts and guests.

The power of example is universal, yet its execution varies across contexts. From inspiring team members to convincing potential investors, the principles of clarity, reliability, and demonstrable proof remain constant.

What's Your Paranoia?

2024-11-18T00:00:00Z

In the complex maze of the modern mind, where every turn presents a new fear, a new inadequacy, or a new ambition, lies the pervasive whisper of paranoia. Not the kind typically associated with conspiracy theories or spy thrillers, but a more subtle, insidious form that has become almost a default setting for human interaction in today’s society. Here, we explore the multifaceted nature of personal paranoia, its origins, its impacts, and its philosophical implications.

The Spectrum of Modern Paranoia

Paranoia today isn’t just about fearing surveillance or betrayal; it’s a broad spectrum that includes the fear of time slipping away, not accumulating enough knowledge, not achieving enough success, or not possessing enough wealth. This isn’t clinical paranoia but rather a societal condition where we measure themselves against an ever-escalating standard of what it means to be ‘enough’.

Time ⏱️

The relentless march of time in a society obsessed with productivity and youth fosters a pervasive paranoia of aging, creating an almost existential fear of falling behind. We are constantly reminded that success has an unspoken expiration date, with youth glorified as the peak of vitality, creativity, and relevance. This fixation seeps into our daily lives, pressuring us to achieve more in less time, to seize every fleeting opportunity, and to stay perpetually “in the game.” It transforms the natural process of aging into something to be resisted, denied, or even feared, as though the mere passage of years diminishes our value. This paranoia is amplified by social media’s highlight reels and the cultural obsession with “overnight success,” leaving many feeling as if they’re racing against an invisible clock, desperate to capture life’s elusive milestones before the sands of time run out. In this unrelenting pursuit, we often overlook the quiet beauty of living in the moment, trading peace for a battle against a clock that never pauses.

Knowledge 📖

In an age where information is at our fingertips yet overwhelming, there’s a constant anxiety about not knowing enough, about being left behind in the intellectual race. The internet has democratized access to knowledge, but it has also created a relentless pressure to keep up. Professionals feel compelled to master every new industry trend, fearing obsolescence in a hyper-competitive job market where expertise seems to have an ever-shortening shelf life. For instance, a software developer might feel inadequate if they aren’t fluent in the latest programming languages, even if their core skills remain relevant. Similarly, a student scrolling through endless online courses may feel paralyzed, unable to decide which skill to learn, all the while haunted by the thought that everyone else is learning faster, achieving more, also known as Choice Overload. Even outside of formal education or work, the sheer volume of information—news updates, academic papers, social media debates—creates a gnawing fear of being uninformed or excluded from critical conversations. This constant exposure to the vastness of what we don’t know fuels a deep-seated paranoia that, no matter how much we learn, it will never be enough. In a way, we are all living in imposter syndrome. How did we all collectively get here together?

Success 🏆

Defined by societal benchmarks, success can become a source of paranoia where failure, or even just the lack of extraordinary achievement, feels like a personal catastrophe. This pressure often manifests in careers, where the absence of rapid promotions or prestigious titles can feel like falling behind in an invisible competition. For example, a young entrepreneur may feel consumed by anxiety if their startup doesn’t become the next billion-dollar unicorn within a few years, especially when bombarded by stories of prodigies who achieve massive success before turning 30.

Students often grapple with this paranoia as well, comparing themselves to peers publishing groundbreaking research or securing scholarships to elite institutions. Similarly, on social media platforms, creators face an unspoken race to amass followers, likes, and viral moments, with each day that passes without such milestones exacerbating the fear of irrelevance.

Even in personal lives, societal benchmarks can overshadow individuality. The expectation to marry by a certain age, buy a home, or achieve financial independence creates an underlying paranoia of “not making it” in time. A 35-year-old who chooses to travel or explore unconventional paths might feel judged or question their decisions when compared to peers who are seemingly settled.

These societal pressures cultivate an environment where the pursuit of success isn’t just about growth but about avoiding the stigma of perceived failure, leaving many trapped in a cycle of self-doubt and relentless striving.

Wealth 💰

The visibility of wealth via social media and global connectivity has turned financial security into a race where many feel they are lagging. Platforms like Instagram and TikTok showcase lavish lifestyles, luxury vacations, and material possessions that often serve as symbols of success. This constant exposure can create an illusion that everyone else is thriving financially, leaving many grappling with feelings of inadequacy.

“The more we are surrounded by people who have apparently attained a great deal, the more difficult it becomes to be content with anything less.”

– Alain de Botton

For someone struggling to make ends meet or simply building their financial foundation, seeing peers—or even strangers—displaying their achievements can foster an insidious paranoia. Questions like “Am I earning enough?” or “Will I ever achieve that level of wealth?” just rage through on a daily basis. The pressure is magnified in a world where wealth is often equated with worth, and financial setbacks are sometimes perceived as personal failures rather than circumstantial challenges.

Since the Postmodern Society

This pervasive paranoia didn’t emerge in a vacuum. It’s a child of postmodernity, where traditional narratives have been fragmented, and the individual is thrown into a world of infinite choices, identities, and paths. The breakdown of grand narratives leaves a void, often filled with personal insecurities and fears, many of which we still carry on, alongwith the ever increasing new variants of the same.

Shaping Communities and Life

This collective paranoia shapes not just individual psyches but entire communities. It fosters a competitive rather than cooperative societal framework where:

Trust becomes scarce as we suspect others of harboring the same insecurities or worse, of possessing what we lack. Relationships become fragile, overshadowed by silent comparisons and unspoken doubts. Even moments of connection can feel transactional, weighed down by the fear of ulterior motives or hidden agendas. In a world where everyone seems to be competing for the same finite resources—be it success, validation, or affection—vulnerability becomes a risk too great to take.

Community Building is challenged as people, driven by their fears, might retreat into themselves, or engage in superficial interactions based on perceived status or success. Life Choices are often influenced more by fear of what might go wrong than by passion or joy, leading to a life lived in anticipation of disaster rather than celebration of possibility.

A Double-Edged Sword

For some, it can fuel ambition, pushing us to work harder, learn more, and strive for better, viewing life as a game that must be played to win. It can heighten awareness of real dangers or societal issues, prompting proactive behavior in areas like personal security or financial planning.
However, the constant undercurrent of fear can lead to stress, anxiety, and depression, undermining the very success it seeks to achieve. It might erode the essence of human connections, replacing empathy with envy or indifference.

The fears we harbor shape the decisions we make, the relationships we build, and the paths we choose. Yet, here lies a paradox:

Creation of Reality: If paranoia shapes our actions, are we not also shaping our reality? Could our destiny be both a manifestation of our fears and our desires?
Choice: Knowing this, we stand at a crossroads where we can either let paranoia dictate our journey or use our awareness to navigate by starlight rather than storm clouds.

In a society striving for progress, could we perhaps see paranoia not just as a burden but as a signal? A call to delve deeper into ourselves, to understand what truly unnerves us and why. That part of your brain you’ve locked away, avoided, averted and ignored.

By confronting our fears, we might strip away the layers of societal expectation to find what genuinely matters to us. We can begine to understand our common fears could bridge divides, fostering a sense of shared human experience rather than competition. Most importantly, talk about it. Doesn’t matter with whom. However paranoid you are, you must trust at least one person. Perhaps our destiny is not predefined but is instead the sum of our reactions to our fears, where overcoming paranoia becomes an evolutionary step toward a more enlightened existence.

As we navigate this age of personal paranoia, we are left with pivotal questions: Are we prisoners of our fears, or are they the very lessons that guide our evolution? Can we transform paranoia from a shadow over our lives into a tool for personal and collective awakening? What kind of human do we become when we decide to confront our deepest fears, and how does this choice resonate through the tapestry of our destiny?

Let me know if you find the answers before me. :)

Decentralising the Web

2024-11-17T00:00:00Z

The web, in its earliest form, was envisioned as a decentralized platform—a space where anyone could share information without gatekeepers. Over time, however, the internet has become centralized. A handful of corporations now control vast amounts of online data, dictating how we interact, transact, and communicate. This centralization has led to issues like censorship, data privacy violations, and monopolistic practices. Sorry, didn’t mean to go full Mr Robot here. This is more on technical advancement and why you should care about it.

Decentralizing the web is a movement to restore power to individuals by creating systems where data and control are distributed, not concentrated. At its core is the idea of a web owned by its users rather than intermediaries. It is the foundation of what we now call Web3 or Web3.0.

The Promise of Blockchain and What Led to Its Success

Blockchain technology lies at the heart of decentralization. A blockchain is a distributed ledger that records transactions across multiple computers, ensuring transparency and immutability. The technology became mainstream with Bitcoin, a decentralized cryptocurrency introduced in 2009. It offered a revolutionary alternative to traditional banking systems by allowing peer-to-peer transactions without intermediaries.

Blockchain’s success stems from its potential to solve real-world problems:

Trust: Transactions are secure, verified, and transparent.
Ownership: Users own their data and digital assets.
Accessibility: Decentralized networks are open to anyone with internet access.

The Ethereum blockchain expanded this promise by introducing smart contracts, enabling decentralized applications (dApps). This innovation fueled the rise of decentralized finance (DeFi), non-fungible tokens (NFTs), and decentralized autonomous organizations (DAOs), paving the way for Web3.

The Current State of Blockchain and Web3

Despite its promise, blockchain and Web3 are still evolving. Challenges include:

Scalability: Networks like Ethereum are working to handle larger transaction volumes efficiently.
User Experience: Web3 interfaces are often complex for everyday users.
Regulation: Governments are grappling with how to regulate decentralized technologies without stifling innovation.
Energy Concerns: While proof-of-stake has mitigated some issues, energy usage remains a topic of debate.

On the bright side, the Web3 ecosystem is thriving:

DeFi platforms manage billions in assets.
NFTs are transforming art, gaming, and digital ownership.
Major players like Solana, Cosmos ecosystem, and Layer 2 solutions like Base, Optimism, Arbitrum as well as other protocols like uniswap, eigen layer, axelar and as such more are driving innovation.

Where Are We Headed?

The future of Web3 looks promising, with advancements in scalability, interoperability, and usability. As blockchain becomes more integrated into everyday applications, we may see:

Decentralized identity systems replacing traditional login credentials.
Tokenized economies, where users earn from participation in digital ecosystems made popular with stable coins.
Metaverse adoption, powered by blockchain-based assets and platforms.

This shift isn’t just about technology—it’s about empowering individuals, fostering creativity, and enabling more equitable economic opportunities.

Why Should You Care?

Centralized systems limit freedom and control. Embracing decentralization can redefine how we interact with technology, making the digital world more equitable and open.

How Do You Start?

Learn: Explore blockchain basics via platforms like Coursera, YouTube, or Web3-focused communities.
Experiment: Create a crypto wallet, interact with dApps, or play around with various digital tokens and cryptocurrencies.
Engage: Join Web3 communities and participate in discussions on platforms like Twitter, Discord, or Reddit.

Watch for emerging trends in DeFi, NFTs, and decentralized social platforms. Look for projects that align with your values, and be part of building the decentralized future.

As we decentralize the web, we move closer to Tim Berners-Lee’s vision of an internet that is “for everyone.” Blockchain and Web3 offer not just technological advancement but also a philosophical shift—one where power, control, and opportunity are redistributed.

As Vitalik Buterin, the creator of Ethereum, aptly put it:
“We don’t need to wait for some kind of future revolution; we just need to keep building piece by piece, solving problems as they come up, and eventually, we’ll get there.”

The Perfect Flaw

2024-11-02T00:00:00Z

In a world increasingly drawn to the pursuit of perfection, the notion of embracing flaws may seem counterintuitive. Yet, these so-called “flaws” might just be what make us remarkable. This paradox is beautifully encapsulated in the concept of The Perfect Flaw—the idea that imperfections are not just acceptable but also essential in defining authenticity, resilience, and growth.

The concept has deep roots across cultures and philosophies. In Japan, the aesthetic of wabi-sabi emphasizes beauty in imperfection, embracing the incomplete and impermanent. Similarly, kintsugi, the art of repairing pottery with gold, values the cracks as part of an object’s story rather than signs of damage. Western philosophy also resonates with this notion through thinkers like Nietzsche, who argued that “what does not kill us makes us stronger,” suggesting that our struggles are pathways to greatness.

The Perfect Flaw in Creativity

Creative fields thrive on imperfections, serendipity, and divergence from norms. Many of history’s most iconic works of art and literature have come from artists who defied conventions or revealed personal vulnerabilities. Van Gogh’s bold brushstrokes, Frida Kahlo’s unapologetic representation of pain, and even Hemingway’s pared-down prose reflect the beauty of embracing one’s unique vision, however unconventional.

Moreover, imperfections in creativity often inspire innovation. When a “perfect” idea doesn’t work out, it is often the pivot or adaptation—the so-called flaw in the original plan—that leads to breakthrough. Think about Post-it notes, the accidental creation that revolutionized office spaces worldwide. The concept of a “flawed” adhesive became a billion-dollar idea because someone was willing to view a perceived mistake as an opportunity.

The Perfect Flaw in Personal Growth

The journey of self-improvement often brings a focus on our weaknesses, but The Perfect Flaw suggests a new way to view them. Instead of seeking to eliminate flaws, we could see them as areas of growth and character-building. Recognizing and accepting our limitations allows us to understand ourselves more fully, to navigate life with humility, and to foster empathy towards others facing similar struggles.

Embracing imperfections enables resilience; when we accept failure as a natural step rather than a debilitating setback, we become less afraid to take risks. Every imperfection reveals an opportunity for self-reflection and renewal, helping us grow in ways perfectionism might stifle.

The Perfect Flaw in Technology and Innovation

Technology and design industries often emphasize precision and perfection, yet some of the most groundbreaking products have come from an acknowledgment of imperfection. Think about the evolution of software; no software version is ever perfect, and updates are constant, acknowledging the room for growth. The Perfect Flaw is central to an iterative design process, where continuous improvement outpaces the unrealistic goal of a “perfect” product from the outset.

In emerging fields like artificial intelligence, the beauty of imperfection is even more pronounced. A perfect algorithm would be static, inflexible, and perhaps even incapable of handling real-world variables. Embracing the unpredictability in data allows AI to adapt, improve, and learn, which is a powerful nod to The Perfect Flaw in action.

The Perfect Flaw as a Life Philosophy

Adopting The Perfect Flaw as a personal philosophy allows for greater freedom, self-acceptance, and joy. Instead of measuring our worth by impossible standards, we appreciate the journey and recognize that our unique imperfections add depth to our lives.

By viewing flaws as integral parts of ourselves rather than defects, we gain clarity, strength, and authenticity. The journey to becoming a better version of ourselves need not imply achieving flawlessness, but rather learning, growing, and accepting who we are.

The Perfect Flaw in Shaping Evolution

Evolution thrives on variation, and those variations—often perceived as “flaws” or deviations from an ideal standard—are what enable species to adapt to changing environments. These variations are not mistakes but are, in fact, the raw material on which natural selection operates. The concept of The Perfect Flaw in evolution reveals how nature embraces imperfections as a means of strengthening species across generations.

For example, genetic mutations are random changes in DNA that may initially seem like flaws. While many mutations are neutral or even harmful, a select few confer advantages that help individuals survive and reproduce in specific environments. Over time, these advantageous “flaws” spread through the population, allowing it to better withstand challenges such as climate shifts, predators, or diseases. A classic example is the peppered moth in England, which developed a darker coloration during the Industrial Revolution, a mutation that allowed it to blend in with soot-covered trees and avoid predation. What was initially an oddity in coloration became a survival advantage as environmental conditions changed.

Similarly, human evolution has benefited from imperfections that have shaped our unique abilities. For instance, the mutation that led to sickle-cell anemia—a condition that distorts red blood cells—provides a degree of immunity to malaria in carriers, which has proven advantageous in regions where malaria is prevalent. Here, what might seem like a genetic “flaw” actually confers resilience against a major health threat.

The Perfect Flaw also allows for behavioral evolution. In social species, individuals who deviate from typical behavior patterns can introduce new social structures or survival strategies, ultimately benefiting the group as a whole. For instance, cooperation in wolf packs and altruistic behaviors in primates allow these groups to respond flexibly to environmental stresses, such as food scarcity or the presence of predators.

At the species level, The Perfect Flaw fosters biodiversity, creating ecosystems rich in variety and resilience. A perfectly homogenous species or ecosystem would be highly vulnerable to sudden environmental changes, whereas a diverse population can adapt and survive through the strength of its variations. Nature’s tolerance for imperfection is, in essence, a testament to the value of diversity as an adaptive force.

In the grand scheme of life on Earth, The Perfect Flaw shapes evolution by ensuring that imperfection isn’t merely tolerated but essential. The resilience of life depends on these so-called flaws—natural deviations that, far from being errors, are pathways to survival and adaptation. Thus, The Perfect Flaw isn’t just a philosophical concept; it’s a fundamental principle that has governed the evolution of all life. Embracing imperfections doesn’t hinder progress; it drives it, both in nature and in ourselves.

The pursuit of perfection often leaves us dissatisfied and critical of our lives, while The Perfect Flaw invites us to reframe this mindset. When we see imperfection as part of the human experience, we can finally begin to live more authentically, to innovate with courage, and to form deeper connections with those around us.

So, perhaps our most perfect qualities are not those that make us flawless, but rather those that make us real. In that raw, authentic state, we find a beauty that is not only rare but also truly irreplaceable. In embracing The Perfect Flaw, we embrace ourselves.

Imagination: The Final Interface

2024-10-27T00:00:00Z

In an era where technological advances continue to break the boundaries of what once seemed like science fiction, we stand at a crossroads between the physical and the digital. The interface has always been the bridge between humans and machines—beginning with the simple command-line, evolving through graphical user interfaces (GUIs), and now, the immersive experiences of augmented reality (AR) and virtual reality (VR). Yet, despite these advancements, the ultimate interface, one that requires no intermediary hardware or software, remains within us: our imagination.

The Evolution of Human-Machine Interfaces

From early computing, where users had to type exact commands to communicate with a machine, to today’s sophisticated touchscreens and voice commands, interfaces have become more intuitive, more human. The keyboard and mouse revolutionized user interaction, but it wasn’t until the advent of the smartphone that the notion of a device being a natural extension of the user became more pronounced.

Today, we are witnessing the rise of immersive technologies. Virtual reality places users in completely fabricated worlds, while augmented reality superimposes digital information onto the physical world. These interfaces are designed to blend the real and the virtual, but even in their most advanced forms, they require physical devices—smartphones, VR headsets, or AR glasses.

But what if the need for external devices disappeared? What if the interface became so seamless that it transcended the material world entirely?

Enter Imagination: The Ultimate Interface

Imagination has always been at the heart of human innovation. It’s the space where our thoughts, dreams, and possibilities converge. Historically, it has been the playground for writers, artists, and philosophers. However, what if our imaginations could directly shape the digital world around us, turning thoughts into action without the need for any intermediary?

This concept, often explored in science fiction, is now approaching the fringes of reality. Brain-computer interfaces (BCIs) have demonstrated the potential to turn neural signals into digital commands, allowing users to control machines with their thoughts. Companies like Neuralink and Kernel are at the forefront of this movement, aiming to create a future where the human brain becomes the interface to everything digital.

However, the idea of imagination as the final interface goes beyond the mere translation of thoughts into commands. It envisions a future where our mental landscape becomes the canvas for creating, experiencing, and interacting with digital environments. In this world, instead of manipulating a screen or speaking commands, you simply imagine your desired outcome, and it becomes real in the digital space.

Potential of an Imagination-Based Interface

Limitless Creation: With imagination as the interface, the boundaries of creation would be limitless. Artists and designers could shape digital environments as quickly as they could think, and everyday users could construct personalized virtual worlds in an instant.

Intuitive Interaction: Unlike today’s devices, which require a learning curve, interacting with your own imagination would be second nature. Your thoughts would guide the experience, making it as intuitive as breathing.

Accessibility for All: One of the greatest challenges with current technology is accessibility. Imagination-based interfaces could level the playing field, allowing individuals with disabilities or limitations to interact with the digital world in a completely natural way.

New Forms of Communication: Language barriers would vanish. Instead of verbalizing thoughts, people could share their raw, unfiltered ideas directly through neural connections, enabling a form of communication far richer than anything words can provide.

Challenges and Ethical Considerations

While the concept of imagination as the final interface is exciting, it also presents profound challenges. The idea of linking our minds directly to digital systems opens up complex ethical questions:

Privacy: If thoughts can be transformed into commands, how do we protect individuals from having their private thoughts accessed or exploited?
Security: As with any technology, a direct neural interface would need to be protected against hacking or malicious interference. The consequences of breaching such an interface could be catastrophic.
Identity and Authenticity: In a world where imagination creates reality, how do we distinguish between the physical and the imagined? How do we maintain a sense of identity when the line between what’s real and what’s not becomes so blurred?

Imagination Meets Reality

Despite the challenges, the future of an imagination-based interface isn’t just a dream—it’s a possibility that the technological world is actively exploring. With advances in neuroscience, artificial intelligence, and brain-computer interfaces, the bridge between imagination and reality is narrowing. What once belonged to the realm of fiction may soon be part of our everyday lives.

At its core, imagination is where all human progress begins. It’s the engine of innovation, the source of creativity, and the final frontier in our quest to merge the digital and the real. As we look toward a future where imagination becomes the interface, we must remember that the most powerful technology we have always had has been within us all along.

The final interface may not be something we touch, see, or hear—it may be something we already possess. Imagination, untethered from the constraints of physical devices, has the potential to become the most advanced interface of all. It is here, at the intersection of thought and technology, that humanity will find its greatest frontier yet. With imagination as the guide, the possibilities for innovation, creation, and connection are truly limitless.

Of course, this needs to be studied more…

Designing The Perfect Incentivised System - Part 2

2024-10-24T00:00:00Z

A lot of the recent rise in isekai anime also suggests a favorable wind towards perfecting our system.

In the anime Hunter x Hunter, the incentive system plays a crucial role in driving the narrative and character development, particularly in the context of the Hunter Exam and various arcs throughout the series.

The Hunter Exam

The most prominent example of an incentive system in Hunter x Hunter is the Hunter Exam, which is designed to evaluate the potential of aspiring Hunters. This exam offers various incentives and motivations for participants, leading to a competitive environment.

Key Features:

Status and Prestige: Becoming a Hunter is a prestigious achievement that grants access to exclusive resources, knowledge, and opportunities. The allure of becoming a Hunter motivates numerous characters to enter the exam, despite its dangers.
Diverse Challenges: The exam comprises multiple stages, each presenting unique challenges that test candidates’ physical and mental abilities. The variety of tasks incentivizes different skill sets and encourages teamwork and strategy.
Elimination Format: The exam’s competitive nature, where candidates are eliminated based on performance, adds a layer of urgency. This structure incentivizes candidates to perform at their best to avoid being cut from the competition.

Individual and Team Incentives

Throughout the series, characters often face situations where individual goals conflict with group objectives, reflecting the dynamics of incentive systems.

Examples:

Alliances and Betrayals: Characters like Gon, Killua, and Leorio form alliances to navigate challenges. However, their individual motivations can lead to conflicts, showcasing the tension between personal and collective goals.
Personal Growth: The characters are often driven by personal desires—Gon’s quest to find his father, Killua’s struggle for independence from his family, and Kurapika’s desire for revenge. These individual incentives create depth in their motivations and actions.

Nen and Its Role as an Incentive System

The Nen system in Hunter x Hunter serves as a complex incentive structure that rewards training, strategy, and creativity in combat.

Key Features:

Personalization: Nen abilities are unique to each user and are based on their personality and experiences. This personalization incentivizes Hunters to invest time and effort into mastering their abilities, as they become extensions of themselves.
Strategic Thinking: The Nen system encourages strategic thinking, as users must understand their strengths and weaknesses and those of their opponents. The incentive to outsmart foes adds layers to battles, making them not just about power but also about wits.

Consequences and Trade-offs

The series also highlights the consequences of the incentive systems in place, particularly regarding the ethical implications of the Hunters’ choices.

Moral Dilemmas: Characters often face moral dilemmas where the pursuit of their goals can lead to negative consequences for others. For instance, some Hunters prioritize their objectives over the well-being of others, raising questions about the ethics of their actions.
Sacrifices: The journey of becoming a Hunter often requires personal sacrifices, be it in terms of relationships, physical well-being, or moral integrity. This reflects the trade-offs inherent in any incentive system.

The Auction and the Underworld

Another significant incentive system is the auction and underworld dealings that occur later in the series, particularly during the Greed Island and Chimera Ant arcs.

Features:

Scarcity and Value: Rare items and information become valuable commodities in the auction system, incentivizing Hunters to participate in dangerous missions to acquire them. The allure of these items drives characters into conflict and competition. 💎
Risk vs. Reward: The underworld emphasizes the risk involved in pursuing rewards. Characters must weigh the potential gains against the dangers they face, illustrating the high stakes associated with their desires. ⚖

In Hunter x Hunter, the various incentive systems—ranging from the Hunter Exam to the Nen system and the underworld dealings—serve to shape character motivations, drive the plot, and explore deeper themes of morality, competition, and personal growth. The complexity of these systems reflects the series’ intricate storytelling, making it a rich exploration of human desires and the consequences of pursuing them.

Tower of God

In the anime Tower of God, we see the incentive system is intricately woven into the narrative and serves as a crucial mechanism for driving character motivations, conflicts, and the overall plot. The Tower itself functions as a multi-layered arena where characters face various challenges, each governed by its own set of incentives and rules.

Climbing the Tower

At the core of Tower of God is the overarching goal of climbing the Tower, which serves as the primary incentive for many characters. The Tower promises immense power, wealth, and the chance to achieve one’s dreams at the top.

Desire for Power and Fulfillment: Each character has their own motivations for climbing, ranging from personal ambition to the desire to reunite with loved ones. For example, Bam’s journey is driven by his desire to find Rachel, while other characters seek glory or revenge.
Challenges and Trials: The Tower is divided into multiple floors, each presenting unique tests and challenges. Successfully overcoming these trials serves as an incentive for characters to prove their strength and skill.

The Role of Rankers

Within the Tower, there are two main categories of climbers: regulars and rankers. Rankers are those who have already ascended and achieved a high status, serving as both mentors and adversaries to the regulars.

Authority and Status: Rankers hold significant power and influence within the Tower, and this status serves as a major incentive for regulars to aspire to reach their level. This dynamic creates a competitive atmosphere where regulars must constantly prove themselves.
Rewards and Responsibilities: Rankers often receive special privileges and responsibilities, which can incentivize them to assist or manipulate regulars in their ascent. The relationships between rankers and regulars can create complex social dynamics based on competition and cooperation.

The Test and Competition Structure

The various tests within the Tower are structured to foster competition among regulars, which is a fundamental aspect of the incentive system.

Teamwork vs. Individualism: Many challenges require cooperation among climbers, creating a dual incentive of working together to succeed while also competing for individual glory. This dynamic is evident in the early tests, where characters must form alliances to survive.
Elimination and Advancement: The competitive nature of the tests means that failure results in elimination from the Tower, which serves as a powerful motivator. The threat of elimination encourages characters to push their limits and take risks.

In Tower of God, the incentive system is multifaceted, shaping the motivations and actions of characters as they navigate the challenges of the Tower. The interplay between personal desires, competition, and the hierarchical structure of regulars and rankers creates a rich narrative landscape. The series delves into the complexities of ambition, sacrifice, and the human experience, making the incentive system an integral part of its storytelling.

Solo Levelling

One of my personal favorites. In the anime Solo Leveling, the ranking and incentive system is central to the story’s premise and character development. The world is divided into Hunters—individuals who possess supernatural abilities and engage in battles against monsters from dungeons. The ranking system not only categorizes Hunters but also serves as a key incentive mechanism, motivating characters to grow stronger and face increasingly formidable challenges. Here’s a detailed exploration of the ranking and incentive system in Solo Leveling:

Hunter Ranks

The ranking system in Solo Leveling categorizes Hunters based on their strength and abilities. The ranks are typically divided into several tiers, from the lowest to the highest:

E-Rank: The weakest category, often consisting of inexperienced Hunters with limited abilities.
D-Rank: Slightly stronger than E-Rank, but still considered low-tier.
C-Rank: Competent Hunters capable of handling moderate threats.
B-Rank: Stronger Hunters who can take on more challenging dungeons.
A-Rank: Highly skilled Hunters with significant abilities and experience.
S-Rank: The elite class of Hunters, known for their exceptional strength and prowess.

This ranking system not only establishes a hierarchy among Hunters but also influences their status, opportunities, and how they are treated in society.

Incentives for Levelling Up

The ranking system provides various incentives for Hunters to level up and improve their abilities.

Recognition and Prestige: Higher-ranked Hunters gain social status and respect. The desire to be recognized as a strong and capable Hunter drives many characters to strive for improvement.
Access to Better Resources: Higher ranks often translate to access to more lucrative missions and dungeons, as well as better gear and resources. This creates a tangible incentive for Hunters to train and advance.
Financial Rewards: Completing higher-level dungeons typically yields greater monetary rewards. As Hunters rise in rank, the potential for earning increases, motivating them to take on more challenging tasks.

Of course in this anime only our protagonist can level up.

The Role of Dungeons

Dungeons are critical to the ranking system, as they serve as the primary battlegrounds for Hunters. The difficulty of the dungeon often corresponds to the rank of the Hunters needed to clear it.

Increased Challenge: Higher-ranked dungeons require stronger Hunters, presenting a significant incentive for individuals to level up. The potential for earning greater rewards in higher-level dungeons drives Hunters to improve their skills.
Experience and Growth: The process of entering dungeons allows Hunters to gain valuable experience, level up, and hone their abilities. As they face stronger monsters, they have the opportunity to prove themselves and ascend in rank.

The Protagonist’s Journey

The story follows Sung Jin-Woo, an E-Rank Hunter who starts at the bottom of the ranking system. After a near-fatal encounter in a double dungeon, he gains a unique ability that allows him to “level up” in a video game-like manner.

Unique Incentive Mechanism: Jin-Woo’s ability to level up independently of the traditional ranking system sets him apart. This mechanic serves as a powerful incentive for his growth, as he can train and gain strength rapidly compared to his peers.
Transformative Growth: As he levels up, Jin-Woo transitions from being one of the weakest Hunters to an S-Rank Hunter. His journey highlights the incentives tied to perseverance, dedication, and the pursuit of power.

The ranking and incentive system also explores social dynamics and psychological motivations among Hunters.

Competition and Rivalry: The hierarchical nature of the ranking system fosters competition among Hunters. This rivalry can lead to alliances or conflicts, as individuals strive to outperform one another.
Fear of Weakness: Many Hunters experience anxiety about their rank, as being labeled weak can lead to social stigma and reduced opportunities. This fear drives characters to push themselves harder and take greater risks to improve their status.

Consequences of the System

The ranking and incentive system in Solo Leveling also has its darker aspects, revealing the pressures and challenges that come with the pursuit of power.

Moral Dilemmas: Characters may face ethical choices when pursuing their goals, such as sacrificing others for personal gain or engaging in ruthless competition.
Mental Strain: The constant pressure to rank up and improve can lead to mental strain and burnout, as Hunters push themselves to their limits.

The ranking and incentive system in Solo Leveling serves as a vital framework for character motivations, societal dynamics, and the overarching plot. By establishing clear tiers of strength and associated rewards, the system encourages characters to grow and adapt, creating a compelling narrative of struggle and triumph. The series effectively explores themes of ambition, competition, and the costs associated with the pursuit of power, making the ranking system an integral aspect of its storytelling.

Similar scoring systems are used in multiple real life scenarios as is in anime. The limits of a limitless system is the most crucial point for the existence of any perpetual system. If we know what’s supposed to be the peak and what’s the rock bottom, we have our range to work with. But often, in society and life, the strongest keeps changing and so does our knowledge of the weakest.

…to be continued.

Designing The Perfect Incentivised System - Part 1

2024-10-22T00:00:00Z

As I started writing this, it became apparent as to how deep the rabbit hole really is… 🐰

So, I’m breaking up the discovery phase in multiple parts. If you’re just catching up, start at the beginning… 🏆

Incentive systems are frameworks designed to motivate individuals or groups to achieve specific goals by offering rewards, recognition, or penalties. These systems can be implemented in various contexts, from businesses to governments, and are essential for driving behavior that aligns with desired outcomes.

A well-structured incentive system does more than offer financial rewards. It considers intrinsic motivation, such as the satisfaction of achievement, recognition, or personal growth. Successful incentive systems balance short-term gains with long-term sustainability, preventing negative behaviors like gaming the system or burnout.

However, designing effective incentive systems requires understanding our psychology, individual preferences, and the dynamics of the environment. Poorly designed systems can lead to unintended consequences, such as encouraging counterproductive competition or diminishing intrinsic motivation. Therefore, the challenge lies in creating incentives that inspire optimal behavior while maintaining fairness and promoting a culture of continuous improvement.

Incentive systems are not one-size-fits-all. They must be adaptable, transparent, and aligned with the broader values and goals of the organization or community. When executed well, they can significantly enhance performance, engagement, and innovation. But, don’t take my word for it. Let’s take a trip through time.

The Origin Story

From the earliest days, we understood that offering something desirable—like food, shelter, or status—could motivate individuals or groups to act in certain ways. These foundational ideas evolved over time, shaping how modern societies and organizations drive productivity and success.

In the workplace, formal use of incentive systems became prominent during the Industrial Revolution in the 18th and 19th centuries. Factories, driven by mass production, started using financial rewards—like piece-rate pay, where workers earned money based on output—as a way to boost efficiency and productivity. This marked one of the earliest structured incentive systems in modern business.

By the early 20th century, thinkers like Frederick Taylor and his “scientific management” principles influenced how organizations designed these systems. Taylor emphasized optimizing workflows and using incentives to increase output. His work laid the groundwork for performance-based rewards, which many industries adopted to motivate workers while maximizing profits.

Over time, incentive systems grew beyond financial rewards. By the mid-20th century, companies began incorporating more diverse incentives, like promotions, recognition programs, and professional development opportunities, acknowledging that motivation was about more than just money.

Today, incentive systems have evolved further, especially in the digital age. Companies leverage everything from flexible work arrangements to social recognition on platforms, understanding that a blend of intrinsic (personal satisfaction, purpose) and extrinsic (monetary rewards, perks) motivators is essential for driving both individual and organizational success.

📜 The idea of using incentives goes all the way back to ancient Egypt! Pharaohs used a kind of “bonus” system to motivate workers building the pyramids. Workers were sometimes paid in beer—a valuable commodity back then—encouraging them to work harder and stay motivated during massive construction projects.

Nosedive

In the Black Mirror episode “Nosedive” (Season 3, Episode 1), the entire society operates on a highly sophisticated incentive system based on a personal rating system that impacts nearly every aspect of people’s lives. This episode provides a dystopian commentary on how a culture driven by social ratings and approval can create incentives that influence behavior in troubling ways.

In Nosedive, each person is constantly rated on a scale of 1 to 5 ⭐️ after every interaction, whether it’s a casual conversation, a service experience, or a social media post. These ratings are given and received through augmented reality (via implants and smart devices), making social validation an omnipresent and quantifiable aspect of life.

Incentive Structure:

High Ratings = Privilege: People with a high rating (closer to 5 ⭐️) have access to better services, exclusive communities, and high social status. For example, they can rent luxury apartments, book first-class flights, and attend elite social events. This creates a strong incentive for individuals to continually strive for positive ratings. ✨
Low Ratings = Social Exclusion: People with low ratings (under 3 ⭐) face social ostracism and exclusion. They are denied access to certain services, treated with disdain, and can lose their jobs, housing, or even friends. This drives a constant fear of dropping in social status. 🚩

Behavioral Modification Through Ratings

The rating system in Nosedive creates powerful incentives for people to adjust their behavior, often in artificial or inauthentic ways. People engage in overly polite, agreeable, and upbeat interactions, constantly trying to please others to maintain or improve their ratings. Authenticity and genuine connection takes a backseat to a shroud of perfection.

Politeness and Conformity: The system encourages extreme politeness and conformity because even small, everyday interactions (like ordering coffee or meeting a stranger) are rated. People aim to avoid conflict or any behavior that might offend others, leading to shallow and artificial interactions. Do you think future meaning of AI will be Artificial Interactions?
Social Media Performance: People carefully curate their social media profiles and posts to reflect an idealized version of their lives. The system incentivizes creating a false sense of happiness and success to earn positive ratings. On some level this might even feel relatable in our current society.

Cascading Effects of Low Ratings

Once someone’s rating starts to fall, the system makes it increasingly difficult for them to recover. This cascading effect mirrors the real-world phenomenon of negative feedback loops, where one small mistake leads to more severe consequences.

Instant Demotion in Social Status: In the episode, the protagonist, Lacie, experiences a sudden drop in her rating after a series of negative interactions. As her rating falls, people begin treating her worse, and even minor slip-ups lead to further ratings hits.
Punitive Measures: At one point, Lacie is punished for a public outburst by having her rating severely downgraded, making it even harder for her to participate in society. This punishment creates fear among others, incentivizing them to be even more cautious about their behavior.

The social rating system directly influences economic and social mobility. People with high ratings enjoy better career opportunities, housing, and access to resources, while those with lower ratings are marginalized and often trapped in poverty or undesirable circumstances.

💼 Job Opportunities: Many jobs in the Nosedive universe require a minimum rating. For example, Lacie’s dream is to move into an upscale apartment complex, but she needs a rating of 4.5 or higher to qualify for a discount. This incentivizes her to engage in strategic social interactions and build relationships with high-status individuals to boost her rating.
🏘 Housing & Services: Access to certain housing, transportation, and even healthcare services is based on one’s rating. People with lower ratings find themselves excluded from basic services, motivating them to constantly improve their scores to regain access.

The Incentive Trap

While the system is designed to incentivize “good” behavior and social harmony, it ends up encouraging manipulation, superficiality, and emotional suppression. Instead of fostering genuine connections, it pushes people to prioritize their public image over authentic relationships.

Inauthenticity: People are incentivized to present an idealized version of themselves, even at the cost of their own well-being. Lacie, for example, suppresses her emotions and thoughts to appear perfect, but this leads to a breakdown when her façade starts to crack.
Social Pressure: The constant pressure to perform for others creates a toxic social environment where people are judged solely by their ratings, rather than by their character or contributions.

Systemic Breakdown & Personal Collapse

In the end, the incentive system in Nosedive proves unsustainable. Lacie’s obsession with improving her rating leads to her mental and emotional unraveling. She spirals into desperation, and her inability to conform to the social norms results in her exile from the high-status world she aspired to join.

🏃🏻‍♂️ Escape from the System*.* Ironically, Lacie finds freedom after her rating drops to zero and she’s imprisoned. In a critical moment, she exchanges insults and genuine emotions with another prisoner, highlighting that, outside the rating system, people can express themselves freely and honestly without the pressure of constant judgment.

The incentive system in Black Mirror’s Nosedive illustrates how an over-reliance on ratings, approval, and superficial metrics can distort our behavior and relationships. While it rewards politeness, success, and conformity, it also suppresses individuality, authenticity, and emotional expression. The episode serves as a cautionary tale about how unchecked incentive systems, driven by external validation, can lead to societal and personal dysfunction.

Game Theory

Game theory is the study of strategic interactions between individuals or groups where the outcome for each participant depends not only on their own actions but also on the actions of others. Developed in the mid-20th century by mathematician John von Neumann and economist Oskar Morgenstern, game theory has since become a crucial tool in economics, politics, psychology, and even biology.

🧩 At its core, game theory seeks to understand how rational players make decisions in situations of conflict or cooperation. A key concept is the Nash equilibrium, introduced by John Nash, where no player has an incentive to change their strategy given what others are doing. Other famous models include the Prisoner’s Dilemma, where two players may not cooperate even if it’s in their best interest, and Zero-Sum Games, where one player’s gain is another’s loss.

Game theory helps explain real-world scenarios like negotiations, business competition, public policy, and even social behaviors, offering insights into how people can optimize decisions in complex environments. Game theory provides valuable insights for designing effective incentive systems by analyzing strategic interactions among individuals or groups. When creating an incentive system, it’s crucial to understand how participants will respond to various incentives and the potential outcomes of their choices.

Understanding Strategic Interactions

Incentive systems often involve multiple stakeholders whose decisions affect one another. Game theory helps predict how individuals will behave in response to different incentives. By modeling these interactions, designers can anticipate possible outcomes and create systems that encourage desired behaviors.

Identifying Nash Equilibria

The concept of Nash equilibrium is pivotal in understanding how individuals may settle into stable strategies where no one has an incentive to change their behavior unilaterally. In designing an incentive system, identifying potential Nash equilibria can help ensure that the chosen incentives promote cooperative behavior rather than competitive or counterproductive actions.

For example, in a workplace scenario, if an incentive system rewards individual performance without considering team dynamics, employees may prioritize personal gains over collaborative efforts. Game theory can help designers find equilibrium strategies that foster both individual and collective performance.

Addressing the Prisoner’s Dilemma

The Prisoner’s Dilemma illustrates how rational individuals may not cooperate, even when it’s in their best interest. This dilemma often arises in incentive systems, especially when individual rewards conflict with group goals.

By understanding this dynamic, designers can create incentive structures that encourage collaboration. For instance, implementing team-based bonuses alongside individual rewards can mitigate the risk of individuals acting solely in their self-interest.

Incentives and Information Asymmetry

Game theory also addresses situations where players have different levels of information, leading to information asymmetry. In incentive systems, this can manifest when one party knows more about the task or effort than the other, leading to mistrust or exploitation.

Designers can counteract these issues by ensuring transparency and communication within the incentive system. For example, implementing performance metrics that are visible to all stakeholders can help align interests and build trust, reducing the chances of opportunistic behavior.

Feedback Loops and Dynamic Strategies

Incentive systems often operate in dynamic environments where strategies may evolve over time. Game theory helps analyze feedback loops in these systems, allowing designers to understand how participants’ strategies may change in response to the incentives offered.

By considering potential shifts in behavior, designers can create flexible incentive structures that adapt over time, ensuring they remain effective as circumstances change. For example, introducing periodic reviews or adjusting rewards based on changing goals can maintain participant engagement and motivation.

Balancing Short-Term and Long-Term Goals

Game theory can guide the design of incentive systems that balance short-term and long-term objectives. Participants may focus on immediate rewards at the expense of future benefits, leading to suboptimal outcomes.

Designers can use game-theoretic principles to create incentives that align short-term actions with long-term goals. For example, structuring bonuses to include both immediate rewards and deferred compensation can encourage sustained effort and commitment to the organization’s vision.

Incorporating game theory into the design of incentive systems provides a robust framework for understanding the strategic interactions of participants. By analyzing these dynamics, designers can create more effective and equitable systems that promote cooperation, align individual and group interests, and ultimately drive desired behaviors. The insights from game theory enable organizations to navigate the complexities of our behavior and foster environments where everyone can thrive.

…to be continued.

Reentrancy Attack

2024-07-22T00:00:00Z

Reentrancy attacks are one of the common security issues that can occur in Solidity smart contracts. They exploit the fact that a function can be called multiple times before it finishes execution.
When a contract A calls a function in contract B, contract B can call back into contract A while it is still running. If contract A has not finished executing and is still holding state, contract B can potentially manipulate that state to gain an unfair advantage.
This can lead to various issues such as fund loss, unauthorized access, or even complete contract failure.

The most famous reentrancy attack occurred in 2016, resulting in the loss of 3.6 million Ether and leading to the Ethereum hard fork, creating Ethereum (ETH) and Ethereum Classic (ETC) also known as, The DAO Hack.

WETH Attack: First ever reentrancy attack was reported on Maker DAO Slack. It can tracked on github issue. It was an intentional one and a patch was later merged about it. You can find more details in web archive.

Just in 2021 and 2022 alone, more than a dozen attacks has happened around this. Rari Capital Expoit, Cream Finance, Fei Protocol, Ola Finance, Hyperbears. BurgerSwap, Revest Finance, PolyDex, and so on…

How does it Work

In a typical reentrancy attack, an attacker exploits the way Ethereum handles external calls and the sequence in which state changes and value transfers are performed. Here’s a simplified flow:

Attack Contract Initiation: The attacker deploys a malicious contract.
Initial Call: The attacker triggers a function in the vulnerable contract that sends Ether to the attacker’s contract.
Fallback Function: The attacker’s contract contains a fallback function that calls the vulnerable contract again before the first function call finishes.
Repeated Calls: The process repeats, allowing the attacker to drain funds from the vulnerable contract.

Example of a Vulnerable Contract

Here’s a basic example of a vulnerable Solidity contract:

pragma solidity ^0.8.0;

contract VulnerableContract {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint _amount) public {
        require(balances[msg.sender] >= _amount);
        (bool sent, ) = msg.sender.call{value: _amount}("");
        require(sent, "Failed to send Ether");
        balances[msg.sender] -= _amount;
    }
}

In this contract, the withdraw function updates the user’s balance after sending Ether. This sequence creates a window for a reentrancy attack.

Exploiting the Vulnerability

The attacker’s contract might look like this:

pragma solidity ^0.8.0;

import "./VulnerableContract.sol";

contract AttackContract {
    VulnerableContract public vulnerableContract;

    constructor(address _vulnerableContractAddress) {
        vulnerableContract = VulnerableContract(_vulnerableContractAddress);
    }

    fallback() external payable {
        if (address(vulnerableContract).balance >= 1 ether) {
            vulnerableContract.withdraw(1 ether);
        }
    }

    function attack() public payable {
        vulnerableContract.deposit{value: 1 ether}();
        vulnerableContract.withdraw(1 ether);
    }
}

How to Avoid Reentrancy Attacks

Check-Effects-Interactions Pattern: Ensure all internal state changes occur before external calls. This pattern involves three steps:

Checks: Validate conditions.
Effects: Update internal state.
Interactions: Make external calls.

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    balances[msg.sender] -= _amount;
    (bool sent, ) = msg.sender.call{value: _amount}("");
    require(sent, "Failed to send Ether");
}

Reentrancy Guards: Use the nonReentrant modifier from OpenZeppelin’s ReentrancyGuard contract to prevent reentrant calls.

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureContract is ReentrancyGuard {
    mapping(address => uint) public balances;

    function withdraw(uint _amount) public nonReentrant {
        require(balances[msg.sender] >= _amount);
        balances[msg.sender] -= _amount;
        (bool sent, ) = msg.sender.call{value: _amount}("");
        require(sent, "Failed to send Ether");
    }
}

Avoid call Method: Prefer using transfer and send methods, which have a fixed gas limit and prevent reentrancy attacks. However, be aware of gas limit changes in EIP-1884.

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    balances[msg.sender] -= _amount;
    payable(msg.sender).transfer(_amount);
}

Best Practices

Audit Regularly: Regularly audit smart contracts to identify and mitigate vulnerabilities.
Use Established Libraries: Utilize well-known libraries and packages like OpenZeppelin for security functions.
Test Thoroughly: Conduct extensive testing, including unit tests and fuzz testing, to uncover potential weaknesses.
Limit External Calls: Minimize the number of external calls in your contract, especially those involving value transfers.

On-Chain Shared State

2024-04-26T00:00:00Z

Communication is a key in any ecosystem. Now with more cross-chain communication getting sorted using bridges, it’s high time to sort on-chain communications as well. Particularly, referencing of composable smart contract functionalities within the same chain.

On-Chain Immutability

Blockchains in general are isolated networks. Smart contracts are even further isolated in the network given that they record data that are immutable. Any update to their state records a new transaction cumulatively records the updated state. This is known and also creates a historical trail for later review and audit. There’s no problem is this process expect it’s not possible to update the smart contract code itself.

I’ve always believe learning by example is best. Let’s take a look at the usage of ownerOf from IERC721 interface and how it’s used to check token ownership for any NFT.

First we import via openzepplin package or you can write your own packaged contract import "@openzeppelin/contracts/token/ERC721/ERC721.sol" . Or if you really want to write your own ERC721 contract, start with importing the interface IERC721 to your contract: import "./IERC721.sol" .

The IERC721.sol contains the function definition:

function ownerOf(uint256 tokenId) external view returns (address owner);

And in ERC721.sol you can find the first override for it as such:

function ownerOf(uint256 tokenId) public view virtual override returns (address) {
        address owner = _ownerOf(tokenId);
        require(owner != address(0), "ERC721: invalid token ID");
        return owner;
}

The function in itself is pretty straightforward. It takes tokenId as input and returns the owner address.

To understand this further, it’s all stored in a mapping:

mapping(uint256 => address) private _owners;

Anyway, regardless of the implementation, this is industry standard at the moment. If in case you’d want to add some conditions or enhance this function in your own contract, you’d need to override this further.

Overriden

Say we want to check for temporary ownership, like a rental ownership, which is time bound. We can not edit the original mapping of course. There’s 2 ways:

We add a separate mapping only for the mapping of tokenId and owner to a timestamp.
We ignore _owners mapping and write our own mapping replacing it. We’ll go with this option cause adding and reading from multiple memory storages will be costlier than having a rogue mapping lying around.

Let’s call our new mapping as _ownership:

struct Owner { 
   address account;
   uint256 expiry;
}
mapping(uint256 => Owner) private _ownership;

Now, we can map the ownership in this accordingly. But we also need to override our ownerOf function:

function ownerOf(uint256 tokenId) public view virtual override returns (address, expiry) {
        Owner _owner = _ownership(tokenId);
        require(_owner.account != address(0), "ERC721: invalid token ID");
        require(_owner.expiry > block.timestamp, "Ownership Expired. No current owner found.");
        return _owner.account;
}

Here, we’re doing a few things. First, we’re checking if the owner account exists and expiry is anytime beyond current block timestamp.

Great, now our existing function ownerOf can serve as the modified version of the existing owner check. So, all the clients can now call this new function of contract and get timestamp enabled ownership check.

However, here’s where things get interesting…

Imported Smart Contracts

The problem in above way is that we would need to burn all tokens from old smart contract and re-mint in new one in order for them to enable expiry in ownership. Which would lead to losing all history of the said tokens. So, how do we deal with this?

Solidity supports importing another smart contract and referring to the functions of it as we established above. We usually use it to extend functionality. For example, we want to add a function to our previous contract which checks ownerOf and rewards a certain amount to them. So, we first need to define it:

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

// other code bits

IERC20 token;

// ...

token = IERC20(token_address);

Now, in above, token represents our token from previous contract which is imported based on token_address. So, we should be able to do something like token.ownerOf(tokenId) to get the owner of tokenId as shown above. Once we get it, let’s say we want to do something like owner_address.send(value) where value is in base token of the chain. This is the most commonly used way to use an external contract. But what would happen if you’re to extend an existing function of original contract?

Let’s take our previous example. We want to add expiry to ownerOf. So, we write a new smart contract and a new function to check ownership. Cause we can’t override a function of a different contract. We’ve a new function which can have same name even. But for the sake of sanity, let’s use a different name, newOwner() and it looks something like:



contract RentContract {
    struct Owner { 
       address account;
       uint256 expiry;
    }
    mapping(uint256 => Owner) private _ownership;
    
    function newOwner(uint256 tokenId, address _to, uint256 _expiry) external virtual {
        _ownership[tokenId].account = _to;
        _ownership[tokenId].expiry = _expiry;
    }
    // ...
}

So, what’s happening here is overloading (not really since we’re using a different name for the function. But from a standard perspective, let’s assume it’s the same) which means we’ve defined a second function and mapping to do the exact same thing which is already been done in previous contract where it’s been imported from. This obviously is a waste of memory on-chain but let’s leave that concern for later. So, now, we’ve a second contract, RentContract which has temporary ownership function which we can use. However, what about the client apps which is already pointed to the old contract? The token ownership does not show any changes regardless to whoever else it’s rented out via the RentContract .

Shared State

Here’s where the concept of Shared State comes in. Here’s to proposing a shared state system which allows to update the state of original contract if the same state is being dealt with on an extended contract.

So, once this new system is in place, we should be able to reflect the updated state back to our original state thereby retaining backwards compatibility as well as history.

This is the next evolution in smart contract standards which will help with better backwards compatible DApps and protocols.

LFG

CyberSpace

2023-12-31T00:00:00Z

A world forgotten
Another awoken
Some lost
Some regained

Doesn’t it feel suffocating at times? Like your life isn’t your own anymore. Like everything you’re doing or about to do is pre-determined. Like you’ve already lost before you began.

It’s impossible to make a choice and call it really a choice. Society has decided your past, present, and future. The only way to break free is to dream.

"I have a dream” – Martin Luther King

Freedom doesn’t just have a physical form, but also a mental form. It’s increasingly important to not notice the extent to which the web of media and the internet has bound us to not be able to breathe without an ad popping up offering you a vacation package to clean air. It’s followed by a series of flight ads which specially shows the food you like and the beverage you love. If somehow it detects an inch of interest, you start getting spammed with holiday clothes and even things to do, of course heavily curated to your taste. It’s all great for you. You don’t even have to sit scrolling through search results or ask people around for such things. They already know. Convenience is the new chain to which we’re all bound in by.

Ownership is of course important. But more than that, the creator within you is crying. Crying for not being able to build, do, go what, how and where you want to. Imagine a future version of the world, without any and all mundane tasks around. You just do the most needed work only. Everything else is done by something, someone, somewhere. You don’t care the how, what, or where, till your tasks are been taken care of. So, let’s imagine a future version of the web, that satisfies the above and more, and we call it The CyberSpace.

CyberSpace is a trans-digital world built, governed, and maintained by the collective intelligence of its residents. It’s a space where everything is based on the rules you set. Loosely based on optimistic theory, CyberSpace is what you make of it. It’s not a new world or a virtual world like MetaVerse. CyberSpace is a space where your creations can take shape, form, and act according to how they are programmed.

Not too different from our current world. We live in a universe governed by certain rules as well. So, what’s different? The difference is consciousness. The way we model CyberSpace is upto us.

So, the Mission as it were to build towards such a Utopia. Together. I’m starting this as a mission for everything that I’ll work on now on and till I see it come to reality.
If you want to join me on my journey, reach out to me on twitter or mastodon. Let’s build and live in The CyberSpace.

Building a New World

2022-06-05T00:00:00Z

When we think about building anything, the first thought is about the past builders, whichever industry, domain, or land you’re coming from. From the Roman Colosseum, Great Wall of China, and Taj Mahal of India to building Wikipedia, Reddit, and Google of today, we look up to the past great builders and wonder what it’d take to even come close to what they’ve accomplished. Thinking about building a new World altogether sounds even more daunting. Specially, if you think about who, how, what, and so on the million other questions. In this article, we’ll start by trying to figure out what and why and the how. Of course, it’s not going to be completely covered in one article alone. But, it can be a start.

Introduction

When we think about the end goal, it doesn’t really look a lot different from our current world. With the only differences being in the WHY of our endeavor. What do we want to be different from this world? The negativity, corruption, stealing, terrorism, war are some of the things that comes to mind. We don’t want them in our new world. but how do we get rid of them? That’s in the innate nature of any living being. Left alone in an environment of utter desperation, anybody would succumb to an inch of negativity leading to any number of things from there. How do we remove all need for desperation? Is that even the real answer? Perhaps not. but let’s start there. I love looking into the past to come on to face the future. Let’s think of what the animal kingdom looks like. There are enough natural resources for everyone to feed on. Someone at some point caught off by feeding on another species and thus came to start the very early carnivores. But even so, there’s enough for all the animals to form a healthy thriving ecosystem or the Circle of Life. We often put all the demise of this planet to early humans who started capturing lands and fighting with each other to polluting the very land. Of course, that’s a different topic, but it does bring forth an important question. How do we prevent that in our new world? The answer to me seems either too simple or I’m way off mark. Let’s see where we end up. We know in our heart what’s right. That might not be what others think, but we do believe in something. More often we end up agreeing with others than disagreeing. The smallest number of times we’ve disagreed, it turns out to be a good tussle of learning something new.

Collective Thinking

An interesting experiment done was on the collective thinking of the masses. We usually do not want to put faith in others, specially in the crowd, and for good reasons. but a lot of times it’s just because we can’t trust them. We fear that it’d be almost impossible to make anybody make see the way into your mind, your thought process, your likes, and dislikes and have them take a call on what’s done or to be done be right or wrong. Yes, I’m talking about a legal Jury here. Of course, you’ve all been either seeing or are acquainted with any number of Law related TV series or Movies thereby, if not the real ones, more so lately. An interesting experiment would be that the collective thinking of random strangers can somehow be almost always very right. There are obvious exceptions, but almost always they all point toward what’s right. How does that happen? Very curious indeed. Of course, you need to present them with all the facts to make a sound judgment. Make them see your way into the void and let them come back into the same tunnel that you once emerged out of. If they do, you were right. If they don’t, perhaps you’ve deviated. It’s an interesting theory to test of what’s already passed. But what if we extend this mysterious power of consensus towards what’s about to happen. Let’s ask who everybody the same question and see what they all come up with. On the outside, it might seem like a very random experiment. Too open. Too many answers. Too many possibilities. Too much chaos. But once the dust settles, we’ll find there’s at least 1 answer that more than 1 person has come up with. Very curious!!

A Big Brain

Collective thinking doesn’t mean that we need to connect everyone’s brains with wires and they operate like a big brain. It means that the decisions taken by one can or has to be reciprocated by others to a point of executing it. The decision-making process can be time or resource intensive based on what the impact of it’s will be like. So, each consensus can be varied based upon the collective decision-making prowess of the society in its entirety. This algorithm need not be perfect from the very beginning, but it needs to be ever-evolving according to the need of society and what’s on priority at the moment. Like evolving data, we need our decisions to evolve as well. A great example is music. 300 years earlier, give or take, pretty much everyone were just gasping over Bach and Mozart, amongst the other greats. 50 years earlier, it was the Bettles and Stones and Led Zep to capture all imagination. 20 years earlier, MJ, Nirvana and Chris Cornel and Pearl Jam. Today, it’s someone else. The music as a taste has changed. If you’re from any of the above generations, you’d relate to this. You might not understand of like at all the electronic music of today. Always finding some excuse to go back listening to some classic rock. Of course, if you’re from Mozart era and still alive, I’d be more curious to meet you even with a scared outlook of having my blood or brain dried out. (Just kidding) But of course, you get the idea.

Any governing algorithm needs to be ever evolving.

And that I believe is the first step towards building our new world…

Stay tuned for more…

NFTs in Metaverse

2022-04-17T00:00:00Z

We love NFTs. It’s pretty cool. But we need to look forward to the next step in the evolution of such artefacts. Fine, I’ve a cap NFT or a car NFT. So what? What do I do next with it?

The answer really is just staring at our face. METAVERSE. Not in the sense Facebook wants you to see it. But in a more useful way, the one image drawn from the OG, Neal Stephenson in his book from 1992, Snow Crash.

A world open for everybody to create, build, run with no central authority. Nobody controlling you or pushing you to do one thing or the other. True freedom indeed! Must be nice. Feel like a pirate, aye? If you’re reading this by mid 2022, you are in fact well ahead of most of the human race in working on towards a true Metaverse. Let’s start with what we’ve right now and then slowly move towards how it’s going to impact our world and our Metaverse.

NFTs are non-fungible tokens which are usually tied to some asset, such as an art piece, a user profile, an avatar or a prize. What’s common amongst all of these are that the NFTs are almost always uniquely represented in a single point of truth universal network. Which means, my NFT can NOT be same as yours. I know you’re at this point thinking of 1155s. But even so, they’re collectively representing something unique. We can hold a handful of sand and start separating out the grains or just put them in a bag, and tag them as unique. Coming back to the topic, if we’ve a unique hat as an NFT, then my NFT hat would be very different from yours. I can add some feather on the top or color it white or even tilt it a little to make it as unique as possible. Cause the more rare something is, the more valuable it gets, right? Similarly with any other object, such shirt, tee, trousers, gloves, shoes, and so on…

So, let’s say now, each of us has a unique-looking shoe. We can put these to some use as well. Let’s say I add a condition that each time you enter my store in the Metaverse, your shoe will get cleaned if you buy something from my store. By clean, any previous data diluting its value will be deleted or overridden in some way, since the data we’re working with is pretty much immutable. That’d be pretty cool for you to come purchase a cheesecake from my bakery. Ah, you also get some health tokens for it. Which later you can exchange at the hospital for some avatar upgradation.

I think you get the general idea of it. Every activity has an equally incentivized criteria to it. Compelling every user to participate and work for it. It’s what’s building the proof of work within our digital paradigm.

I’ll be working next on building such a world, a truly free world. If you’re interested in building together, get in touch with me. Help me help us get there…

Until next time…

What is NFT?

2021-09-27T00:00:00Z

NFT or Non-Fungible Token, is the latest in the long line of jargon that you might be hearing a lot about recently. So, why should you care and what is it even? Let’s try to understand the origin and thereby the hype around it.

A digital token is just another piece of a smart contract code that’s running somewhere on a particular blockchain. When cryptocurrency came out and everybody started issuing their tokens, we saw a meteoric rise to Digital Tokens or CryptoCurrencies in the form of ICOs (Initial Coin Offerings) that every other project was really into at the time. Most used CryptoCurrencies came on the more popular decentralised networks like Ethereum, in the form of ERC-20s. This gave a widespread knowledge around what cryptocurrencies are and ERC-20 became a common term to be used in analogous to digital tokens wherever specified. However, several improvements on specific use-cases kept happening over time. These improvements are usually referred to as EIPs(Ethereum Improvement Proposals).

One of the most sought after use-cases was ERC-721 or deeds or as more commonly known as Non-Fungible Tokens. NFTs can represent ownership over digital or physical assets. It’s obviously not a new concept. It’s been around since 2014.

Physical property — houses, unique artwork
Virtual collectables — unique pictures of kittens, collectable cards
“Negative value” assets — loans, burdens, and other responsibilities In general, all houses are distinct and no two kittens are alike. NFTs are distinguishable and you must track the ownership of each one separately.

This by itself doesn’t really mean much but when you really think about it, we already have an extremely large scale demand for such unique items. From collectible cards, items, and luxury antiques, our lives revolve around uniqueness. The more unique an item, the more valuable it becomes. It’s the very core of how our economics work and how every valuable item is identified. Now, with ERC-721, we got a way to represent it online and have a very simple way to buy and sell such assets. Of course, it comes with its own set of problems like enormous gas fees which one has to pay for networks like Ethereum. Makes it almost impossible to acquire one or more of these very special NFTs for normal people. The NFT market value tripled in 2020, reaching more than $250 million. During the first quarter of 2021, NFT sales exceeded $2 billion. Plagiarism is another big concern where a true digital identity solution can very well fix it. We’ll take all the issues and possible solutions in perhaps a separate post of its own. I feel it deserves a more in-depth analysis.

Marketplaces

OpenSea

As one of the most commonly referred NFT marketplaces, OpenSea has established it’s dominance in the space. You can practically buy or sell any type of NFT here. The process is as simplified as it can be.

Binance NFT

Binance NFT Marketplace brings together artists, creators, and crypto enthusiasts on a single platform to create and trade top NFTs. The platform features 3 product lines:

Events: Buy premium and exclusive NFTs created by global leading artists
Marketplace: Mint, purchase, and bid on NFTs from creators around the world
Mystery Box: Stand a chance to win rare NFTs in a box full of surprises

Crypto.com NFT

Rarible

Foundation

SuperRare

Atomic Market

Myth Market

BakerySwap

Axie Marketplace

KnownOrigin

MakersPlace

Solana Art

NBA Top Shot

Async Art

Portion

Enjin Marketplace

BakerySwap

Even traditional art giants like Christies are setting up shop around it can step into the modern age.

Variations

Over time, some variations of ERC-721 have emerged as well.

ERC-1155 which offers semi-fungibility and works over a class of assets instead of particular assets.
FLOW blockchain provides proof-of-stake consensus. Mostly used by NBA Top Shot.
Tezos also works on a proof-of-stake based NFT.
Solana has also started supporting NFTs.

Create your own NFT

A simpler way is to start using one or the platform above mentioned and get started with it. If you want to create your own marketplace or product as such, there’s always a way to do so.

Select a DLT network on which you’d like to issue the NFTs on. Preferably one with less transaction fee.
Write an NFT smart contract or equivalent in that particular network. Here’s a good getting started point are in OpenZepplin Docs.
Make sure there’s an easy interface because mind you, most of your users are really just everyday Joes who just want to purchase as an investment strategy.

So, what all can you use NFTs for?

Art
GIFs
Videos and sports highlights
Collectibles
Virtual avatars and video game skins
Designer sneakers
Music
Tweets
Github Commits

Of course, be wary of where you’re buying these NFTs from. Are they authorised sources or someone broker marketplace who’s just selling via some other marketplace? Are they really the owner or authorised seller of the items. Are they backed by a reputable organisation or foundation? Which blockchain or DLT platform are they using and how much transaction fee is that purchase going to cost you? Also, make sure you’re aware of your country or state’s legalities and taxation procedures. NFTs are also subject to capital gain tax such as any stock you might own.

To Go with Golang

2021-01-26T00:00:00Z

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

At least that’s how the website describes itself. The first time I tried golang was about 3 years ago as a hobby project. However lack of an implementation need and a busy work schedule made my side project obsolete. Of course, you would know what that feels like. Familiar territory. So, when the opportunity rose to write a new service in golang, I absolutely jumped at it.

I’m supposed to build a small web service accepting http connection and storing some data on mongodb. Returns a certain set of result, and so on. Basic CRUD stuff. If you’re not interested in #webdev, I believe this is your stop. If you’re interested however, read on to know about what I used and why. The entire dev cycle from dev to deploy phase.

First of all, why I opted for golang anyway? The service I’m supposed to write needs a highly concurrent persistent api service. It needs to be fast and also easily scalable. We could have gone with python fastapi, but at this stage I just wanted to learn golang.

Setting up Golang

If you’ve finally decided to go ahead with this, let’s do this. Easiest way probably is to just download from the official website and get going. Here’s another article which very nicely explains the setup process. This is ideally for mac OS. In case you’re looking for other OSes, please follow respective guides.

Be sure to setup your GOPATH very properly as this will remain as your common ground for any defined packages installed in your system.

Once done, make sure your console recognises the GOPATH. echo $GOPATH

HTTP Service

I went with fasthttp, which provides high performance, zero memory allocations in hot paths and Up to 10x faster than net/http for a large throughput service. Go provides out of the box http support but for a beginner, it felt much easier to go with a framework, thereby ended up using fiber.

API

Fiber is an Express inspired web framework built on top of Fasthttp, the fastest HTTP engine for Go. Make sure to use Fiber v2. Fiber V2 has a lot of breaking changes to Fiber v1. I had to spend an extra hour just upgrading these breaking changes cause I started with v1.

A simple fiber service can be started using just this:

package main

import "github.com/gofiber/fiber/v2"

func main() {
    app := fiber.New()

    app.Get("/", func(c *fiber.Ctx) error {
        return c.SendString("Hello, World 👋!")
    })

    app.Listen(":3000")
}

You now have a live server running at your http://localhost:3000.

Connect to a DataBase

Next, we need our web service to talk to our web-service. There are quite a few ODM(Object Document Mapper) out there. But given my initial requirement was pretty straightforward, I went the default mongodb golang driver. It’s pretty straightforward to connect an mongodb client:

client, err := mongo.Connect(ctx, options.Client().ApplyURI("mongodb://localhost:27017"))

So, now we got an active db connection going. Ideally, that’s all we would need to create the smallest possible POC(Proof Of Concept) of any web-service you can think of. Obviously, do go through the proper documentation as there are many pitfalls at every stage. Might as well address a few of those on a separate post.

However, to make a production level POC, we need a few more stuff. So, let’s discover a few add-ons to our service:

Logging

Logging is one of the most important aspects in any programming. To see what’s working and where has been the crux of any development really. We sometimes debug using our logs. Specially in production. The easiest and in-built way of printing/logging can be done using fmt or log packages. A small example:

fmt.Print("Printing with fmt")

buf    bytes.Buffer
logger = log.New(&buf, "logger: ", log.Lshortfile)
logger.Printf("Logging with log")

The use log is highly encouraged as compared to fmt. Log is thread safe where as fmt is not. A Logger can be used simultaneously from multiple goroutines; it guarantees to serialize access to the Writer.

log.Fatalf("Fatal err happened:", err)

You can also add fatal logs if in case you would want to flag certain types of logs which might be critical to the application.

Some added advantages of using Fiber is it’s logging module. If you’re on v1, you would need to install the logger package separately, but in v2 it has been made available within v2 itself: "github.com/gofiber/fiber/v2/middleware/logger".

If you need to log each request as and when it comes in, you can add something like this:

app.Use(requestid.New())

app.Use(logger.New(logger.Config{
	// For more options, see the Config section
  Format: "${pid} ${locals:requestid} ${status} - ${method} ${path}\n",
}))

Now, each route visited will come up on your console.

Hot Reloading

Golang is a compiled language, which means unlike Python or NodeJS which are interpreted languages, we need to build it everytime we would want to run it. Ideally we build the project as such: go build . And then we run it like: ./app-name.

However, we can still run the dev version as: go run main.go Or if there’s more than one file: go run *.go

But while development process, we often make changes and would want to check the output without having to restart the go server manually. You can obviously write your own small shell script to detect any file changes on the entire directory and restart go run everytime. If you’re using docker, you can also write the entire go build . and ./app-name process inside the container.

Needed a more robust way, which is provided by this package called fresh. Fresh is a command line tool that builds and (re)starts your web application everytime you save a Go or template file. You can also customise the log color that comes with the default fresh setup. It requires a default runner.conf file. If you want to go with the default options, you don’t even need this file on your project root.

root: . tmp_path: ./tmp build_name: runner-build build_log: runner-build-errors.log valid_ext: .go, .tpl, .tmpl, .html no_rebuild_ext: .tpl, .tmpl, .html ignored: assets, tmp build_delay: 600 colors: 1 log_color_main: cyan log_color_build: yellow log_color_runner: green log_color_watcher: magenta log_color_app: blue

Now we’ve a complete dev setup done and dusted.

Routing

I’m obsessed with structured code. Everything can be written in a single file and ran but a structured codebase, makes it all the more easier to document, read and later manage it. Thereby, routing is a crucial part of adopting a new framework. Fiber comes with inbuilt route grouping

func main() {
    app := fiber.New()

    api := app.Group("/api", middleware) // /api

    v1 := api.Group("/v1", middleware)   // /api/v1
    v1.Get("/list", handler)             // /api/v1/list
    v1.Get("/user", handler)             // /api/v1/user

    v2 := api.Group("/v2", middleware)   // /api/v2
    v2.Get("/list", handler)             // /api/v2/list
    v2.Get("/user", handler)             // /api/v2/user

    app.Listen(":3000")
}

This can help you in writing a more structured app as such you might need to authenticate only a particular group or log a particular route and so on.

Deployment

Probably best to go with a containerised deployment. We have deployed on Kubernetes - Google Kubernetes Engine (GKE) which only needs an additional Dockerfile.

It’s better to go with a multi-stage docker setup:

FROM golang:1.12-alpine AS build_base

RUN apk add --no-cache git

# Set the Current Working Directory inside the container
WORKDIR /tmp/go-sample-app

# We want to populate the module cache based on the go.{mod,sum} files.
COPY go.mod .
COPY go.sum .

RUN go mod download

COPY . .

# Unit tests
RUN CGO_ENABLED=0 go test -v

# Build the Go app
RUN go build -o ./out/go-sample-app .

# Start fresh from a smaller image
FROM alpine:3.9
RUN apk add ca-certificates

COPY --from=build_base /tmp/go-sample-app/out/go-sample-app /app/go-sample-app

# This container exposes port 8080 to the outside world
EXPOSE 8080

# Run the binary program produced by `go install`
CMD ["/app/go-sample-app"]

A complete guide on dockerising your golang app can be found here and here.

With this we’ve now a deployed version of our golang app. Connect that gke ip to your preferred DNS provider and share the link. Feel free to leave a link of you first golang app in the comments. Would love to see what everyone is working on.

If you have a different view on some of the stack used or talked here, feel free to add your thoughts. We’re all learning and would love to see the more popular frameworks and best practices in use.

Cheers and until next time…

The Code of Libraries

2020-08-04T00:00:00Z

How many times have you found yourself in the middle of your project, had to stop and switch to a different library, all because it didn’t support a simple feature? How many of those times you wondered if you knew which library to use to get going? You did nothing wrong. You chose the first result that came up on google or your package manager’s recommended website. It obviously showed a very download rate and popular usage. But even so, more times than less, we tend to miss a key factor or two which can lead us to go back and check out a different package. Sometimes it leads you to lose interest in the working project, or find yourself trying to fix the library which might increase your development time.

It really is frustrating at times, isn’t it? Considering being in a similar situation more times than I would care to admit, I tried to devise a few guidelines to follow while selecting the right library to use, which let’s call as The Code of Libraries.

Source Code

This should be pretty obvious. Find that source code of your library and go through the code. No need to get overwhelmed and no need to obviously go through the entire source code. Just enough to make to sure that there’s at least some code written on it. It might just be a fully updated package every few months and has no code whatsoever written inside. Even better if the library has tests written which you can run preferably in interactive or verbose mode to go through the output as it happens.

Stars/Forks/Watchers

A quick look at the stars any project has got can provide a good idea of the popularity and validation for the project. Forks would showcase of how many people are interested in contributing or working on the project, which would also mean it’ll be that easier to get support for the project.

Version

Trust in experience. Always take into consideration going for libraries with releases before their own v1.0.0. They’re probably still testing it out themselves. Obviously, they would put up a flag on their readme file as to Under Development or something similar, but they also might not have. So, it’s obviously upto you to cross-check. Make sure to also check previous versions. It might so happen that someone’s first release is starting from v1.0.0. On the other hand check the versions previous to it. A very good possibility that on every spelling fix, the maintainers were pushing a separate release and now the poor library is left with v24.12.142 and really it’s just printing Hello World on the console.

Downloads

Pretty obvious when you think about it. Always check the number of downloads the library is getting on a weekly or monthly basis. Often times than more, the libraries get downloaded by thousands of mirroring bots to private data centres for analysis and storage. So, although most of those numbers might be way higher than actual users downloading that particular library. But also the mirroring bots are active more frequent on the more user downloaded libraries.

Used By

This is one of the best features Github rolled up recently. Touchdown Github! This particular feature provides a pretty comprehensive list on how many people are using the project. Check out the dependants of python flask project. If the codebase is on GitHub, definitely this adds more credibility to the project than anything else. To be sure, just browse through randomly some of those projects to get an idea what they are being used for and how’s their work going along. It might so happen that the library was popular before and used a lot by a lot of projects but now not so much, due to either a better updated library available or the technology itself being outdated.

Last Updated

Find the repo link. Check for when the last push to the codebase was. It’s a statistically safe bet if the library had code pushes in anywhere within last 2–4 months. Anything more than 6 months is not to be trusted. Specially for languages like nodejs and gaoling where the language releases are very often within months. For languages which doesn’t have that fast releases like python or ruby, upto 6 months still is okay. We’ve used packages from 3 years ago and still works great. And also packages that went on update last month is still some vulnerable dependencies.

Release Cycle

Alongside last updated, release cycles are very important. You might find this a vague criteria, but for packages which are being released every week, if they suddenly stop releases, it’s either the maintainers have dumped this project or have some issues that they can’t fix yet. An instance might be when last updated date is 3 months ago but it used to have steady releases every week. By their own timeline, they would have missed close to 14 cycles. That never looks good. Trust us.

Issue/Bug List

A very important criteria to meet is to check for open issues on the repo. And if any of those issues are very old pending. Look more closely as to when were last updated in comments as such. Also, if there’s any critical bug pending in open issues. Sometimes this might be a make or break moment. A package might be not maintained as much but the maintainers might still be answering questions on issues raised and closing them or redirecting to another working library. While you’re at it, take a quick peek on closed issues as well to make sure the project maintainers aren’t just closing issues so they won’t stay on the open issues and make themselves look bad.

Dependencies

Check the codebase and go through it thoroughly for all dependency that your desired package is facing up. Even better if the project has integrated code coverage, dependency checker or other such tools. They’re free to use and you should definitely use them to your advantage. Your library might be very well maintained but some dependency that it’s relying on might have been outdated and not-maintained anymore. It’s a big disaster in that case. Switch to some other library immediately.

Community Response

Finally, check for the official communitcation channel or q/a forums used by the respective community. It might be on irc, gitter, slack, discord, rocketchat or some equivalent communication channel but this will give a great idea of the typeof discussions happening at the project level and if the project is inherently active.

So, there you have it. Now, repeat: I solemly swear to abide by The Code of Libraries for my all future projects.

Some Popular Tools

The Ruby community came up with an online tool to compare projects called Ruby Toolbox. It’s brilliant and provides a pretty comprehensive comparision to make your job easier.

Libraries.io helps you find new open source packages, modules and frameworks and keep track of ones you depend upon.

Now, sometimes even after following Polyglot’s Code of the Libraries, you might get stuck into such scenarios where you need to take care of a dependency of a dependency of your project. You might imagine yourself spending too much time fixing up the library. Polyglot is a community of developers driving an open source software agency to help you get out of such a mess. Get in touch with Polyglot Network at team@polyglot.network and let them take care of that open source library for you.

Data Currency and Technology

2018-04-22T00:00:00Z

Three words that is in everything and everywhere. The very essence of an object, be it physical or digital is encompassed within the realms of these 3 words. However, there is such distinction amongst the words that we often do not relate to them as the one single entity or even closely linked to each other. Today, we’ll try to find out if that’s true.

A most widely generic definition can be:

Any piece of information, however small or intricate, vague or clear, story or not, if given a proper structure and category that be meaningful in one way or other to oneself, can be termed as data.

So, in a way any piece of information can be termed as data. Interesting! I never knew that me, eating an apple instead of banana can be a meaningful piece of information to be classified as data. But it actually is. To the right person, in the right hands, any piece of information that they can monetise on is actually data. How, do you ask? Well, if an apple selling store knew about this, they would know that I prefer apple over banana and they would then try to sell more apples or other product of apples, perhaps Apple Juice or something. On the contrary if a banana store came around it, they would probably ask me what’s wrong and try to fix it so as to not lose a potential customer.

Of course, for as small a data set as a single person, nobody would bother. But say that data isn’t just of mine. It’s of thousands of people in the same neighbourhood. Then, it might catch their eye and they would react. Cause then they would need this data to get their business running. And they would be willing to pay to get such data. Maybe pay 1% of their rest 99% in profit from targeted marketing and sales. Believe me, it is already a thing. Which links to my next point: Currency.

Who doesn’t know what currency is? But do we really understand it? We take a dollar or rupee bill, and think it holds some value when actually, it doesn’t. If it’s unregistered, somewhere or other it’s not a legal form of currency note. Some bank or institution has to maintain a clear ledger of data as to where that particular note went through to reach your hands. If they do, that note is valid. Otherwise, it becomes something we term as black money and liable to get yourself a heavy charge for carrying illegal money. But, banking ledgers being controlled at a particular location or set defined books became easy to access or manipulate. One could copy all of the books and in process, insert their data in between the rest, which could eventually make their money legal. Eventually, the banks got smarter. They moved from books to storage devices and softwares. But now, it became even easier to randomly insert data. And copy data into new data. Now, the struggle only remained as a tug of war between who knew more technology to get ahead of the other.

Technology really just means the science of craft. But we’ve taken it so closely to gadgets, that for us, technology merely means catching a Pokemon with a ball by swiping up, in our phone. Well, technically, it ain’t wrong. Just incomplete. We live in a world surrounded by gadgets and apps. Alexa, Uber, Instagram, WhatsApp, Facebook, Twitter, Google Home, even cars now, Tesla. How can the meaning not change. Technological advancements has been tremendous in the last few years. Technology has influenced every part of our lives. From managing data to transferring currency. We don’t go to the banks anymore to fill out a form and transfer money. We just use Paypal or Paytm. Excel sheets have paved ways to databases, and then distributed databases to enhance the further security and accessibility of data. Yes, the social websites that we visit to do give us a lot of exposure. But they also clearly sell out your data to potential buyers. Data encourages currency. But technology really is the one that supports it. But the more important question is, do you really care? If you did, you would lived a monk life so far. But you don’t. You want people to show you ads of that camera, that you viewed a hundred times but can’t afford. If there’s ever an offer or better price somewhere else or newer bran, you’ll come to know about it. Isn’t that great? Of course it is. You may cower that you might not want to know about some other related item which even might get inappropriate sometime and I totally agree to it. But how will the systems learn and adapt to your needs and requirements if they are fed in with huge amounts of data on the same. Are they really breaching our privacy? Do we really need to shut them down. After-all, it’s our inability to read through the lengthy agreements of usage. We are in so hurry to get on-board the show, that we are ready to give it all up.

Being said that, obviously we would want a control over own data. Not all of us want to know the nearest restaurant or asked to check-in every time we are near one. And I totally am on the same page with that as well. We must have control over our data. But at the same time be aware of the advantages that data can bring to us. Technology as helped us use our data in the form of currency today. There are various data marketplaces even, where companies buy and sell data legally. You can also utilise such marketplaces to monetise your data, the way you would want it to be used.

Put up your thoughts as to what you think the world should move on to the next phase of data privacy and sharing. Is it ok to come up on WikiLeaks and not on google or do we really want the control and are willing to spend time and give up the online social life to get free of that.

Originally posted on Medium

Intro To Blockchain

2017-04-16T00:00:00Z

The first time I heard of blockchain was by being the distributed ledger that bitcoin uses. And I’m sure so have many of you, maybe still you believe the same. So, let’s take a trip down the years of how blockchain came to be and what it can be potentially.

Origin

Satoshi Nakamoto was the inventor of the bitcoin protocol, publishing a paper via the Cryptography Mailing List in November 2008. He then released the first version of the bitcoin software client in 2009, and participated with others on the project via mailing lists, until he finally began to fade from the community toward the end of 2010. Nakamoto worked with people on the open-source team, but took care never to reveal anything personal about himself, and the last anyone heard from him was in the spring of 2011, when he said that he had “moved on to other things”. As of 2 February 2017, Nakamoto is believed to own up to roughly one million bitcoins,3 with a value estimated at over US$1.1 billion.

Bitcoin

Bitcoin is a digital currency and a public ledger. Often the ledger is itself mistook to be what blockchain is. That’s not entirely true. Bitcoin as a ledger is a type of blockchain. Blockchain as a whole is the technology underlying bitcoin.

“[Blockchain] is to Bitcoin, what the internet is to email. A big electronic system, on top of which you can build applications. Currency is just one.” — Sally Davies, FT Technology Reporter

So, let’s move on to what blockchain is.

Blockchain

Blockchain by definition is an open transparent distributed ledger. That’s it. Nothing more. Nothing less. But you still feel confused. Let me explain what that definition means.

Here’s what Vitalik Buterin, the co-founder of Ethereum(An open-source, public, blockchain-based distributed computing platform featuring smart contract (scripting) functionality) and the co-founder of Bitcoin Magazine says:

“A blockchain is a magic computer that anyone can upload programs to and leave the programs to self-execute, where the current and all previous states of every program are always publicly visible, and which carries a very strong crypto economically secured guarantee that programs running on the chain will continue to execute in exactly the way that the blockchain protocol specifies.” — Vitalik Buterin

Still not too clear? How about we take a look at how the World Economic Forum describes it with this video right here:

Makes a little more sense. Deloitte explains blockchain something like this:

You (a “node”) have a file of transactions on your computer (a “ledger”). Two government accountants (let’s call them “miners”) have the same file on theirs (so it’s “distributed”). As you make a transaction, your computer sends an e-mail to each accountant to inform them. Each accountant rushes to be the first to check whether you can afford it (and be paid their salary “Bitcoins”). The first to check and validate hits “REPLY ALL”, attaching their logic for verifying the transaction (“Proof of Work”). If the other accountant agrees, everyone updates their file… This concept is enabled by “Blockchain” technology.

A pretty decent overview of the system. You must by now have a clear picture of what the blockchain is and can be turned into.

Applicaitons

The world has already started reacting to this massive revolution.

Honduras government has put all land records on a public ledger - the blockchain. The minute there is a change in ownership, it gets recorded publicly.

The Australian Securities Exchange (ASX) announced that it would move Australia’s equities clearing and settlement system on to blockchain.

Nasdaq unveiled Linq, a solution enabling private companies to digitally represent share ownership using blockchain-based technology.

ICICI Bank executes India’s first banking transactions on blockchain in partnership with Emirates NBD. Undertakes pilot transactions in international trade finance and remittance on blockchain.

Ascribe lets artist themselves upload digital art, watermark it as the definitive version, and transfer it.

And these are just a few examples of the many applications and areas blockchain is expanding it’s reach to.

Future

Blockchain is creating a biggest shift in paradigm the world has seen yet, since the days of world wide web. And it’s here to create the revolution that will blow your mind.

Don Tapscott, the author of many business and economics books and also the lead author of Blockchain Revolution, says:

“The technology likely to have the greatest impact on the next few decades has arrived. And it’s not social media. It’s not big data. It’s not robotics. It’s not even AI. You’ll be surprised to learn that it’s the underlying technology of digital currencies like Bitcoin. It’s called the blockchain.” — Don Tapscott

Needless to say what the future holds for blockchain and the huge potential blockchain can bring in to the current world. We get not just to witness a revolution, but also be a part of it.

Consensus Decision Making

2017-02-18T00:00:00Z

Introduction to Decision Making

In psychology, decision-making is regarded as the cognitive process resulting in the selection of a belief or a course of action among several alternative possibilities. Human performance with regard to decisions has been the subject of active research from several perspectives:

Psychological: examining individual decisions in the context of a set of needs, preferences and values the individual has or seeks.
Cognitive: the decision-making process regarded as a continuous process integrated in the interaction with the environment.
Normative: the analysis of individual decisions concerned with the logic of decision-making, or communicative rationality, and the invariant choice it leads to.

Decision-making techniques

Decision-making techniques can be separated into two broad categories:

Group decision-making techniques and individual decision-making techniques.
Individual decision-making techniques can also often be applied by a group.

Consensus decision-making

Consensus decision-making is a group decision-making process in which group members develop, and agree to support a decision in the best interest of the whole. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the “favourite” of each individual. It is a creative and dynamic way of reaching agreement between all members of a group. Instead of simply voting for an item and having the majority of the group getting their way, a group using consensus is committed to finding solutions that everyone actively supports, or at least can live with. The input and ideas of all participants are gathered and synthesised to arrive at a final decision acceptable to all. Through consensus, we are not only working to achieve better solutions, but also to promote the growth of community and trust.

Giving consent does not necessarily mean that the proposal being considered is one’s first choice. Group members can vote their consent to a proposal because they choose to cooperate with the direction of the group, rather than insist on their personal preference. Sometimes the vote on a proposal is framed, “Is this proposal something you can live with?” This relaxed threshold for a yes vote can achieve full consent. This full consent, however, does not mean that everyone is in full agreement. Consent must be 'genuine and cannot be obtained by force, duress or fraud. The values of consensus are also not realized if “consent” is given because participants are frustrated with the process and wanting to move on.

Sociocracy

It furthermore paved way to a system of governance using consent decision making and an organisational structure based on cybernetic principles, i.e. a transdisciplinary approach for exploring regulatory systems—their structures, constraints, and possibilities… It was called Sociocracy. Sociocracy makes a distinction between “consent” and “consensus” in order to emphasize that circle decisions are not expected to produce “a consensus”. It doesn’t mean agreement or solidarity. In sociocracy consent is defined as “no objections,” and objections are based on one’s ability to work toward the aims of the organisation. Sociocratisch Centrum co-founder Reijmer has summarised the difference as follows: "By consensus, I must convince you that I am in the right; by consent, you ask whether you can live with the decision.”

Consensus Decision Making in Making of a Start-Up

By now, you must have had a pretty decent understanding on the clarity that consensus decision making can provide us and the advantages of it in a small company or a startup where a few people have to sit-tight in a room and decide over what business model they should go with. Let’s go over a model from the emergence of a startup:

Introduce and clarify the issue to be decided.
Explore the issue with your group and look for ideas amongst peers or partners or close friends.
Look for emerging proposal. Sometimes this phase also results in a completely different idea than what was to be decided at all, which is turn deviates a startup from one business model to the next also known as pivot of idea.
Discuss, clarify and amend your proposal.
Test for agreements. Check for blocks, reservations, resolve them if needed and then it’s all good to proceed.
Finally, implement the decision.

Quick Decision Making

However, consensus decision making process can be sometimes slower and we are in a cut throat world where multiple issues require our quick attention. In quick consensus we are cutting short the discussion part and paring it down to just one workable proposal with amendments. This is because you are aiming to make the best decision in the time you have. However, this model of decision making needs lots of practice in advance. If you want to use this process, you’ll need to discuss in advance the situations when you’ll use it, and take time to explore the issues involved. That way you’ll already know what people’s concerns and reactions might be when confronted with the situation. In effect, this is like having the discussion stage of the consensus process in advance, which will allow you to jump straight to the proposal stage in an urgent situation.

What about on scale?

We have by now come across multiple models to facilitate consensus decision making in small team or group. But what larger groups? Do we fall back to our democracy system and rely on voting? Well, not really. It’s more challenging to get an unanimous decision in such large group but nonetheless if and when achieved is inspiring in it’s own self. The six steps for reaching consensus are the same as for small groups, but some steps may happen with everyone together and other steps may happen in small groups to enable in-depth discussion and participation.

Delegation: Avoiding micro-management is the key while delegating decisions, where the whole group decides in fine detail what needs to be done.
Large plenaries: The whole group comes together in one place, can be used to share information, to make proposals and for final decision making.
Working in small groups: People will be much more comfortable talking openly in a small group of 6-15 people. Working in small groups and teams also saves time. In every organisation the teams are formed for the same reason.
The spokes-council: Obviously after all that, given the huge size of group, someone has to sit and pass on the judgement and decide over convincing a team to another and make everyone reach one decision.

Consensus is about co-operating to find solutions and not competing. An extremely effective decision making process which has advantages beyond expectations and I personally feel every organisation should adhere part of it or completely to it.

AniLog

Writing Your Own Claude Plugin and Shipping it to the World

What even is a Claude plugin? #

Lets get started #

The Manifest #

The Skill #

Testing #

Validating Skills #

From inside Claude Code (via pi) #

In CI #

Ready to publish #

Meet AgentHub #

Distribute your plugin #

Listing on AgentHub #

Into the wild #

Using Plugin #

Shipping Updates #

A few things I learned the hard way #

References #

N Reviewers Walk Into a PR...

A Story You’ve Lived #

The Tools Available (And Why They Fall Short) #

Enter: PR Reviewer Labeler #

Zero-Config Setup (Seriously, It’s This Easy) #

Your Team, Your Rules #

Not All Lines Are Born Equal #

What Happens Under the Hood #

Wire It Into Your Workflow #

Best Friends With actions/labeler #

The Roadmap (a.k.a. “I Have Ideas”) #

CODEOWNERS Integration #

Complexity Scoring #

Auto-Request Reviewers #

Software Without Pause

The Rulebook That Got Us Here #

A Pattern We’ve Seen Before #

When Intelligence Became a Primitive #

The Old Guard vs. The New Movement #

The New Economics #

The Recursive Engine #

Rethinking the Fundamentals #

Getting Ahead of the Curve #

The Missing Playbook for AI Agents

The Core Parallel #

Designing an Agent = Designing a System #

1. Goal clarity: single-shot vs multi-step #

2. Control style: how much autonomy does the LLM get? #

3. Tool surface area: narrow vs wide #

The Architecture Shift #

Building the Agent #

The Minimal Agent Loop #

Start Small, Then Expand #

Skills: The Building Blocks #

Frameworks and When to Use Them #

Testing Agents: The Missing Discipline #

The Agent Testing Stack #

Evaluating Trajectories, Not Just Outputs #

The Eval Mindset #

Running Agents #

Runtime Patterns #

Failure Modes You Must Handle #

Making It Real #

Cost #

Latency #

Observability #

Memory: The State Management Problem #

Context Management #

Sliding window #

Summarization #

Selective injection #

Structured context #

Distribution #

Putting It All Together #

Design Phase #

Implementation #

Testing #

Where People Mess Up #

Takeaways #

References & Further Reading #

Skills, Agents, and the Missing Middle

What even is a Claude plugin?

Lets get started

The Manifest

The Skill

Testing

Validating Skills

From inside Claude Code (via pi)

In CI

Ready to publish

Meet AgentHub

Distribute your plugin

Listing on AgentHub

Into the wild

Using Plugin

Shipping Updates

A few things I learned the hard way

References

A Story You’ve Lived

The Tools Available (And Why They Fall Short)

Enter: PR Reviewer Labeler

Zero-Config Setup (Seriously, It’s This Easy)

Your Team, Your Rules

Not All Lines Are Born Equal

What Happens Under the Hood

Wire It Into Your Workflow

Best Friends With actions/labeler

The Roadmap (a.k.a. “I Have Ideas”)

CODEOWNERS Integration

Complexity Scoring

Auto-Request Reviewers

The Rulebook That Got Us Here

A Pattern We’ve Seen Before

When Intelligence Became a Primitive

The Old Guard vs. The New Movement

The New Economics

The Recursive Engine

Rethinking the Fundamentals

Getting Ahead of the Curve

The Core Parallel

Designing an Agent = Designing a System

1. Goal clarity: single-shot vs multi-step

2. Control style: how much autonomy does the LLM get?

3. Tool surface area: narrow vs wide

The Architecture Shift

Building the Agent

The Minimal Agent Loop

Start Small, Then Expand

Skills: The Building Blocks

Frameworks and When to Use Them

Testing Agents: The Missing Discipline

The Agent Testing Stack

Evaluating Trajectories, Not Just Outputs

The Eval Mindset

Running Agents

Runtime Patterns

Failure Modes You Must Handle

Making It Real

Cost

Latency

Observability

Memory: The State Management Problem

Context Management

Sliding window

Summarization

Selective injection

Structured context

Distribution

Putting It All Together

Design Phase

Implementation

Testing

Where People Mess Up

Takeaways

References & Further Reading

What We Actually Mean by “Skills”

Introducing Sutras

What’s Next

Our Journey: Building a Trustworthy Summarization Tool

Run in Google Colab

🏠 Run Locally