DEV Community: calleb

Ontribe: A Protocol for Onchain Reputation in the Age of Trustless Identity

calleb — Fri, 13 Jun 2025 07:26:20 +0000

The internet gave us freedom.
Web3 gives us ownership.
But without reputation, ownership is shallow — and trust doesn’t scale.

Ontribe is a protocol for onchain reputation — composable, verifiable, and community-owned.
It helps you prove who you are through what you’ve done — without doxxing, vanity metrics, or centralized gatekeepers.

Because in a network society, your signal is your social capital.

And now, Ontribe is going live — natively on Base, integrated into the Bankr ecosystem for real-time, trust-based coordination.

🧩 What is Ontribe?
Ontribe transforms scattered actions into structured identity.
Not with static bios, but through provable contributions.

It’s a protocol for:

Verifying onchain & offchain activity
Building portable, multi-wallet identities
Curating reputational “karma” from real contributions
Filtering signal from noise in open, trustless systems

Imagine a passport for your Web3 presence — not just what you hold, but what you’ve backed, built, or contributed to.

🌐 Why Base + Bankr?
Bankr gives Ontribe a native interface for crypto-native interactions — social, seamless, and programmable. Base provides fast, low-cost infra optimized for onchain activity at scale.

With Bankr, users can:

Trade, tip, and trigger onchain actions via X or Warpcast
Launch tokens and missions via messages
Sync reputation from liquidity, tipping, trading, and social actions

Ontribe will use Bankr to:

Capture onchain + social actions as reputation signals
Score karma from verified posts, swaps, tips, and token launches
Enable trust-weighted access, voting, and onchain roles
Launch community quests that reward real participation

It’s not about who tweets the loudest —
but who builds signal through action.

⚙ Key Features

🔗 Ontribe ID
A dynamic, NFT-based reputation passport. Composable. Portable. Yours.

📊 Reputation Karma
Earned from governance, contribution, tipping, and engagement. Transparent & weighted.

🌐 Cross-Chain Signals
Aggregate signals from Base, EVM chains, and offchain sources.

🛡 Privacy by Design
zk-enabled proofing: verifiable without revealing identity.

🎯 Use Cases

Airdrop gating based on contribution, not click farms
Community voting weighted by trust
Talent discovery in DAOs & social teams
Role access based on karma & skill reputation

🧬 Why Now?
Web3 is scaling. So are bots.
Content is easy. Signal is rare.
And trust is still being built from scratch every time.

We need a protocol that makes reputation portable, provable, and programmable.

Ontribe is that layer.
It’s not about status — it’s about verified signal from real humans, doing real work.

🛠 What’s Coming
The MVP will launch inside the Bankr ecosystem, built on Base.

Early users will be able to:

Mint their Ontribe ID

Link multiple wallets + social accounts

Earn Karma through posts, tips, swaps, token launches, and missions

Join exclusive drops and gated threads

Visualize trust-based networks across Bankr and beyond

Want early access? ontribe.io

🚨 TL;DR
Ontribe = a protocol for onchain reputation
Built on Base, powered by Bankr
Reputation = identity you own, signal you earn
Trust becomes portable, programmable, and composable
Made for contributors, not influencers

Ontribe
Built for contribution.
Backed by reputation.
Owned by communities.

—
Crafted with intention by @callebknox
For those who believe trust should scale with contribution

Let's build an Agentic Trading System. Together

calleb — Fri, 13 Jun 2025 03:39:17 +0000

My role?
Basically building mathematical models to estimate market risk for all financial derivatives at one of the largest European banks.

Was it fun?
Yes, of course! It was my dream job back then (the fact that it was the first job out of Maths school probably helped).

I used to spend my days fitting statistical models to price and hedge financial derivatives, way before Machine Learning was cool.

It was all about MATLAB (not my cup of tea, but my best friend at the time. Is that too sad? xD).

Apart from maths and MATLAB, a big part of my job was talking to traders, the guys at the bank that were using these models to make trading decisions that fit their (and the bank's) risk appetite.

Then something happened
I entered a trading floor for the first time in my life, and I got a glimpse of what actual trading looks like.

Bloomberg terminals, fax machines, phone booths.

Risk management, portfolio construction, and of course trading.

One of the things that caught my attention, was the amount of screens showing Bloomberg news 24/7.

Traders would constantly have one eye on their Bloomberg terminal, and the other on Bloomberg news.

Why?
Because they knew that some news can really move the market.

So they wanted to be the first to know, take action and profit.

Back then there was no such thing as Large Language Models. But there were a lot of smart tricks to extract sentiment from news.

Simple regular expressions, helped quant traders build C++ functions running on Bloomberg terminals, generating numeric scores for potential market moves.

These inputs were then used to make trading decisions (by traders), that had to be approved by risk management.

That was the Prehistory of Natural Language Processing.

Fast forward 13 years….

Sentiment analysis is a solved problem in 2025
Large Language Models are universal functions that can map any given text to any structured output you want.

For example, map a piece of market news to a JSON formatted list of sentiment scores.

Of course, you need to wrestle a bit with your prompts to get there.

And this is something I want to quickly show you if you have 5 minutes. Do you?

A 5-minutes straight-to-the-point prompt engineering example
All the source code I am showing you here is in this repo I put together.

Link to the repo

We will be using [BAML](https://github.com/BoundaryML/baml) (Basically a Made up Language) to ensure our LLM generates the type of structured output we want.

Why BAML?

I personally prefer BAML to all-in-one frameworks like LangChain, as it makes fast prompt experimentation (the key to success for 99% of LLM problems) easier.

I also strongly recommend you use uv to package your project.

curl -LsSf https://astral.sh/uv/install.sh | sh
For example, to create the project structure you just need to run:

uv init crypto-sentiment-parser
Nice, let's now install the BAML client and the BAML cli.

uv add baml-py
To generate some boilerplate BAML code under baml_src run:

uv run baml-cli init
From these *.baml typed files, you can generate the equivalent Python code with:

uv run baml-cli generate
And here is where the magic starts to happen → In the BAML language a prompt is a function with strict types.

You define your types in BAML

class CryptoSentiment {
coin Coin
score Score
reason string
}

enum Coin {
Bitcoin
Ethereum
}

enum Score {
Positive @description("Positive sentiment")
Negative @description("Negative sentiment")
Neutral @description("Neutral sentiment")
}
and from there, you prompt becomes a typed function. Genius.

For example, here is our ExtractCryptoSentiment function, that maps a string to a list of CryptoSentiment objects.

From here, the BAML client will generate the Python code for you and put it in the baml_client folder.

So, whenever you need to invoke this very simple sentiment extraction agent, you just need to use a super simple function like this:

If you want to play around, check out this repository I put together. Feel free to adjust the code to your own needs.

So what now?
Building a sentiment extraction parser like we just did is very cool and all that.
But this is just one piece of the trading puzzle.

Trading in the real world takes more than that. WAY more.

Trading smartly is all about:

Finding a good trading idea

Testing with hard data if this idea is really a good idea

Executing the idea

So, the question that I kept asking myself last week was

Can we take things to the next level, and build not only a single news sentiment service, but a semi-autonomous fleet of agents that can find, test and execute trading strategies as the human traders I met 13 years ago did?

And you know what?

I think WE can.

And I say WE, because I want you to join me in this journey.

Agent architectures that scale

calleb — Thu, 12 Jun 2025 15:06:58 +0000

These past 4 weeks I have talked to several companies, who want to develop some sort of agentic platform.

They are all in the same situation.

They managed to build a Proof Of Concept, for their business case, using third-party services (like OpenAI API) and duck-taped Python scripts

For example
An agent demo to automate customer support workflows in a gaming company, built as a single Python Langgraph flow running on AWS Lambda.

What’s the problem
I have worked as an ML engineer for 10 years, and I have seen this hype-crash-back-to-basics several times.

10 years ago it was the Deep Learning hype, when companies of all sorts (including the one I was working back then) thought that Deep Learning for Computer Vision was all about training neural networks from scratch, without thinking of deployment and operationalisation (aka fancy ML without Ops).

Needless to say, all these projects ended up badly (including the one I was working xD).

And the thing is, I see a similar trend these days with LLM engineering and LLMOps.

Companies know how to build LLM demos, but they don’t know how to scale and operate them. So their toys never see the light of production.

Either because they are

too slow

too expensive

too hard to trust,

or all of these reasons together.

Today I want to share my 2 cents to help you go from LLM toys to LLM products that move the needle for your company.

An LLMOps blueprint
Agentic platforms are no dark magic.

They are just a bunch of applications running as containerised services inside a compute platform.

Let’s go one by one:

Compute platform
When you are a small company, you can start with serverless compute like AWS Lambda or GCP Cloud Functions. However, as you start to grow, and token volumes increase in your agentic workflows, your cloud bills will start to grow. A LOT.

So, unless you are willing to burn cash, I recommend you get into the Kubernetes train.

Your cost curve will flatten, and you will increase return of investment.

My advice

The Kubernetes learning curve is steep, especially at the beginning. However, when you overcome this first shock, a whole new world of possibilities opens in front of your eyes.

Agent workflow logic
This is typically a Python script written using libraries like

Langchain

Pydantic AI

Langgraph

Llamaindex

or, even better, using a Rust alternative like Rig.

My tip
Rust is a compiled language, that produces very small binaries, that translate into super slim containers running in your cluster. This means you can run 10-50x more agents in Rust than in Python, using the same infrastructure. So you build safer, faster and cheaper agents.

LLM servers
LLM servers, that provide text completions used by the agent workflows to reason, and to output responses.

Tool servers
Tool servers, that acts as gateways between the agents and the external services theses agents invoke to accomplish their tasks

And the thing is, with the emergence of standards for

Agent-tool interaction, like Model Context Protocol introduced by Anthropic

Agent-to-Agent interaction, like the newly proposed Agent2Agent protocol by Google.

this modularisation will take us to yet-another era of microservices architectures.

In this case, micro-agent architectures.

Which means that, if you and your company want to make the most out of it, you need to go back to good-old software engineering and DevOps best practices.

In a nutshell
IMHO this is the design that unlocks the door to Agentic Architectures that help you either

make more money for your business, or

spend less money in your business.

Build and Deploy a Real Time ML System

calleb — Thu, 12 Jun 2025 07:59:08 +0000

Today I will show you how to build a real time ML system to predict credit card fraud on top of the TurboML platform.

Feel free to adjust the code to your own use case

crypto price prediction

click-through rate prediction

anomaly detection, or

whatever problem that needs ML models to quickly adapt to changing patterns

Let's dive in!

All the code is available in this Github repository ⭐

The problem
Every time your credit card is used online by someone (hopefully you), your card issuer has to check whether the transaction is legitimate.

Behind the scenes, your credit card issuer (e.g. Visa, Mastercard, etc.) runs a real time ML system, that

Ingests the transaction data

Enriches the data with additional features (aka feature engineering).

Pipes these feature into a Machine Learning model. In this case, a classification model that outputs a fraud score. If the score is above a certain threshold, the transaction is flagged as a fraud.

Serves these scores and flags to downstream services, so they can act accordingly, for example:

Block the transaction

Ban the card

Send an SMS alert to the user

The system is modular, so different feature engineering logic and models can be applied for the same incoming data.

This way their internal Data Science teams can do things like:

Experiment with different feature engineering logic

Experiment with different model architectures

Compare the performance of different models, for safe deployments.

Monitor the model performance over time

Retrain the model incrementally on new data, to quickly adapt to changing fraud patterns.

But the thing is, building the underlying MLOps platform that supports these workflows is no piece of cake.

So the question is:

How do you build a production-ready ML system, without having to build from scratch such a platform ❓

And here is when TurboML comes to the rescue!

The solution
We will build on top of Turbo ML, a real time ML platform that helps you build, deploy and monitor production-ready real time ML systems.

The idea is simple (and brilliant).

We define the business logic in Python, including

data sources

feature engineering logic

model training and evaluation metrics

and TurboML handles all the infrastructure necessary to bring this logic to life. So you go from idea to production at light speed.

Let me show you with an example.

All the code is available in this Github repository ⭐

Steps
1. Install the tools
These are the tools you will need to follow the hands-on example:

Docker to spin up Docker containers on your machine

VSCode to open the repository, or any other IDE that supports devcontainers.

Dev Containers extension to open the repository in a devcontainer

Set up the development environment The repository comes with a pre-configured devcontainer that you can use to get started.

Why use a devcontainer?

Devcontainers are a powerful way to create a reproducible development environment. They allow

easy cross-platform development, and

are a great way to onboard new developers.

The devcontainer we use today is a Linux container based on an official Docker image built by the TurboML team, that comes with the TurboML Python SDK pre-installed. So you can start coding right away.

To open the repository inside this devcontainer, you:

git clone this repository

Reopen the repository in VSCode with the Dev Containers extension, either by

by clicking on the Dev Container tab in the bottom left of the VSCode window and selecting Reopen in Container

running the command palette (Ctrl+Shift+P) and selecting Dev Containers: Reopen in Container, or

It will take a few minutes to download the Docker image and start the container. Once everything is ready, open a new terminal session and double-check you are in a devcontainer by running

$ uname -a
If you see something like this

Linux 1821e9cf7662 6.10.14-linuxkit #1 SMP Fri Nov 29 17:22:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
you are good to go.

2. Set your TurboML credentials
Copy the .env.example file into a new .env file

$ cp .env.example .env
and replace the placeholders with your own TurboML credentials.

TURBOML_BACKEND_URL="YOUR_BACKEND_URL_GOES_HERE"
TURBOML_API_KEY="YOUR_API_KEY_GOES_HERE"

To get these credentials, sign up for free at TurboML and you will get a workspace with a backend URL and an API key.

3. Create a feature pipeline
This is the first pipeline you need to build a real time ML system.

To do this in TurboML, you first need to create a dataset object for your

features → set of variables you use to generate predictions, and

labels → target variable you want to predict

This is what the create_datasets function does.

setup_feature_pipeline.py

transactions, labels = create_datasets(
transactions_dataset_name=config.transactions_dataset_name,
labels_dataset_name=config.labels_dataset_name,
n_samples=100,
)
Once you have the dataset objects, you can define the feature engineering logic you want to apply on top of them:

setup_feature_pipeline.py

define_feature_engineering(transactions)
All this logic is encapsulated in the setup_feature_pipeline.py script, that you can run with the following command:

$ make feature-pipeline
After running this command, you should see 2 feature groups in your dashboard, one for the features and one for the labels.

4. Define and deploy a Machine Learning model
Fraud patterns are not static, but evolve over time. Fraudsters are always coming up with new ways to defraud credit card companies, so your ML system needs to adapt o these changes, to keep up with the latest fraud trends.

To accomplish this, you typically need to:

Use historical data to train a good initial model. This is often called, offline training.

Deploy this model either as a streaming job, or as a REST API, so it can start making predictions on new data.

Add monitoring to the model, so you can detect if it's performing poorly.

Update the model parameters incrementally as new pairs (input, label) come in. This technique is called online training, or incremental training. The updated model needs to be redeployed frequently, to keep up with the latest fraud trends.

With TurboML, you save yourself the hassle of building all this infrastructure from scratch.

Instead, you define the model training logic in Python, using the features and labels we created in the previous step, and TurboML will take care of

Deploying the model either as a streaming job, or as a REST API

Monitoring the model performance

Updating the model parameters incrementally

All this is encapsulated in the setup_model.py script, that you can run with the following command:

$ make model

After running this command, you should see the model deployed in your dashboard:

5. Generate live predictions
Let's put our model to work. Let's start generating live data of transactions and labels, and see how the model performs.

I created a generate_live_data.py script to generate live data. This script samples historical data to simulate a live stream of transactions and labels, and pushes them to the online datasets we created in the previous steps.

$ make live-data
What about real-world data?

In a real-world scenario, this data would come from your data sources, for example a Kafka topic or a database table.

These are called Connectors in the TurboML platform.

6. Model monitoring
After running the previous command, you can check the model performance on the dashboard:

7. Model comparison
Typically, you will want to compare the performance of different models, to see which one performs better.

You can easily do this by:

Updating the model_name in the config.py file → e.g. model_name = "fraud_detection_model_2"

Running the setup_model.py script again

Comparing the performance of the new model with the old one on the TurboML dashboard.

Now it is your turn 🫵
Sign up for free at TurboML and start building your own end-2-end real time ML systems.