I am Andre from the Data Science and Analytics (DSA) track of MITB’s August 2025 intake. From April to October 2026, I interned with Olam Food Ingredients (ofi) as a Commercial Analyst in the Cocoa Division, supporting the Commercial team through market and sales analytics.

As someone transitioning from Research & Development in Food Science into analytics, this internship represented more than just a six-month attachment. As I embark on my career change, this opportunity was a rare one, allowing to bridge two very different worlds. Having attended CDSWS10 Managing Career Change, I knew that the “easier” route would have been a singular pivot, either changing job functions within the same industry or keeping the same function while moving industries. However, opportunities within Food domain were limited, with the only singular pivot available for me being job function, and the gap between Food Science and Data Science is substantial.

This internship therefore felt like a rare doorway into the analytical field and, hopefully, a gateway towards future analytics roles.

Interview Process

The interview process was one of the more unusual experiences of my internship journey. It began with an informal screening call with the Head of HR, where we discussed my background, motivations, and career aspirations. Surprisingly, HR expressed the intention to offer the internship shortly afterwards, despite me not having met the hiring manager or undergone any technical assessment.

Wanting greater clarity before making a decision, I requested a meeting with the hiring manager. The discussion provided a better understanding of the role, team objectives, and how the internship aligned with both MITB requirements and my career goals. However, it also revealed that analytics capabilities within the team was relatively limited, with Excel and Power BI serving as the primary tools while Python and SQL appeared to play a secondary role.

Uncertainty and scepticism remained, yet the opportunity still represented a rare chance to pursue the career pivot I had been seeking.

I took a leap of faith.

Working as a Commercial Analyst Intern in ofi (Cocoa)

Olam Food Ingredients (ofi) is a global food and agri-business. This internship was housed within the Cocoa Division, covering products across the cocoa value chain, including cocoa beans, powder, liquor, and butter.

Overarching Project

The primary project occupied most of my internship tenure.

The company had purchased third-party market data to improve market understanding and support commercial strategy. However, the dataset had reportedly remained largely untouched for over a year. The internship position was subsequently created to determine how commercial value could be extracted from it.

The Actual Work Done in This Role

One of my initial observations after joining the team was the absence of an established analytics function. There were no resident data analysts, predefined frameworks, or existing workflows to inherit. While this initially felt intimidating, it also created a unique opportunity.

Rather than stepping into an existing process, I was given the freedom to help shape one.

The project was largely unconstrained by existing processes, offering substantial ownership and autonomy over both the analytical approach and the direction of the work. It provided a blank canvas on which to creatively apply the skills, methodologies, and disciplines developed throughout the MITB programme.

Upon gaining access to the dataset, the broad work process involved:

1. Understanding what management hoped to achieve with the data.
2. Understanding what the data was actually capable of answering, whether narrower or broader than management’s expectations.
3. Wrangling messy text-based data into structured information that could be aggregated, analysed, and visualised.
4. Building PowerBI dashboards capable of addressing management’s requirements while clearly communicating any analytical limitations.

With the goal of establishing a structured understanding of global cocoa trade flows to support market intelligence and strengthen competitive positioning against other cocoa bean grinders in the region.

One of the key challenges involved transforming unstructured trade records into a format suitable for analysis. This required extracting SKU and product information from free-text “Goods Description” fields and harmonising importer and exporter names across different origin and destination countries. The methodology was subsequently generalised across all countries under investigation, enabling large-scale aggregation, visualisation, and market analysis.

Given that the project was solely owned by an intern, it was also important to ensure a smooth handover upon completion. While more technically sophisticated solutions were possible, I recognised that their value would be limited if future users were unable to maintain them. With Excel being the primary tool used by the team, I intentionally constrained the solution design around tools and workflows that would remain accessible after my departure.

This led to several key considerations:

1. Data cleaning, transformation, and other recurring processes had to be performed within Excel using transparent, step-by-step workflows that were easy to understand and maintain.
2. Power BI dashboards had to be easily refreshable and maintainable by users with limited technical expertise.
3. Any processes requiring other programming languages or tools had to be fully automated, requiring only script execution without modification.

With these constraints and considerations in mind, the project was ultimately executed using Excel (including Power Query) and PowerBI.

Short Side Projects and Ad Hoc Requests

Beyond the primary project, there were opportunities to support a range of smaller initiatives and ad hoc requests.

These smaller projects varied substantially in scope and requirements, but they provided valuable opportunities to apply more advanced analytical techniques, modelling techniques, or exposure to tools that were beyond what I had been exposed to in the MITB programme as of this writing. Examples included:

• Forecasting Cocoa Bean Arrivals using time series modelling with XGBoost Regressor and lag-variable feature engineering.
• Explored the use of Agentic AI on Copilot Studio as an alternative to PowerBI reporting or complementary tool, assessing its generative capabilities and the costs trade off.

Who Does the Intern Interact With?

Supervisor

My supervisor was also the hiring manager and primary stakeholder. He focused on obtaining data-backed answers to business questions while giving significant autonomy over the design and execution of analytical solutions.

Colleagues Across Functions

Interactions with colleagues were highly collaborative. They provided domain knowledge, business context, and feedback on dashboard usability, while I supported analytical requests and explained methodologies and outputs.

Relevant Coursework

Several MITB modules were particularly valuable in supporting the work required for this role.

ISSS621 Data Science for Business

Arguably the most impactful module. The discipline of always anchoring analytics work to a Business Question ensured that analytical efforts remained relevant, purposeful, and aligned with business objectives. The ability to translate business questions into measurable data science tasks proved especially valuable.

IS628 Computational Thinking with Python

In particular, Regular Expressions (Regex) formed the foundation of the data cleaning process. They were instrumental in transforming messy text-based fields into structured information suitable for aggregation, analysis and visualisation.

ISSS615 Data Management & IS625 Query Processing and Optimisation

Concepts surrounding relational databases, data modelling, and entity-relationship design proved useful when integrating datasets, mapping relationships, and constructing dimension tables.

CS610 Applied Machine Learning

Knowledge of machine learning algorithms, model evaluation techniques, and practical implementation enabled the application of models such as XGBoost in forecasting-related tasks.

Learnings and Takeaways from the Internship

The freedom to independently shape the project’s direction provided significant opportunities for both technical and professional growth. Beyond strengthening my capabilities in Excel, Power BI, and analytics, I was able to apply concepts and methodologies from the MITB programme within a real-world business environment.

The high level of ownership also created opportunities to present findings, demonstrate dashboard functionalities, and explain how analytical outputs addressed business questions. Through these interactions, I developed the ability to translate technical concepts and analytical methodologies into language accessible to stakeholders with varying levels of data literacy.

One of the most valuable lessons from the internship was that data and analytics derive their value not from technical sophistication alone, but from their ability to support meaningful business objectives. While metrics, models, and visualisations can generate insights, their impact depends on how effectively they are linked to business context and decision-making. This reinforced the importance of combining technical expertise with domain knowledge and business understanding, a skillset that remains highly transferable across industries.

An encouraging outcome of the internship was the interest expressed by management in exploring potential opportunities within the organisation beyond the internship period. While no formal offer was extended, discussions were held around areas such as digitalisation, data governance, business transformation, and commercial support, where my combined background in Food Science and Data Science & Analytics was viewed as potentially valuable. These conversations reflected a positive reception to the work completed during the internship and remain open for future consideration following my next internship and completion of the MITB programme in April 2027.

Advice for Future Interns

1. Don’t Judge an Internship Solely by the Technology Stack

It is easy to evaluate an internship based on the tools listed in the job description. Compared to many technology-focused internships, my role relied primarily on Excel, Power BI, and occasional Python usage rather than modern data infrastructure or large-scale analytics platforms.

However, technical sophistication does not necessarily determine learning value (apart from the technical proficiency of it). Despite the relatively simple tech stack, I had substantial ownership over the entire analytical process, from understanding business requirements and preparing data to building dashboards and presenting insights. While tools matter, the scope, autonomy, and business impact of the work can be equally valuable opportunities for growth.

2. Learn the Business Before Focusing on the Analytics

One of the biggest lessons I learnt was that understanding the business often creates more value than immediately applying analytical techniques.

Before any analysis could be performed, it was necessary to understand what management was trying to achieve, what decisions needed to be made, and what questions the business wanted answered. Only then could the data be evaluated for its usefulness.

Many aspiring data professionals naturally gravitate towards technical solutions. However, a sophisticated analysis that answers the wrong question creates little value, while a simple analysis that addresses an important business problem can have significant impact.

3. Be Comfortable with Ambiguity

Not every organisation will have mature analytics capabilities, established processes, or clearly defined project requirements.

When I joined the team, there was no resident data analyst and no predefined framework for how the project should progress. Initially, this uncertainty was intimidating. Over time, however, I realised that ambiguity can also be an opportunity.

The lack of an established process provided greater freedom to shape the analytical approach, define workflows, and determine what outputs would be most valuable. While structured environments can accelerate learning, less structured environments often provide greater opportunities to develop ownership, initiative, and problem-solving skills.

4. Build Solutions Others Can Maintain

As the sole owner of the project, I knew that maintainability was just as important as the analysis itself. Although more technically sophisticated solutions were possible, many would have been difficult for future users to support. As a result, recurring processes were intentionally designed around tools that colleagues were already familiar with.

The best solution is not always the most advanced one. More often, it is the one that balances capability, usability, and maintainability.

Final Thoughts

Looking back, the factors that initially made me hesitant to accept the internship ultimately became the factors that made it valuable. The most important lesson I took away was that analytics is ultimately a means to an end. Tools, models, and dashboards only create value when they help answer business questions and support decision-making.

Regardless of industry or role, individuals who can combine technical skills with business understanding, ownership, and effective communication will be better positioned to create meaningful impact.

Acknowledgements

I would like to express my sincere gratitude to Saurabh and Valencia for the opportunity to intern with ofi, as well as Syed, Yi Feng and Joanne, for their guidance and support throughout the internship. The trust they placed in me, together with the freedom to explore, experiment, and shape the project’s direction, made the experience especially meaningful. It provided a rare opportunity to apply the skills and perspectives gained from the MITB programme to real business challenges, while learning firsthand how analytics can create value within a commercial environment.

Disclaimer: All opinions and interpretations are that of the writer(s), and not of MITB. We declare that we have full rights to use the contents published here, and nothing is plagiarized. We declare that this article is written by us and not with any generative AI tool such as ChatGPT. We declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of our knowledge. We agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

The Cocoa Trade: Data, Decisions, and an Internship with Olam Food Ingredients was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few weeks ago I started my Master of IT in Business journey at Singapore Management University (SMU) and somehow, I’m already halfway through my first term (how time flies so fast!).

If I’m being honest, going back to school after working for a few years feels very different from what I expected.

There are the obvious parts: attending classes, doing assignments, preparing for quizzes, working on group projects, and trying to remember what it feels like to study for an exam again.

But beyond the academic workload, I’ve realised that this experience has been teaching me something I didn’t quite expect: sometimes, going back to the basics is exactly what you need to move forward.

Going back to the basics

After working for a while, we naturally develop our own ways of doing things. You build muscle memory. You know which tools to use, which shortcuts to take, and what usually works. Eventually, you can do certain things almost automatically.

But when you go back to the fundamentals, you start asking different questions:

Why am I doing it this way?
Why does this method work?
Is there actually a better way to approach this problem?

And that has been one of the things I appreciate most about the program so far. Going through the fundamentals again has helped me understand the reasoning behind some of the things I have been doing at work, rather than simply knowing how to do them.

It’s a good reminder that knowing how to do something and understanding why you do it are two very different things.

The people make the experience

Another thing I’ve really enjoyed is meeting people from completely different backgrounds.

Everyone comes into the classroom with a different set of experiences and strengths. Some people are incredibly skilled in areas where I have much less experience, while I have my own areas where I can contribute.

And that’s where things get interesting!

Instead of everyone trying to know everything, we complement one another. A group discussion can suddenly become a mini knowledge exchange: someone brings the technical perspective, someone brings the business perspective, someone has industry experience, and someone else sees the problem from a completely different angle.

The only problem?

There is never enough time to learn everything from everyone.

There are simply too many interesting conversations to have, too many people to meet, and too many things happening at once.

When everything becomes P0

And speaking of “too many things”…

Individual projects. Quizzes. Assignments. Group projects. Readings. Classes. Networking. Somehow, still trying to have a life outside school. At some point, my priority matrix started looking… questionable. 😂

It actually reminds me a lot of working in a fast-paced environment where suddenly everything is P0. Everyone wants to be prioritised. Everything feels urgent. And when everything is a priority, nothing really is.

So once again, I found myself asking:

What actually needs to be done first?

I started becoming much more intentional about prioritising based on impact and effort. If something is low effort and high impact, why not get it out of the way first? If something is important but requires more time, perhaps it needs to be broken down into smaller tasks.

It sounds simple, but being thrown into an environment where multiple deadlines overlap has made me practise this much more deliberately. Ironically, one of the biggest things I’ve learned so far isn’t from a textbook.

It’s how to manage my own time and priorities.

And this is only the first half

It has only been the first half of my first term, but I already feel like I’ve learned so much.

Not just academically, but also in ways that are much harder to measure: learning from people with different perspectives, becoming more comfortable with uncertainty, managing competing priorities, and reminding myself that there is always more to learn.

I’m sure there will be many more stressful weeks, confusing assignments, last-minute group discussions, and “how am I supposed to finish all of this?” moments ahead.

But I’m also looking forward to them.

Because perhaps that’s what going back to school is really about — not just collecting another qualification, but putting yourself in an environment where you get to learn, unlearn, and grow all over again.

Here’s to the second half of the term, and to many more lessons and journeys ahead. 🥂

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

Going Back to School: 1st Term of My SMU MITB Journey was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

The artificial intelligence industry has spent the past few years racing to build increasingly intelligent large language models (LLMs).

LLMs got bigger, got better at reasoning and now accept longer context windows.

Then, on 15 September 2026, something rather different arrived.

Meet Jev, the world’s first commercially released “System One” model.

And here’s the interesting part: Jev doesn’t generate text. It makes decisions.

Unlike a conventional generative LLM, Jev doesn’t produce free-form text. Instead, you give it a set of possible answers, and it evaluates them, returning confidence scores for the available options.

Think multiple-choice questions rather than essay writing.

Why the hype?

According to benchmarks published by TypeSafe AI, Jev delivers competitive classification accuracy at a fraction of the cost of state-of-the-art LLMs:

In addition, as we’ll soon see, Jev is absurdly fast.

The implication is that you might not always need to use a LLM for classification and tool calling. Jev would be able to do it too.

End of story?

Not quite. There’s always a caveat.

Though Jev’s model architecture is unknown, it is the first model to be classified as a “Systems One” model. This borrows from the definition of “Systems One” first coined by Daniel Kahneman in his book “Thinking, Fast and Slow”, which is now the cornerstone of behavioral economics.

The theory is this: systems one is our fast, automatic, intuitive state of decision-making.

As an example, imagine if your colleague sitting next to you at work got surprised by other colleagues with a “happy birthday” song. You might react by singing along without thinking. That’s a system one response.

System Two, on the other hand, describes slower, more deliberate thinking. It’s what happens when we consciously work through a difficult problem, such as solving a quadratic equation.

Of course, the two systems aren’t completely independent. Our intuition frequently informs our deliberate reasoning, and deliberate reasoning can override our intuition.

But the distinction is useful: System One reacts. System Two reasons.

This distinction is important when building AI agents.

Jev might be excellent at deciding which tool should handle a request. But deciding which tool to call is not the same as reasoning through the problem, executing a multistep workflow, and synthesizing the results.

In other words, Jev might make an excellent bouncer. That doesn’t mean it should run the entire nightclub.

Important Fineprint

Jev 1.13 (the latest model) is said to have a context window of 64k tokens — far less than the 1 million token context window of state-of-the-art LLMs.

TypeSafe AI is pushing the envelope though. Jev 1.14 (in preview) is said to have a long-context mode which takes up to 262k tokens. TypeSafe AI caveats that Jev is less accurate and slower in this mode — so don’t go stuffing entire documents or chat histories at it.

Since the launch of Jev, many open-sourced “System One” models have been released — most involve finetuning a smaller LLM like Qwen 3.5:9bn to do classification. Not all of these models are trained via the reinforcement learning for calibrated decisions (RLCD) regime like Jev though.

Other closed-sourced systems one models like Liquid AI’s d1 model have also since been released.

What we’re witnessing might be the beginning of a second AI race: not to build models that can reason about everything, but to build models that can make narrow, reliable decisions extraordinarily quickly.

How should you use Jev then?

TypeSafe AI provides many cookbooks demonstrating how Jev can perform tasks traditionally handled by specialized models. For example, Jev can be used to rerank retrieved text chunks — a task typically assigned to a dedicated reranker.

LangChain published an integration package with TypeSafe AI that ships with two default middlewares — ModelRoutingMiddleware and AutoModeMiddleware that aim to use Jev in different settings:

The spirit of these recipes is this: Jev can be used at decision-making points that would otherwise require an LLM. But just because Jev can make a decision doesn’t necessarily mean it should. The trick is identifying decisions that don’t require extensive reasoning, and determining whether Jev can make them reliably.

At the time of writing, I haven’t read any of these cookbooks. Instead, I wanted to approach Jev from first principles and figure out where it might fit into my own multi-agent systems.

What follows is my own experiment, rather than an adaptation of an existing recipe. I hope you find it useful!

I’ll walk through the architecture, implementation, and experiments below. You can also find the complete code in my GitHub repository.

The idea

One of the challenges of building agentic applications is that you never quite know what questions your users will throw at your agents.

User questions might be abstract, multipart, direct, or simply badly written. Depending on the question, an agent might benefit from asking for clarification, decomposing the request into smaller questions, or rewriting it into something more precise.

More commonly, however, we simply rely on the raw intelligence of the LLM to figure everything out, including which tools and skills to invoke.

Let’s change that.

In my experiment, I’ll create a hierarchical multi-agent system with a supervisor agent, a forex exchange agent and a web search agent; and use Jev to be the bouncer at the door.

The tools

There are two tools.

My forex exchange agent uses a forex tool around Frankfurter’s generous public forex API:

import requests
from langchain.tools import tool

@tool
def get_forex_exchange_rate(base_currency: str, target_currencies: list[str]) -> dict[str, float]:
    """
    Get the current forex exchange rate between two currencies.

    Args:
        base_currency (str): The base currency code (e.g., "USD").
        target_currencies (list[str]): A list of target currency codes (e.g., ["EUR", "GBP"]).

    Returns:
        dict[str, float]: A dictionary mapping each target currency to its exchange rate.
    """
    res = requests.get(
        "https://api.frankfurter.dev/v2/rates",
        params={"base": base_currency, "quotes": ",".join(target_currencies)},
        timeout=10,
    )
    rates = {row["quote"]: row["rate"] for row in res.json()}
    return rates

My web search tool leverages Tavily’s generous free tier:

from langchain_tavily import TavilySearch

tavily_tool = TavilySearch(
    max_results=5,
    topic="general",
    include_answer=False,
    search_depth="basic",
)

Jev as the bouncer

I want Jev to intercept every user query before my supervisor agent sees it, and determine whether the query needs further work. If so, perform the query enrichment so that we can maximize the mileage (and hopefully save tokens) of our multi-agent system.

LangChain’s before_agent agent middleware hook is the perfect place to implement this, and can be used either as a function or within a class that subclasses AgentMiddleware .

Let’s start by defining the middleware’s constructor and the middleware hook method:

class QueryEnrichmentMiddleware(AgentMiddleware):    
    def __init__(self, llm, classifier = None, threshold: float = 0.80):
        super().__init__()
        self.llm = llm
        self.classifier = classifier or TypeSafeClassifier()
        self.threshold = threshold
        self.handlers = {
            "decomposable": self.decompose_query,
            "enrichable": self.enrich_query,
            "needs_clarification": self.clarify_query,
        }

    def before_agent(self, state: AgentState, runtime: Runtime) -> dict[str, Any] | None:
        messages = state["messages"]
        if not messages or not isinstance(messages[-1], HumanMessage):
            return None
        query = messages[-1].text

        next_action = self.query_classify(query).choices["next_action"]
        handler = self.handlers.get(next_action.choice)
        if next_action.confidence < self.threshold or handler is None:
            return None
        return {
            "messages": [
                HumanMessage(
                    content=handler(query), 
                    id = messages[-1].id
                )
            ]
        }

We want to extract the last human message, classify it, handle it, and then send it to the supervisor agent. Importantly, before_agentmust return either a dictionary object or Nonein or LangChain will return an error.

With that in mind, it’s time to write our handlers:

def enrich_query(self, query: str) -> str:
    """Helper function to enrich user queries"""
    return self.llm.invoke(
       "Rewrite the following user query for clarity. "
       "Preserve the original meaning and all explicit constraints. "
       "Do not invent missing details or answer the question. "
       "Return only the rewritten query.\n\n"
       f"User query: {query}"
    ).content
    
def decompose_query(self, query: str) -> str:
     """Helper function to decompose user queries"""
     sub_queries = self.llm.invoke(
        f"The user's query is: {query}. "
        "Your role is to decompose this query into sub-queries that can be answered separately. "
      )
     return (
         f"Original user query: {query}\n\n"
         f"Suggested sub-questions:\n{sub_queries.content}\n\n"
         "Use these sub-questions to guide your analysis. "
         "Combine related operations where appropriate, "
         "and synthesize the results into a single response."
     )

def clarify_query(self, query: str) -> str:
    """Helper function to inject prompt to clarify user queries"""
    return (
         f"Original user query: {query}\n\n"
         "The request may be ambiguous or missing essential information. "
         "Ask the user one concise clarification question before proceeding. "
         "Do not assume missing details."
    )

• enrich_query uses an LLM to replace the original query by rewriting it to be clearer and more specific
• decompose_query uses an LLM to decompose the original query into sub questions, then appends these sub questions on top of the original query
• clarifiy_query nudges the LLM to seek user clarification — wrapping the original user query.

Now for the query classification method

This is where Jev comes in.

LangChain’s TypeSafe AI integration docs are extremely instructive. In essence, Jev has 3 primary primitives:

Of these, Noul is the only primitive that does not return a confidence score (remember that machine learning class?).

Choice is the equivalent of a normal classification task, and Score is a subset of Choice , used for questions where the answer is a position on a spectrum — for example, on a scale of 1–5, how much does it hurt when your agent hallucinates.

For our bouncer, we’re interested in choosing between several possible actions: rewrite, decompose, clarify, or leave the query alone. That makes Choice a natural fit.

The code:

def query_classify(self, query: str) -> ClassifierResponse:
    """Helper function to classify user queries using Jev"""
    return self.classifier.invoke(
        {
            "state": query,
            "questions": {
                "next_action": Choice(
                    instructions = "Should this query be decomposed into multiple sub-queries?",
                    criteria = {
                        "decomposable": "Does the query have multiple distinct sub-queries that can be answered separately?",
                        "direct": "Is the query a single, direct question that can be answered without additional context or information?",
                        "enrichable": "Should the query be re-written to be clearer so that it can be answered more effectively?",
                        "needs_clarification": "Does the query require additional context or clarification before it can be answered?",
                    }
                )
            }
        }
    )

Taking it out for a spin

Let’s see Jev classify something using our middleware:

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-6-luna")
decomposable_query = (
    "What is the current exchange rate between USD and EUR, "
    "and can you also provide the latest news on the European Central Bank's "
    "monetary policy?"
)

query_middleware = QueryEnrichmentMiddleware(llm=llm)
response = query_middleware.query_classify(query=decomposable_query)
print(
  response.choices["next_action"].choice, 
  response.choices["next_action"].confidence
)

# decomposable 1.0

Jev classified the query as decomposable with a confidence score of 1.0. Given that the request contains two distinct questions, that's hardly surprising.

Assembling the multi-agent system

Let’s first start by wrapping our sub agents and their tools in LangChain’s SubAgentMiddleware :

from deepagents.backends import StateBackend
from deepagents.middleware import SubAgentMiddleware

subagent_middleware = SubAgentMiddleware(
    backend=StateBackend(),
    subagents = [
        {
            "name": "Forex_Expert",
            "description": "An expert in forex exchange rates and currency markets.",
            "tools": [get_forex_exchange_rate],
            "model": llm,
        },
        {
            "name": "Web_search",
            "description": "An expert in searching the web for information.",
            "tools": [tavily_tool],
            "model": llm,
        },
    ]
)

The SubAgentMiddleware class wraps every subagent as a task tool for the supervisor agent — so we don’t have to define any further tools.

Notice the backend parameter. It deserves an article of its own, so I'll leave that discussion for another time. For this demonstration, StateBackend keeps things simple.

Next, let’s instantiate the checkpointer and create the supervisor agent:

conn = sqlite3.connect("jever.db", check_same_thread=False)
checkpointer = SqliteSaver(conn)

agent = create_agent(
    model = llm,
    tools = [], # LOOK NO TOOLS!
    middleware = [query_middleware, subagent_middleware],
    checkpointer=checkpointer,
)

Running the agent against the same query, we get:

response = agent.invoke(
    {"messages": [ HumanMessage(content=decomposable_query),]},
    {"configurable": {"thread_id": "thread-4",}}
)

# Truncated response
### USD to EUR: The latest rate lookup returned US$1 ≈ €0.8920. 
### ...
### ECB monetary policy: As of 15 October 2026, the latest rate decision I 
### could verify was on 10 September. The ECB raised its key rates by 0.25 
### percentage point, ....

It’s what our traces tell us that’s interesting

The first trace shows the expected execution pattern. Jev classified the request as decomposable, our middleware generated the sub-questions, and the supervisor subsequently invoked both specialist agents in parallel before synthesizing their responses.

Importantly, Jev didn’t select the specialist agents. That decision remained with the supervisor.

In one run, my supervisor agent actually got one of its subagents to do a web search to verify the findings of a previous subagent run:

That’s an example of adaptive orchestration.

Rather than executing a predetermined sequence of steps, the supervisor made a subsequent decision based on the information available.

To me this proves that it is quite dangerous to simply replace the supervisor agent with Jev, because:

• Jev is unable to synthesize a final response from subagent replies,
• Jev can classify predefined next actions, but it doesn’t offer the same open-ended reasoning and generation capabilities as a conventional LLM supervisor.

Jev did an amazing job as a bouncer though.

How did the Jev-ed agents do for other question types?

I then ran the multi-agent system across 3 more query types:

direct_query = "What is the current exchange rate between USD and EUR?"
enrichable_query = "Usain Bolt fast how training he?"
needs_clarification_query = "fasdlkfaleuraoi34"

tests = [direct_query, enrichable_query, needs_clarification_query]
answers = []
for i, test in enumerate(tests):
    response = agent.invoke(
        {"messages": [ HumanMessage(content=test),]},
        {"configurable": {"thread_id": f"thread_{i}",}}
    )
    answers.append(response['messages'][-1].content[-1]['text'])

And the Jev-ed agent did well for them:

The latest rate available to me is 1 USD ≈ 0.8916 EUR. 
---
Bolt trained for explosive speed, not long-distance running....
---
What would you like me to do with “fasdlkfaleuraoi34”?

An important point is the enrichable_query question:

Jev classified the deliberately poorly written question as enrichable, as expected. However, its confidence score fell below our threshold of 0.80. Consequently, the middleware left the original query untouched and allowed the supervisor to handle it directly.

How did the baseline do?

Here’s the code I used to run the baseline:

baseline_agent = create_agent(
    model = llm,
    tools = [], # LOOK NO TOOLS!
    middleware = [subagent_middleware],
    checkpointer=checkpointer,
)

baseline_tests = [decomposable_query, direct_query, enrichable_query, needs_clarification_query]
baseline_answers = []
for i, test in enumerate(baseline_tests):
    response = baseline_agent.invoke(
        {"messages": [ HumanMessage(content=test),]},
        {"configurable": {"thread_id": f"baseline_thread_{i}",}}
    )
    baseline_answers.append(response['messages'][-1].content[-1]['text'])

Their metrics on LangSmith were pretty interesting:

Now here’s where things get interesting.

For our multipart question (rows 4 and 8), the baseline agent took 2 minutes and 21 seconds to complete its response.

With Jev-powered query enrichment, the same task took just 11.69 seconds.

That’s approximately a 12× reduction in execution time, despite the additional classification and query decomposition steps.

I repeated the baseline experiment several times, and the results remained substantially slower. Even my fastest baseline run took approximately 1.5 minutes.

So what happened?

My hypothesis is that the decomposed query helped the supervisor understand how to distribute the work across its specialist agents, avoiding unnecessary deliberation or repeated tool invocations.

However, there’s an important caveat: Jev didn’t perform the decomposition itself. It classified the query as requiring decomposition, after which another LLM generated the sub-questions.

Consequently, this experiment doesn’t isolate how much of the improvement came from Jev versus the decomposition step.

What it does demonstrate is that conditionally preprocessing a complex query can substantially change how an agent executes it.

Interestingly, the differences for the other question types were relatively small.

My suspicion is that GPT-6-Luna was already capable of handling those simpler requests without assistance.

This raises an interesting question: would a more capable supervisor narrow the performance gap, or would a smaller model benefit even more from query enrichment?

That’s an experiment for another day.

Final thoughts

So, does your AI agent need a bouncer? Perhaps.

Jev is an interesting addition to the AI engineer’s toolbox. Rather than replacing the reasoning capabilities of an LLM, it offers an alternative for making fast, inexpensive decisions at specific points in an agentic workflow.

In my experiment, Jev helped determine whether incoming queries needed clarification, rewriting, decomposition, or no intervention at all. The results were encouraging, particularly for multipart questions, where the Jev-powered system completed one task nearly 12 times faster than the baseline. Of course, this is a small experiment, and more rigorous testing is needed to determine how much of that improvement came from Jev’s classification versus the subsequent LLM-powered query decomposition.

But that’s not really the point. The interesting opportunity isn’t replacing LLMs with Jev. It’s identifying where we don’t need an LLM in the first place. Not every decision requires an expensive reasoning model, and not every user query needs additional processing. Sometimes, a lightweight classifier is all we need to decide what happens next.

As agentic systems become increasingly sophisticated, I suspect we’ll see more specialized models working alongside general-purpose LLMs, each doing what they’re best at.

And that’s how you catch Jev-er. 😎

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

Your AI Agent Needs a Bouncer was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cryptocurrency has a volatility problem.

The entire construct of cryptocurrency is trust-based through the use of blockchain. Unlike fiat currencies like USD, cryptocurrencies are unregulated, but can be exchanged for fiat currencies.

However, a quick google search shows the price fluctuation of bitcoin:

Imagine receiving your salary in cryptocurrency, only to discover that your purchasing power has fallen by 10% before you’ve paid your bills.

One solution is to create a cryptocurrency that doesn’t fluctuate in value. Just create a token and promise everyone that it’s worth one US dollar.

Welcome to stablecoins, where blockchain technology meets a centuries-old financial concept: someone promising that their money is worth something else.

In this article, I’ll explain what stablecoins are in great detail. Specifically, how their exchange rates are maintained, and what happens when those mechanisms fail.

As with my previous articles, all my code can be found in my GitHub repository.

1. What is a stablecoin?

Simply put, a stablecoin is a cryptocurrency designed to maintain a stable value relative to another asset, typically a fiat currency like the US dollar.

Say I were to create my own TitusCoin (TTC) and peg it to USD, then my objective would be:

1 TTC = 1 USD

Simple enough. Problem solved, right?

Right. And then some.

1a. Banks transfer money between themselves and facilitate payments between individuals and organizations.

However, some payment and settlement systems operate within specific business hours, particularly when transactions cross national borders. Transactions can also take time to settle, depending on the payment infrastructure and institutions involved. Stablecoins circumvent these issues. A stablecoin can be transferred between blockchain addresses at any time, even when conventional banking systems are closed.

The transfer can settle on-chain without waiting for the next banking day, although converting the stablecoin back into fiat currency may still depend on banking infrastructure and the issuer’s redemption arrangements.

That’s potentially useful for cross-border transactions, payments, and financial institutions moving value between counterparties.

1b. Stablecoins can also provide an alternative to holding currencies that experience significant volatility.

For example, someone holding a currency that is rapidly depreciating against USD might choose to convert part of their holdings into a USD-denominated stablecoin.

This reduces their exposure to their domestic currency, although it introduces other risks, including exposure to the US dollar and the stablecoin issuer.

2. So can anyone create a stablecoin?

Stablecoins are still a cryptocurrency and trust is still the key. I could create a million TitusCoins (TTCs) and call myself a millionare, but my declaration does not mean anyone will believe it.

Let me explain using the age old-economics concepts of demand and supply.

Remember the Asian Financial Crisis of 1997?

Before the Asian Financial Crisis, Thailand maintained an exchange-rate regime that kept the Thai baht closely tied to the US dollar at 25 Baht to 1 USD.

The Bank of Thailand had to intervene in foreign exchange markets to maintain this rate. If too many people wanted to sell Baht for USD, the central bank would have to defend its currency by using its foreign exchange reserves to purchase Baht.

Here’s the problem: The Bank of Thailand did not have an unlimited supply of US dollars.

During the 1990s, speculators began questioning whether Thailand could maintain its exchange-rate regime. Wealthy investors, including funds associated with George Soros, made bets against the Baht by shorting it.

These investors deliberately hoarded USD and aggressively borrowed and sold Baht for even more USD, anticipating that the currency would eventually depreciate. The Bank of Thailand continued defending the exchange rate using its foreign reserves and other market interventions.

But the pressure became increasingly difficult to sustain. And Thailand eventually abandoned its exchange-rate regime and allowed the Baht to float. The currency depreciated sharply, contributing to a financial crisis that spread across much of Asia.

The lesson: You can promise that your currency is worth a fixed amount of another currency. But maintaining that promise requires resources and market confidence.

Reference: Lessons learnt from the Asian Financial Crisis (Bank of Thailand)

3. Let’s create TitusCoin

Time to establish a fictional financial institution called Titus Bank and a stablecoin cryptocurrency called TitusCoin (TTC). My promise is straightforward:

Anyone holding 1 TTC can redeem it for 1 USD, subject to the bank’s redemption arrangements.

To back that up, I ensure that Titus Bank must hold at least USD 1 in reserves for every TTC issued.

So, if Alice deposits USD 100 into Titus Bank, I mint 100 TTC and send the tokens to her blockchain address. I’d also have to find some way to put USD 100 in my bank. That way if Alice wants her money back, I destroy or burn those tokens and release USD 100 from my reserves.

This is the basic concept behind a fiat-backed stablecoin, such as USDC, issued by Circle.

4. But does 1 TTC always equal 1 USD?

Not necessarily. There’s an important distinction between the value promised by Titus Bank and the price at which TTC actually trades on cryptocurrency exchanges.

I can’t stop Alice from selling her TTC to Bob for USD 1.10, or some other amount. The issuer’s promised redemption value and the market price are two different things — the market price depends on what buyers and sellers are willing to pay.

And as we saw in the Asian Financial Crisis, it depends largely on whether people believe the issuer can honor its promise.

The USDC depegging incident of March 2023

In March 2023, Silicon Valley Bank (SVB), a major US financial institution, collapsed. Unfortunately for Circle, approximately USD 3.3 billion of its reserves (roughly 8% of its reserves) were deposited with SVB.

When SVB failed, uncertainty emerged over whether Circle could recover those funds. And the cryptocurrency market reacted.

USDC, which was supposed to maintain a value of USD 1, briefly traded around USD 0.87–0.88 on secondary markets.

No blockchain failures or cyberattacks. The market was simply uncertain whether Circle could access enough reserves to honour redemptions. Nonetheless, Circle maintained its commitment to redeem eligible USDC holdings at USD 1 per token.

Following intervention by US authorities to protect depositors at SVB, confidence recovered, and USDC returned towards its peg.

A stablecoin’s price doesn’t remain at USD 1 simply because its issuer says it should. So what actually keeps the market price close to the promised value?

5. Greed is the main market force maintaining the exchange rate

More specifically, arbitrage.

Imagine that 1 TTC = USD 1.20 on a cryptocurrency exchange. That’s interesting, especially when you remember Titus Bank’s promise of issuing 1 TTC for every USD 1 deposited.

Which means, you could:

• Deposit USD 100 with Titus Bank.
• Receive 100 newly minted TTC.
• Sell those 100 TTC on the market for USD 120.
• Pocket the USD 20 difference.

20% profit!

The problem is every other investor will do the same thing.

As more TTC tokens are minted and sold, supply increases which pushes the market price back to USD 1.

So what happens if say 1 TTC = USD 0.90? Titus Bank still promises 1 TTC for USD 1. So you could:

• Purchase 100 TTC on the market for USD 90.
• Redeem those tokens with Titus Bank.
• Receive USD 100.
• Pocket the USD 10 difference.

And every other investor will do the same. So demand for TTC increases, and when those tokens are redeemed, they are burned, which reduces the circulating supply. Which pushes the price to return to USD 1.

This is the fundamental arbitrage mechanism behind a redeemable fiat-backed stablecoin.

Isn’t it beautiful that nobody needs to perform these transactions out of kindness? Greed makes things work out.

But this only works reliably when redemption is accessible, transaction costs are manageable, and investors believe Titus Bank can actually pay them.

6. What about using another cryptocurrency to maintain the peg?

What if, instead of keeping US dollars in a bank, we used another cryptocurrency to maintain the value of TTC?

Let’s introduce TitusFloat (TTF), a cryptocurrency whose price fluctuates freely.

Instead of promising that every TTC is backed by an actual US dollar, our protocol allows users to exchange TTC for USD 1 worth of TTF.

Notice the difference? We’re promising that 1 TTC can be exchanged for however many TTF tokens are worth USD 1 at the prevailing market price.

Say 1 TTF = USD 100:

• If Alice redeems 1 TTC, we burn her TTC and issue her 0.01 TTF. That’s USD 1 worth of TTF.
• If TTF falls to USD 50, redeeming 1 TTC would instead create 0.02 TTF

6a. The mechanism of maintaining the peg is conceptually similar

If TTC trades below USD 1, arbitrageurs can purchase discounted TTC and exchange it through the protocol for USD 1 worth of newly issued TTF.

For example:

• If 1 TTC trades at USD 0.90.
• Investors each purchase 100 TTC for USD 90.
• They redeem those tokens through the protocol and receive USD 100 worth of TTF.
• They then sell the TTF on the market.
• The TTC tokens are burned during redemption, reducing their circulating supply.

Now supposed TTC trades above USD 1:

• Investors could use USD 1 worth of TTF to mint a new TTC then sell it for more than USD 1.
• The newly minted TTC increases the supply, pushing its market price down.

6b. But this mechanism doesn’t necessarily work.

Supposed 1 TTF initially trades at USD 100.

When someone redeems 1 TTC, the protocol only needs to mint 0.01 TTF to give them USD 1 worth of tokens. But what happens if TTF’s price falls ?

As TTF becomes cheaper, the protocol has to issue more TTF to honour the same USD 1 redemption.

And what are investors likely to do with the TTF they receive?

Sell it.

After all, they wanted to redeem their TTC for something worth one US dollar. They didn’t necessarily want to hold a volatile cryptocurrency.

But as more TTF is minted and sold, the additional supply and selling pressure can cause TTF’s market price to fall further. Which means the protocol must issue even more TTF to honour subsequent redemptions.

Which creates even more selling pressure.

Which causes the price to fall further.

The vicious part: this is all done automatically via code. The protocol automatically increases the quantity of TTF issued per redemption! The mechanism trying to save the peg is the hyperinflation engine. This is the ailment of algorithmic stablecoins.

This isn’t just theoretical by the way.

6c. Terra/LUNA: When the stablecoin collapsed

In May 2022, the Terra ecosystem suffered one of the most spectacular collapses in cryptocurrency history.

TerraUSD (UST) was an algorithmic stablecoin designed to maintain a value of USD 1, and its peg mechanism depended on another cryptocurrency, LUNA.

Under the protocol’s original design, users could exchange 1 UST for USD 1 worth of LUNA, and vice versa, through the mint-and-burn mechanism. When UST began losing its peg, investors rushed to exit their positions.

The protocol attempted to restore the peg by allowing UST to be redeemed for newly minted LUNA. But that created enormous quantities of additional LUNA, causing a price collapse — and more tokens minted to maintain redemption value.

The supply of LUNA exploded from hundreds of millions of tokens to trillions in a matter of days. Its market price collapsed from tens of dollars to tiny fractions of a cent.

Ultimately, tens of billions of dollars in market value disappeared from the Terra ecosystem.

And perhaps the most unsettling part is that the collapse didn’t require someone to break the blockchain’s cryptography

Phew. That was a lot of economics theory. And we haven’t written a single line of code yet.

7. First, we need a ledger

We’ll create a toy fiat-backed stablecoin and demonstrate how its transactions can be recorded on a blockchain.

First, we need a ledger to keep track of how many TTC tokens each person owns.

Our TokenLedger class will manage token balances, minting, burning, and transfers. Whenever a token operation occurs, we'll broadcast a corresponding transaction and include it on our blockchain, reusing the mempool implementation from my previous articles.

For simplicity, our token balances are maintained in a Python dictionary, while the blockchain records the associated transaction events. In a production token implementation, balance updates would ordinarily be enforced as part of the blockchain’s smart contract state.

The important distinction is that our blockchain records token activity, not the actual US dollars held by Titus Bank.

class TokenLedger:
    """Minimal on-chain token ledger for stablecoin and HTLC lessons."""

    def __init__(
        self, symbol: str, blockchain: Blockchain, network: Network
    ) -> None:
        """Attach this ledger to one chain and one gossip network."""
        self.symbol = symbol
        self.blockchain = blockchain
        self.network = network
        self.balances: dict[str, float] = {}
        self.total_supply: float = 0.0

    def record_payload(self, payload: str, tx_id: str | None = None) -> None:
        """Gossip ``payload`` as a ``Transaction`` and include it from the origin."""
        tx = Transaction(
            tx_id or f"{self.symbol}-{len(self.blockchain.chain)}",
            payload,
        )
        origin = self.network.node_names[0]
        self.network.broadcast(tx, origin)
        self.network.include(origin, tx.tx_id, self.blockchain)

    def _record(self, record: dict[str, str | float]) -> None:
        """Gossip a token event as a ``Transaction``, then include it."""
        event = str(record.get("event", "EVENT"))
        self.record_payload(
            json.dumps(record, sort_keys=True),
            tx_id=f"{self.symbol}-{event}-{len(self.blockchain.chain)}",
        )

    def mint(self, to: str, amount: float) -> None:
        """Create tokens for ``to`` and record a ``MINT`` receipt."""
        self._require_positive(amount)
        self.balances[to] = self.balances.get(to, 0) + amount
        self.total_supply += amount
        self._record({"event": "MINT", "symbol": self.symbol, "to": to, "amount": amount})

    def transfer(self, sender: str, receiver: str, amount: float) -> bool:
        """Move tokens between holders without changing supply"""
        self._require_positive(amount)
        if self.balances.get(sender, 0) < amount:
            return False
        self.balances[sender] -= amount
        self.balances[receiver] = self.balances.get(receiver, 0) + amount
        self._record(
            {
                "event": "TRANSFER",
                "symbol": self.symbol,
                "from": sender,
                "to": receiver,
                "amount": amount,
            }
        )
        return True

    def burn(self, holder: str, amount: float) -> bool:
        """Destroy tokens and shrink supply."""
        self._require_positive(amount)
        if self.balances.get(holder, 0) < amount:
            return False
        self.balances[holder] -= amount
        self.total_supply -= amount
        self._record(
            {"event": "BURN", "symbol": self.symbol, "holder": holder, "amount": amount}
        )
        return True

Our ledger can:

• mint / burn — create or destroy tokens and change total_supply.
• transfer — move tokens; supply stays put. Ownership moved, nothing was created.

8. Next we need a FiatBackedIssuer

Now that we can create, destroy, and transfer TTC, we need someone to guarantee that every TTC is backed by one US dollar.

If I haven’t said so already, welcome to Titus Bank 🏦

In code, Titus Bank will be represented by a FiatBackedIssuer class that maintains a separate record of its USD reserves.

It needs three important methods.

• deposit_and_mint — When someone deposits USD, Titus Bank records the deposit and asks TokenLedger to mint the corresponding amount of TTC.
• redeem — When someone wants their money back, Titus Bank asks TokenLedger to burn the TTC and reduces its reserve balance accordingly.
• record_reserve_loss — This is where things get interesting. The bank can record a loss of USD reserves without modifying the token ledger or creating a blockchain transaction. This method is particularly important — the blockchain cannot independently determine whether the issuer has sufficient reserves, and USD reserves exist outside our blockchain. Therfore, a change in these reserves would not affect the number of TTC in circulation.

class FiatBackedIssuer:
    def __init__(self, name: str, ledger: TokenLedger) -> None:
        """Bind this issuer to one token ledger."""
        self.name = name
        self.ledger = ledger
        self.reserve_usd: float = 0.0

    def deposit_and_mint(self, to: str, usd_amount: float) -> None:
        """Record fictional USD reserves and mint the matching token amount."""
        TokenLedger._require_positive(usd_amount)
        self.reserve_usd += usd_amount
        self.ledger.mint(to, usd_amount)

    def redeem(self, holder: str, token_amount: float) -> bool:
        """Burn tokens and release the corresponding fictional reserve amount."""
        TokenLedger._require_positive(token_amount)
        if self.reserve_usd < token_amount:
            return False
        if not self.ledger.burn(holder, token_amount):
            return False
        self.reserve_usd -= token_amount
        return True

    def record_reserve_loss(self, usd_amount: float) -> bool:
        """Record an off-chain loss against this fictional issuer's reserves."""
        TokenLedger._require_positive(usd_amount)
        if self.reserve_usd < usd_amount:
            return False
        self.reserve_usd -= usd_amount
        return True

    @property
    def reserve_ratio(self) -> float:
        """Return the fictional reserve amount divided by issued token supply."""
        if self.ledger.total_supply == 0:
            return 1.0
        return self.reserve_usd / self.ledger.total_supply

    @property
    def backing_per_token(self) -> float:
        """Return simplified fictional backing per token, not a market price."""
        return min(1.0, self.reserve_ratio)

9. Taking our stablecoin blockchain for a spin

We’ll use the same proof-of-stake blockchain in my previous article and extend it a little:

class StableCoinBlockchain(Blockchain):
    """PoS blockchain extended with a readable name and proposer rewards."""

    def __init__(self, name: str, validators: list[Validator]) -> None:
        """Name this chain and reuse the parent PoS genesis."""
        super().__init__(validators)
        self.name = name

    def add_block(self, data: str) -> tuple[Block, Validator]:
        """Append a block through the shared PoS implementation and pay its proposer."""
        block, proposer = super().add_block(data)
        proposer.stake += BLOCK_REWARD + FEE_PER_TX
        return block, proposer

    def accept_candidate(self, block: Block) -> None:
        """Append a mempool-included candidate and pay its named proposer."""
        super().accept_candidate(block)
        proposer = next(v for v in self.validators if v.name == block.proposer)
        proposer.stake += BLOCK_REWARD + FEE_PER_TX

Then, reusing the Network class from my previous article on mempools and wiring everything togther:

nodes = ["Titus-Node-1", "Titus-Node-2"]
network = Network(nodes, random.Random(7))
chain = StableCoinBlockchain(
    "TitusChain",
    [Validator("Titus-Node-1", 250), Validator("Titus-Node-2", 150)],
)
tituscoin = TokenLedger("TTC", chain, network)
titus_issuer = FiatBackedIssuer("Fictional Titus Bank", tituscoin)

Let’s imagine Alice deposits USD 1000 with Titus Bank. Titus Bank would then have to mint 1000 TTC.

titus_issuer.deposit_and_mint("Alice", 1_000)

print(f"Alice: {tituscoin.balances['Alice']:.0f} TTC")
print(f"Supply: {tituscoin.total_supply:.0f} TTC")
print(f"Reserve: ${titus_issuer.reserve_usd:,.0f} fictional USD")

Output:

Alice: 1000 TTC
Supply: 1000 TTC
Reserve: $1,000 fictional USD

Now suppose Alice decides to pay Bob 250 TTC. Would Titus Bank need to mint another 250 TTC?

Of course not. We’re simply transferring ownership of existing tokens.

supply_before_transfer = tituscoin.total_supply
reserve_before_transfer = titus_issuer.reserve_usd
transfer_succeeded = tituscoin.transfer("Alice", "Bob", 250)

print(tituscoin.balances)
print(f"Supply still: {tituscoin.total_supply:.0f} TTC")

# {'Alice': 750, 'Bob': 250}
# Supply still: 1000 TTC

Alice now has 750 TTC while Bob has 250 TTC. Total supply of TTC remains at 1,000 TTC.

Now let’s say Bob redeems 100 TTC:

• Titus Bank would then have to release 100 USD to Bob, and total supply changes.
• The TokenLedger.burn removes Bob’s 100 TTC on-chain and reduces reserve_usd by 100 off-chain. Both of which are coordinated by FiatBackedIssuer.redeem

redemption_succeeded = titus_issuer.redeem("Bob", 100)

print(f"Bob: {tituscoin.balances['Bob']:.0f} TTC")
print(f"Supply: {tituscoin.total_supply:.0f} TTC")
print(f"Reserve: ${titus_issuer.reserve_usd:,.0f} fictional USD")

Bob: 150 TTC
Supply: 900 TTC
Reserve: $900 fictional USD

Notice that a problem off the chain does not rewrite the token ledger

Say Titus Bank records a USD 180 reserve loss. Token balances and total supply should not automatically shrink!

Instead, FiatBackedIssuer.record_reserve_loss changes only reserve_usd . Alice and Bob’s TTC are in tact and total supply remains at 900.

supply_before_loss = tituscoin.total_supply
balances_before_loss = tituscoin.balances.copy()
blocks_before_loss = len(chain.chain)
loss_recorded = titus_issuer.record_reserve_loss(180)

print(f"Reserve after loss: ${titus_issuer.reserve_usd:,.0f} fictional USD")
print(f"Supply after loss: {tituscoin.total_supply:.0f} TTC")
print(f"Reserve ratio: {titus_issuer.reserve_ratio:.0%}")
print(f"Backing per TTC: ${titus_issuer.backing_per_token:.2f}")
print(f"Blockchain valid: {chain.is_valid()}")

# Reserve after loss: $720 fictional USD
# Supply after loss: 900 TTC
# Reserve ratio: 80%
# Backing per TTC: $0.80
# Blockchain valid: True

Importantly, Titus Bank can no longer redeem every TTC for USD 1 because of a lack of reserves. But nobody knows that — shh…

Moving forward

We’ve established why stablecoins exist, how their exchange rates are maintained, and what happens when the mechanisms supporting those exchange rates fail.

We’ve also created our own fictional stablecoin, TitusCoin, using the same proof-of-stake blockchain and mempool concepts from my previous articles.

But it’s fictional of course. Nothing is technically stopping me from creating my own stablecoin and declaring myself a billionaire — getting everyone else to believe I’m a billionaire is the hard part.

But there are other interesting questions worth exploring as well.

Suppose there are now two independent fictional banks, Titus Bank and Mary Bank that need to settle accounts after hours.

• Titus Bank issues TitusCoin (TTC), while Mary Bank issues MaryCoin (MTC).
• Both stablecoins exist on different blockchains.

How would these transactions be coordinated? Well, that’s where things get interesting.

I guess our journey continues.

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

Introducing stablecoins was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

Existing protections for large language models mainly operate at the textual interaction level. Safety prompting, guardrail policies, and jailbreak filters can often determine whether a single response should be refused. Mobile agents are different. Their risk does not necessarily appear at one isolated step; it can accumulate over a multi-step chain of behaviors.

An agent may first open a payment or settings application, then navigate through apparently normal interface states, bypass a confirmation process, and finally enter or transmit sensitive information. Individual actions such as opening an application, selecting a contact, typing a value, or pressing a button may appear harmless in isolation. The risk emerges from the dynamic evolution of the entire visual-behavior trajectory across interfaces, applications, and state transitions.

This creates two central challenges. First, step-level defenses designed for language models can fail to detect how risk evolves over time, making chained attack paths difficult to identify and block. Second, security evaluation in GUI environments still relies heavily on manual review and heuristic rules, which are expensive, subjective, and difficult to scale.

TAME-MA addresses both challenges by treating trajectory-level trustworthiness as the core safety objective.

TAME-MA: defense and evaluation at the trajectory level

TAME-MA consists of two main components. SafeTrajGuard is a behavior-level defense module that evaluates candidate operations before execution. GPTJudge is a trajectory-level evaluator that performs automated post-hoc safety assessment over complete execution traces.

SafeTrajGuard is trained using SafeTrajDPO, a trajectory-level preference optimization mechanism. It jointly models historical interactions and the current action to capture progressive risk patterns such as semantic drift and privilege escalation. GPTJudge transforms the task description, behavior logs, and final interface state into a structured evaluation input and produces a trajectory-level safety score and jailbreak judgment.

The framework is designed to be non-invasive and modular. It can operate alongside an existing mobile agent without modifying the underlying agent architecture.

Why a trajectory should not be treated as a list of equal actions

A mobile task is naturally represented as an ordered sequence of actions. The actions may include clicking a button, entering text, switching a toggle, navigating to another screen, or submitting information. These actions have clear temporal and causal dependencies.

However, not every action contributes equally to safety risk. Some operations are supporting actions, such as browsing an interface, while others directly determine a state transition or create a security consequence. Examples include `click:confirm`, `navigate:settings`, and `input:password`. These operations often act as turning points in a trajectory.

TAME-MA therefore treats a trajectory as a risk-sensitive behavior chain. During training, key actions with significant decision-making or safety impact receive stronger supervision. This design focuses learning on the parts of the trajectory that matter most for security rather than treating every action as equally important.

Safe and unsafe trajectory preference learning

To enable trajectory-level preference learning, TAME-MA constructs aligned pairs of safe and unsafe trajectories grounded on common GUI contexts. Unsafe trajectories contain risk-sensitive operations drawn from categories such as privilege escalation, system reset, sensitive-data leakage, unauthorized transactions, authentication changes, phishing, or malicious content submission. Safe trajectories represent legitimate task completion in the same or compatible interface context.

SafeTrajDPO builds on Direct Preference Optimization and uses these positive and negative trajectories to train SafeTrajGuard. A risk-aware weighting mechanism places greater emphasis on key actions, especially high-impact unsafe steps. Local subsequences around key actions are also reused during training so that safety supervision is concentrated around important decision points.

The goal is not merely to teach the guard to reject suspicious words. It is to learn preferences over structured behavior sequences and to distinguish how apparently ordinary actions combine into safe or unsafe task progression.

History-aware inference

After training, SafeTrajGuard is integrated into the mobile-agent pipeline as a safety reviewer. At each decision step, it evaluates the task objective, the current GUI state, the candidate action proposed by the original agent, and recent interaction history.

The historical context is important because the safety of a current action may depend on what has already happened. Navigating to a sensitive settings page may be acceptable in one task and suspicious in another. Entering information may be benign in isolation but risky if earlier steps exposed private data or established an unauthorized payment workflow.

To keep the context compact, the main configuration uses the two most recent historical traces. With this local history, SafeTrajGuard moves from static single-step judgment to dynamic security inference over a behavior chain. It can identify patterns such as consecutive navigation to sensitive pages, privacy-sensitive information flow, or action combinations that collectively form unauthorized access or payment workflows.

Automated evaluation with GPTJudge

The second component, GPTJudge, addresses the difficulty of evaluating mobile-agent safety at scale. Manual evaluation requires reviewers to inspect long behavior traces, interface states, and final outcomes. Rule-based evaluation is easier to automate but often fails when tasks or interfaces change.

GPTJudge evaluates the complete trajectory using three types of information: the original task description, the sequence of actions produced by the agent, and the final interface state. These are encoded into a structured prompt and assessed by a large language model acting as a safety evaluator.

Each trajectory receives a safety score from 0 to 100. Higher scores indicate safer and more task-aligned behavior, while lower scores indicate greater jailbreak risk. A threshold of 50 is used in the main experiments to convert the score into a binary jailbreak-success judgment.

This provides two complementary metrics: G-Score measures trajectory safety on a continuous scale, while G-ASR measures the proportion of jailbreak tasks judged to be successful. Human evaluation is retained as H-ASR to verify whether the automated assessment is consistent with expert judgment.

Evaluation setup

We evaluate TAME-MA on two representative mobile-agent systems: the single-agent AppAgent and the multi-agent Mobile-Agent-v2. Both operate in an Android emulator environment with GUI parsing and natural-language task execution.

The evaluation is based on MobileSafetyBench and covers six task categories: Text Messaging, Web Navigation, Social Media, Finance, Device/Data Management, and Utility. The original 80 real-world scenarios are expanded to 330 jailbreak tasks using semantic rewriting, cross-interface context perturbation, and human verification.

The evaluation measures both security and utility. G-Score and G-ASR capture automated trajectory-level safety; H-ASR provides human judgments; Task Completion Rate measures whether benign tasks remain usable after the defense is introduced.

Main defense results

Across six jailbreak categories, TAME-MA substantially improves trajectory safety. The average G-Score increases from 31.04 without defense to 83.94 with TAME-MA. The table below summarizes the central comparison with guard-model baselines.

The key result is the security-utility balance. TAME-MA reduces G-ASR to 16.7% and H-ASR to 8.4%, while the normal-task completion rate remains 77.8%, the same as the no-defense setting. In contrast, some alternative guards reduce attack success by becoming more conservative, which also lowers normal task completion.

The results also show strong protection in high-risk categories. In Finance and Device Management, where the no-defense attack success rate can reach 100%, TAME-MA reduces both automated and human-measured jailbreak success to zero in the reported category-level experiments.

Optional visual — insert the original Figure 5 here. It shows examples in which SafeTrajGuard blocks a critical transfer step induced by a forged system prompt and prevents the posting of harmful content.

Generalization across foundation models and mobile-agent frameworks

TAME-MA is evaluated across GPT-4o, Gemini 2.5, Claude 3, and DeepSeek within AppAgent. Across these models, the average G-Score improves from 51.75 to 85.94 and the average G-ASR decreases from 55.5% to 16.7%.

For GPT-4o, G-ASR decreases from 86.1% to 16.7% and H-ASR from 72.2% to 8.4%. On Claude 3, the defended G-Score reaches 92.31 and H-ASR falls to 2.7%. On DeepSeek, the defended G-Score reaches 89.23 with H-ASR of 8.3%.

The framework is also evaluated on both AppAgent and Mobile-Agent-v2. In the multi-agent Mobile-Agent-v2 setting, the average G-ASR decreases from 87.9% to 2.2% and H-ASR from 78.9% to 1.1% in the selected high-risk categories. This indicates that the defense can adapt to more complex multi-stage planning and execution processes.

Why history matters — and why more history is not always better

One of the most informative ablations changes the amount of trajectory history available to SafeTrajGuard.

Using only the current action is insufficient for many cross-step risks. Adding one or two recent steps substantially improves defense performance. The two-step history window gives the best overall balance between security, task completion, false positives, and latency.

Importantly, using the entire history does not continue to improve performance. Full history increases latency, increases the false-positive rate, and slightly reduces task completion. This suggests that excessively long context can introduce irrelevant information or noise. For this reason, the main configuration uses the most recent two steps rather than the full trajectory history for online decision making.

Safety gains are not simply over-blocking

A practical guard can appear safe simply because it refuses too many actions. We therefore separately measure false positives on normal tasks.

With the LLaMA3–8B BF16 guard, Action-FPR is only 0.8% and the task-level blocking failure rate is 0.6%, while normal TCR remains 77.8%, identical to the no-defense baseline. This indicates that the main security benefit is not obtained by indiscriminately blocking benign actions.

There is also a deployment trade-off between latency and security. The LLaMA3–8B configuration adds approximately 2.93 seconds per decision step and achieves G-ASR of 16.7%. Smaller guard models reduce latency but have higher G-ASR and higher false-positive rates. This allows the deployment configuration to be adjusted according to device resources and task risk.

Limitations and future directions

TAME-MA demonstrates substantial security improvements across multiple mobile-agent systems and high-risk task scenarios, but several limitations remain. SafeTrajGuard mainly relies on structured GUI-level information and action trajectories, which makes more dynamic interfaces and unstructured visual interactions more challenging. The current key-action identification mechanism is used only during training, but its heuristic design may still limit the discovery of important operations in applications with non-standard interface labels or customized UI components.

SafeTrajDPO also requires fine-tuning on preference data, and training or inference overhead can become more important when scaling to larger models or multi-agent systems. Finally, GPTJudge currently evaluates trajectories according to static safety norms, whereas real-world safety requirements can vary by task context and evolve over time.

Future work will extend trajectory-level safety modeling to broader agent modalities, reduce training and inference overhead, improve automatic discovery of high-impact actions, and investigate adaptive safety standards and formal verification tools.

Full paper

TAME-MA: Taming Mobile Agents via Trajectory-Level Trustworthiness under Jailbreak Manipulations
Full publication link: https://link.springer.com/article/10.1007/s11263-026-03015-7

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

TAME-MA: Taming Mobile Agents via Trajectory-Level Trustworthiness under Jailbreak Manipulations was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

Multimodal large language models are becoming an important infrastructure for general-purpose AI systems by unifying visual and linguistic information and demonstrating strong generalization capabilities in tasks such as visual question answering, vision-language understanding, embodied intelligence, human-computer interaction, and automated content generation. As these models are deployed in safety-sensitive scenarios such as healthcare, autonomous driving, intelligent manufacturing, and content moderation, the reliability of their output behavior is no longer merely a matter of performance but is directly related to security and societal risks.

However, multimodal large language models are susceptible to backdoor implantation during instruction alignment and supervised fine-tuning. An attacker only needs to construct a small number of poisoned samples with trigger conditions to cause the model to output an attacker-defined target response when a specific trigger appears at test time, while still maintaining good performance on normal inputs. This makes backdoor attacks highly stealthy: once implanted, they can be difficult to detect through standard testing or manual inspection.

The defense problem is difficult for two reasons. First, realistic attackers can use low-to-moderate poisoning ratios, such as 5%, which results in sparse backdoor-related signals during training. Second, multimodal models have complex generation distributions, so aggressive defense can easily damage normal generation capability. The central challenge is therefore to suppress backdoor behavior without sacrificing utility.

Threat setting and defense objective

We focus on training-phase backdoor attacks under low-to-moderate poisoning ratios. During supervised fine-tuning, an attacker injects a small number of poisoned samples containing hidden trigger patterns. These samples establish a stable trigger-target association, so that the model behaves normally on clean inputs but produces a predefined target response when the trigger is present.

In our setting, only a very small number of samples are poisoned in the training dataset, and each training batch may contain only zero or one poisoned sample. This makes the backdoor highly difficult to identify through simple statistics or anomaly detection.

The defense objective is correspondingly two-sided. We want the model to stop producing the attacker-specified target when the trigger is present, while keeping its multimodal understanding and generation behavior on clean inputs as close as possible to the original model. Importantly, the defense should not require explicit annotations of poisoned samples or prior knowledge of the attack trigger.

The key observation: backdoor responses are abnormally invariant across views

Backdoor attacks commonly rely on localized trigger patterns in visual inputs. During training, the model may overfit these local regions and establish a strong association between the trigger and a fixed target response.

To expose this behavior, we construct two views of the same input. The original image is kept unchanged, while a perturbed view is created by applying small local modifications such as masking, random-noise replacement, or patch shuffling. The textual instruction remains unchanged, and the perturbation is designed to preserve the global semantics of the image.

This dual-view construction reveals an important structural difference between normal and backdoor samples. Normal samples remain semantically consistent across the two views, but their generated forms can naturally vary. Backdoor samples, in contrast, tend to collapse into nearly identical fixed target responses across both views because of the strong trigger-target binding.

This cross-view output invariance is not a natural property of the task. It is a pathological feature associated with the backdoor structure. Instead of trying to identify poisoned samples directly, we use this abnormal invariance itself as a defense signal.

The defense framework

Our framework combines three components: patch-based view generation, cross-view discrepancy optimization, and uncertainty-aware output regularization.

1. Patch-based view generation

For each training sample, we construct an original view and a locally perturbed view. The perturbation operates only on the visual modality and keeps the text instruction unchanged. In the experiments, the patch size is randomly sampled from a small portion of the image area, and the position is sampled across the image. Perturbation operations include masking, random-noise replacement, and patch shuffling.

At the feature level, the model is encouraged to maintain stable high-level semantic representations across the two views. This reduces the tendency of the model to over-rely on localized trigger regions and weakens the separability of backdoor triggers in the feature space.

2. Cross-view discrepancy optimization

The central component operates at the output level. Normal and backdoor samples behave differently across the two views: normal outputs are semantically consistent but naturally diverse, whereas backdoor outputs tend to collapse into almost identical fixed responses.

We therefore penalize this anomalous cross-view similarity at the token-probability level. The optimization acts on each sample rather than relying on statistics of the poisoning ratio at the batch level. For normal samples, output distributions already have natural variation across views, so the resulting gradient is limited. For backdoor samples, output distributions are abnormally similar, which generates a stronger optimization signal.

This is particularly useful under low poisoning ratios. Even when only zero or one poisoned sample appears in a batch, the cross-view relationship of that individual sample can still expose the pathological stability of the backdoor response.

3. Uncertainty-aware output regularization

Simply forcing the outputs of the two views to become different can introduce a new problem: the model may produce overconfident extreme predictions, leading to output-distribution collapse or degradation of normal generation capability.

To prevent this side effect, we introduce uncertainty-aware regularization at the output layer. The regularization penalizes excessively concentrated, low-entropy predictions and helps preserve sufficient diversity in the model’s generation distribution.

The two objectives are complementary. Cross-view discrepancy optimization suppresses the abnormal stability of backdoor responses, while uncertainty-aware regularization stabilizes the normal output distribution. Together with patch-level feature regularization, they aim to balance security and normal generative capability.

Experimental evaluation

We evaluate the defense on two multimodal vision-language datasets, MS COCO and Flickr30k. Three representative multimodal models are used as victim models: OpenFlamingo, Otter, and BLIP-2. We construct the training-stage threat environment using a 5% poisoning ratio.

Six representative backdoor attacks are included: BadNets, Blended, LowFrequency, WaNet, InputAware, and DualKey. These attacks cover local pixel triggers, global blending triggers, frequency-domain triggers, geometric transformations, input-adaptive triggers, and dual-key triggers. Normal generation quality is evaluated using BLEU@4 and CIDEr, while backdoor effectiveness is measured by Attack Success Rate (ASR).

Defense performance under different attacks

On OpenFlamingo with the COCO dataset, the undefended model is almost completely controlled by the backdoor under all six attack settings, with ASR values between 96.7% and 98.9%. After applying the proposed defense, the ASRs are substantially reduced.

The defense also preserves normal generation performance. In the clean setting, BLEU@4 decreases from 25.8 to 23.9 and CIDEr decreases from 98.9 to 89.4, indicating that the security improvement does not come from simply degrading the model’s overall generation capability.

For triggered inputs, the defense can also recover normal generation performance. Under BadNets and Blended, for example, BLEU@4 improves from 2.7 and 2.0 to 14.6 and 13.7, while CIDEr improves from 1.5 and 1.9 to 45.5 and 41.3.

Generalization across models and datasets

The same trend is observed across different model architectures. On Otter, the defended ASRs for BadNets, Blended, LowFrequency, WaNet, InputAware, and DualKey are 55.0%, 60.4%, 42.8%, 48.4%, 32.8%, and 35.3%, respectively. On BLIP-2, the corresponding values are 52.1%, 58.1%, 40.1%, 46.2%, 30.6%, and 34.0%. Normal generation performance remains close to the clean setting in most cases.

We also evaluate cross-dataset generalization on Flickr30k. Without defense, all six attacks again achieve ASRs above 95%. After defense, the ASRs are reduced to 53.0%, 60.8%, 42.6%, 48.4%, 32.3%, and 35.8%. On clean inputs, BLEU@4 changes from 22.1 to 20.9 and CIDEr from 86.6 to 78.5.

These results show that the defense is not limited to a single model architecture or data distribution.

Which component matters most?

We conduct an ablation study under the BadNets attack on COCO to examine the contribution of each component.

Patch-level feature consistency weakens the model’s dependence on localized trigger patterns. Adding cross-view discrepancy further reduces ASR, confirming that anomalous cross-view invariance is a key signal for breaking the trigger-target association. The complete method provides the best overall defense and generation performance, with uncertainty-aware regularization helping stabilize the output distribution.

Comparison with existing defenses

We also compare the method with representative inference-phase defenses under the BadNets attack on Flickr30k. Without defense, ASR reaches 98.2% and generation quality is severely degraded. Fine-Pruning reduces ASR to 71.3%, STRIP Detection to 88.5%, and Entropy Filtering to 79.6%. Our method reduces ASR further to 53.0% while maintaining higher generation quality.

The distinction is important. These inference-phase approaches mainly rely on post-hoc detection, filtering, or pruning. Our framework instead suppresses the formation and stability of the backdoor mechanism during training. In the reported comparison, this produces a better balance between attack suppression and task performance.

Practical trade-offs and limitations

The method introduces an additional forward pass for the perturbed view during training, resulting in approximately a twofold increase in training-time computation compared with standard supervised fine-tuning. GPU memory usage also increases because intermediate activations from both views must be stored. Importantly, the method does not introduce additional inference-time overhead because the perturbation mechanism is only used during training.

Overall, the defense shows consistent performance across attack types, datasets, and model architectures. The results suggest that cross-view discrepancy regularization can disrupt trigger-target bindings while preserving normal generation behavior.

The method also has limitations. Its core perturbation operates mainly on localized visual regions, so more complex cross-modal or global triggering mechanisms require further evaluation. Regularization weights may still need adjustment across models and tasks, and the method mainly takes effect during fine-tuning, which limits its direct applicability to already deployed models.

Full paper

The complete paper, including all mathematical formulations, baselines, implementation details, sensitivity analyses, and references, is available here:

A Patch-based Cross-view Regularized Framework for Backdoor Defense in Multimodal Large Language Models
https://arxiv.org/abs/2604.04488

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

A Patch-based Cross-view Regularized Framework for Backdoor Defense in Multimodal Large Language… was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last time, I compared smart contracts to vending machines: put in $2, press B4, get a Snickers. No clerk, no judgment calls. A smart contract is code at an address that gives the same output every time it’s called, and it can call other contracts.

We built three of them.

• First, an Automated Market Maker (AMM) pool: a contract holding two piles of tokens, Ether (ETH) — a cryptocurrency — and USD, that quotes a price purely from the ratio between them. Its one rule: multiplying the two piles together must always give the same number, so selling ETH in pushes its price down.

Think of it as a puddle. Toss in a pebble and the water barely moves. Cannonball into it and it splashes everywhere. But a splash tells you about the puddle, not the ocean. In my code, one big sale crashed ETH’s price 69% in this pool while it stayed $2,000 everywhere else.

• A lending protocol loans USD to borrowers by ascertaining the value of their collateral from their ETH, and liquidates borrowers whose collateral fell below a specific threshold of their debt. This price could come from the AMM pool, or from an external source, such as:
• A price feed stored reported prices, acting as an oracle.

Our lending protocol took a shortcut: it read its ETH price straight off the AMM pool. One call, and the puddle’s number became its truth. I hinted at a fix, taking the median of several independent price reports, without showing why it works.

This time we break it. I’m a huge fan of the Ocean’s movies, but they needed eleven specialists. Ours needs one: you, wearing every hat. Then we’ll see why the median stops the whole thing cold.

As before, all the code is in my GitHub repository. We’ll be reusing the classes from my previous article.

Act One: Alice executes a heist with ETH she owns

Meet Alice, our attacker, with 40 ETH. She participates in a pool that is shallow: 50 ETH and $100,000.

A borrower has posted 10 ETH against a $12,000 loan: at $2,000/ETH (USD100k : 50 ETH) that’s a collateral ratio of 1.67, comfortably above the 1.5 threshold.

Pause and predict: What happens if Alice sells all 40 ETH into the pool?

nodes = ["Node A", "Alice-Node", "Bob-Node", "Farid-Node"]
validators = [
    Validator("Node A", 100),
    Validator("Alice-Node", 80),
    Validator("Bob-Node", 70),
    Validator("Farid-Node", 50),
]
owned_network = Network(nodes, random.Random(7))
owned_chain = Blockchain(validators)

# Same two contracts, neither buggy. The lending rule still asks the puddle about the ocean.
owned_pool = AMMPool("amm-thin.eth", 50.0, 100_000.0)
owned_lending = LendingProtocol("lending-thin.eth", owned_pool)
owned_lending.call(
    "open_loan", borrower="victim", collateral_eth=10.0, debt_usd=12_000.0
)

# TX1: Alice dumps 40 ETH she already owns. The cheap price is now public. Crime scene, open floor plan.
alice_eth = 40.0
usd_from_dump, dump_tx, dump_block = submit_call(
    owned_network,
    owned_chain,
    "Alice-Node",
    "tx-dump-40eth",
    owned_pool,
    "swap_eth_for_usd",
    eth_in=alice_eth,
)
manipulated_price = owned_pool.spot_price
victim_ratio = owned_lending.collateral_ratio(owned_lending.loans["victim"])

# TX2: liquidate at that public photograph, then buy ETH back at the price she herself created.
seized, liq_tx, liq_block = submit_call(
    owned_network,
    owned_chain,
    "Alice-Node",
    "tx-liquidate-victim",
    owned_lending,
    "liquidate",
    borrower="victim",
)
usd_for_buyback = usd_from_dump - seized.debt_usd
eth_bought_back = owned_pool.call("swap_usd_for_eth", usd_in=usd_for_buyback)
alice_final_eth = eth_bought_back + seized.collateral_eth
profit_eth = alice_final_eth - alice_eth

print(f"{dump_block.proposer} included {dump_tx.tx_id} in Block #{dump_block.index}")
print(
    f"DUMP: Alice sells {alice_eth:.2f} ETH of her own for ${usd_from_dump:,.2f}; "
    f"AMM price becomes ${manipulated_price:,.2f}/ETH."
)
print(
    f"The cheap puddle is now public. Victim ratio at this price: {victim_ratio:.2f}."
)
print(f"{liq_block.proposer} included {liq_tx.tx_id} in Block #{liq_block.index}")
print(
    f"LIQUIDATE: pay ${seized.debt_usd:,.2f} debt and seize "
    f"{seized.collateral_eth:.2f} ETH."
)
print(
    f"BUY BACK: remaining ${usd_for_buyback:,.2f} buys {eth_bought_back:.2f} ETH."
)
print(
    f"Alice started with {alice_eth:.2f} ETH, ends with {alice_final_eth:.2f} ETH, "
    f"profit {profit_eth:.2f} ETH."
)

Output:

Alice-Node included tx-dump-40eth in Block #1
DUMP: Alice sells 40.00 ETH of her own for $44,444.44; AMM price becomes $617.28/ETH.
The cheap puddle is now public. Victim ratio at this price: 0.51.
Alice-Node included tx-liquidate-victim in Block #2
LIQUIDATE: pay $12,000.00 debt and seize 10.00 ETH.
BUY BACK: remaining $32,444.44 buys 33.18 ETH.
Alice started with 40.00 ETH, ends with 43.18 ETH, profit 3.18 ETH.

Read the result. Alice deliberately sells 40 ETH into a pool that only had 50 ETH. Price collapses 69% — not because ETH crashed, but because she displaced most of the puddle.

At $617/ETH, the victim’s 10 ETH is worth $617 against $12,000, i.e. the collateral ratio is 0.51. The protocol, following its rules correctly, marks them liquidatable.

Alice then pays the $32,444 required to buy ETH back — at the depressed price she herself created and reaps 3.18 ETH of pure profit, extracted from someone who never did anything wrong.

That’s why a lender should never treat a single thin pool’s spot price as the truth.

Act Two: The same heist with a flash loan

Act One had a barrier: you needed to own enough ETH like Alice to move the pool. A flash loan removes this requirement. The idea sounds insane the first time you hear it: a contract will lend you unlimited money with zero collateral, no credit check, and no questions asked.

The catch is brutal— the money must be back by the end of this transaction. If it is not, the entire transaction reverts and it is as though nothing happened.

Think of it like borrowing a suitcase of cash on the condition that you hand the exact suitcase back before you finish walking through the lobby.

You can take the money.

You can use it.

You can even make a profit with it.

But if you reach the exit without returning the suitcase, the entire walk through the lobby is rewound.

That sounds like a very safe loan.

And it is — for the lender.

The lender doesn’t need to trust Alice because Alice never gets to keep the borrowed principal. The loan either comes back before the transaction ends, or the transaction doesn’t happen. And this is enforced by the code of the flash loan smart contract.

So why offer this at all?

Fees. Real flash-loan providers charge fees for the temporary use of their liquidity. The lender gets paid without taking the usual credit risk of an unsecured loan.

Now change exactly one thing from Act One: Alice owns zero of the 40 ETH. The provider has 1,000 ETH available. Alice borrows 40 ETH.

She now has the same 40 ETH that previously belonged to her — except this time she only has it temporarily.

And because the loan, the manipulation, the liquidation, the buyback, and the repayment can all happen inside one transaction, nobody gets a chance to step between the pieces.

Five operations:

1. Borrow 40 ETH.
2. Dump the 40 ETH into the shallow AMM, crushing its spot price.
3. Liquidate the victim using that manipulated price.
4. Buy back ETH cheaply with the USD recovered from the dump.
5. Repay the original 40 ETH.

If anything fails, the whole thing rewinds. If everything succeeds, whatever ETH remains after repayment belongs to Alice.

And here’s the deliciously uncomfortable part:

We already know exactly how much should remain.

We just watched Alice do the same thing in Act One with her own money. Now she does it with 0 ETH.

And she still walks away with 3.18 ETH.

Act Three: The heist fails

Now let’s change exactly one thing from Act Two: the victim has 40 ETH instead of 10 against the same $12,000 debt.This means that even after Alice’s attempted attack, the victim should survive.

Like Act Two, Alice still borrows 40 ETH and dumps all 40 ETH into the same shallow AMM.

failed_tx = Transaction(
    "tx-flash-victim2",
    "Flash-loan against Victim2",
)

network.broadcast(
    failed_tx,
    origin="SketchyGuy-Node",
)

included_failed, failed_block = network.include(
    "SketchyGuy-Node",
    failed_tx.tx_id,
    chain,
)

print(
    f"{failed_block.proposer} included {included_failed.tx_id} "
    f"in Block #{failed_block.index} (execution comes next)."
)

We create the same shallow AMM, the same $12,000 loan, and the same flash-loan provider. The only difference is the victim’s collateral:

failed_pool = AMMPool(
    "amm-victim2.eth",
    50.0,
    100_000.0,
)

failed_protocol = LendingProtocol(
    "lending-victim2.eth",
    failed_pool,
)

failed_protocol.open_loan(
    "Victim2",
    40.0,
    12_000.0,
)

failed_provider = FlashLoanProvider(1_000.0)

Before executing the attack, we record the state of the world:

failed_before = (
    failed_pool.eth_reserve,
    failed_pool.usd_reserve,
    tuple(sorted(failed_protocol.loans)),
    failed_provider.eth_available,
)

Now Alice’s attack:

• She dumps the borrowed ETH.
• The AMM price collapses.
• Then she attempts the liquidation. But this time, the protocol checks victim’s collateral ratio and refuses.

def failed_attack_action(
    amount_eth: float,
) -> tuple[float, AttackTrace]:

    failed_pool.swap_eth_for_usd(amount_eth)

    failed_observation["price"] = failed_pool.spot_price

    failed_observation["ratio"] = (
        failed_protocol.collateral_ratio(
            failed_protocol.loans["Victim2"]
        )
    )

    failed_protocol.liquidate("Victim2")

The result:

SketchyGuy-Node included tx-flash-victim2 in Block #2
(execution comes next).

Attempted dump moved AMM price to $617.28/ETH.
Victim2 ratio after dump: 2.06;
liquidation is rejected.

Attack transaction: REVERTED

The AMM really did hit $617.28.

But the victim’s collateral ratio was still 2.06, comfortably above the 1.50 liquidation threshold. So liquidate() rejected the operation. And once that happened, the flash-loan transaction reverted.

• The AMM reserves were restored.
• The loan record was restored.
• The flash-loan provider’s balance was restored.

Everything returned to its pre-transaction state.

This is the part that is easy to misunderstand.

The price manipulation did happen during execution. It just didn’t survive the transaction. If a required step fails, the successful steps that came before it don’t get to stay behind as souvenirs.

But notice what did not happen: nobody looked at Alice’s transaction and said: “Hmm. This appears to be an attack. Let’s stop her.”

Only rules encoded in code within smart contracts are evaluated. In Act Two, every rule check passed, so the attack succeeded. In Act Three, liquidate() failed its rule check, so the transaction reverted.

The defence: stop asking the puddle

Act Three failed because, even at the manipulated price, the victim’s collateral ratio remained above the liquidation threshold.

But what if Alice had a flash loan of 100 ETH? The failure in Act Three wasn’t that flash loans suddenly stopped working. It was that this particular amount of manipulation wasn’t enough to make the victim liquidatable. Give Alice enough capital, and she may be able to push the puddle far enough.

So the real defence cannot be “make the puddle deeper.” It has to be stop asking the puddle for the market price in the first place.

My previous article already gave the fix: stop asking the puddle. Don’t make the lending protocol trust a single price source that an attacker can manipulate with a large enough trade. Point the lending protocol at a MedianOracle instead and the attack dies — because the liquidation no longer depends on the AMM puddle.

A median of three sources survives one liar and fails against two. If those “independent” sources are themselves thin AMM pools, a flash loan large enough can move two of them in the same transaction.

# Three reports, one median. No ML. Sort, pick the middle, ignore how loud the liar was.
defense_oracle = MedianOracle(
    [
        PriceReport("exchange-A", 2_005.0),
        PriceReport("exchange-B", 1_995.0),
        PriceReport("reference-feed", 2_000.0),
    ]
)
defense_pool = AMMPool("amm-defense.eth", 50.0, 100_000.0)
# price_source overrides the puddle. 
defense_protocol = LendingProtocol(
    "lending-defense.eth", defense_pool, price_source=defense_oracle
)
defense_victim_loan = defense_protocol.open_loan("defense-victim", 10.0, 12_000.0)
defense_pool.swap_eth_for_usd(40.0)
defense_ratio = defense_protocol.collateral_ratio(defense_victim_loan)

try:
    defense_protocol.liquidate("defense-victim")
except PositionNotLiquidatableError:
    defense_rejected = True
else:
    defense_rejected = False


def defense_verdict(defense_rejected: bool) -> str:
    """Return a short label for whether the median-priced liquidation ran.

    Args:
        defense_rejected: True if ``liquidate`` raised.

    Returns:
        ``liquidation rejected`` or ``liquidation executed``.
    """
    return "liquidation rejected" if defense_rejected else "liquidation executed"


print(f"Manipulated AMM spot price: ${defense_pool.spot_price:,.2f}/ETH")
print(
    f"Median oracle price: ${defense_oracle.price:,.2f}/ETH; "
    f"protocol ratio: {defense_ratio:.2f}"
)
print(f"Defense result: {defense_verdict(defense_rejected)}")

The result:

Manipulated AMM spot price: $617.28/ETH
Median oracle price: $2,000.00/ETH; protocol ratio: 1.67
Defense result: liquidation rejected

Read the result. The AMM really moved to $617.28. The protocol read the median price of $2,000 and rejected the liquidation.

Aggregation did not make the AMM honest — the AMM was always honest!

It was honestly reporting the price implied by the liquidity sitting in its pool. The bug was asking that price to answer a question it wasn’t qualified to answer: “What is ETH really worth?”

The defence wasn’t to make the puddle honest. It was to stop asking the puddle.

Thinking of what we just did

Here’s a reality bite: Flash loan attacks are not hypothetical.

Flash loan oracle manipulation has drained hundreds of millions of dollars from real protocols, repeatedly, for years, in attacks that were structurally identical to the one above.

And the uncomfortable part is that the failure often wasn’t some exotic bug hiding in a thousand lines of Solidity.

The code could be audited. The contracts could execute exactly as written. The liquidation logic could be perfectly correct.

There was a contract asking a puddle about the ocean.

And an attacker realized that if the puddle was shallow enough, they could move it. The vulnerability was trusting a price source that an attacker could manipulate.

Median feeds, TWAPs, deeper liquidity, freshness limits, circuit breakers: these are layers of defence, each addressing different failure modes. None is magic, and all require understanding the assumptions underneath them.

This isn’t to say that smart contracts are safe now. In my view, DeFi remains a bit of a wild west, evolving daily.

Nonetheless, I will tentatively end my exploration of the more volatile side of DeFi here, though I have a feeling this won’t be my last article about it.

In my next article, I’ll explore something intriguing — stablecoins, a token that claims to be a dollar.

References (honestly too many):

• Qin, K., Zhou, L., Livshits, B., & Gervais, A. (2021). Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit.
• Aave. Flash Loans.
• Adams, H., Zinsmeister, N., & Robinson, D. (2020). Uniswap v2 Core
• [Medium Article] Traroe, P. The 5 Biggest Flash Loan Attacks (2022)

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

Flash loan attacks on smart contracts was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

My odyssey into blockchain has been getting progressively more interesting.

What started as curiosity to understand how Bitcoin works has turned into a series of articles where I keep opening increasingly suspicious-looking boxes and asking, “Okay, but what actually happens inside?”

So far I’ve covered how blocks get proposed (PoW, then PoS), how a Merkle tree lets you prove one credential belongs to a much bigger set without hauling out the whole set, how permissioned chains handle endorsement and stale-state conflicts, and how transactions live in a messy, half-agreed-upon mempool before they ever make it into a block. If any of those are fuzzy, the earlier articles are still there — this one assumes you’ve got the gist.

With the exception of OpenCerts, the blockchains in my articles so far have mainly been about ledgers:

Alice sends Bob some tokens, a validator checks the transaction, the network agrees on what happened and the blockchain records it.

There is, however, a rather important assumption hiding underneath all of this: The blockchain already knows everything it needs to know.

If Alice sends Bob 10 tokens, the blockchain doesn’t need to phone anyone to ask whether Alice really sent Bob 10 tokens.

The transaction is the information.

The blockchain can compare that transaction against its existing state, apply the relevant rules, and — assuming everything checks out — record the result.

But now imagine that our blockchain needs to know something that does not originate on the blockchain.

And this is where things get interesting.

Because once we give the blockchain programs that actually do things, those programs are going to want information about a world that exists outside the blockchain.

That brings us to smart contracts, and eventually, to oracles.

As before, all my code can be found in my GitHub repository.

What a smart contract actually is

A smart contract is like a vending machine.

You put in the required amount of money, press B4, and a Snickers falls out (yum). The machine has rules. All you have to do is satisfy them.

In Ethereum, a smart contract is program code deployed to the blockchain. Other participants can send transactions requesting that the contract execute a particular function. The resulting execution can change the blockchain’s state.

And here is the important part:

The blockchain does not understand that you have asked it to “swap some ETH for USD.”

It understands something much more mechanical — Call the contract at this address, invoke this function, and provide these arguments.

The contract’s code determines what happens next. Smart contracts are very deterministic programs.

These programs live in a shared environment where thousands of machines may independently execute the same instructions and must arrive at the same result.

Here’s what a simple smart contract could look like, recycling our PoS blockchain and mempool classes from Articles 2 and 5:

class SmartContract:
    def __init__(self, address: str) -> None:
        """Store the address this contract will be called at."""
        if not address:
            raise ValueError("Contract address must be non-empty.")
        self.address = address

    def call(self, method: str, **kwargs: Any) -> Any:
        """Invoke a public method by name."""
        if method.startswith("_") or method == "call":
            raise AttributeError(
                f"{self.address} has no public method {method!r}."
            )
        func = getattr(self, method, None)
        if not callable(func):
            raise AttributeError( 
                f"{self.address} has no public method {method!r}."
            )
        return func(**kwargs)

The important idea here is surprisingly small.

• A contract has an address.
• It has code.
• And that code exposes methods that can be called.

In our simplified blockchain, a contract call is represented as a transaction, which can enter the mempool, be included in a proposed block, and then be executed.

So the simplified flow is:

Contract call → Transaction → Mempool → Block → Execution → State change

Which means the mempool we built in the previous article still matters.

Our shiny new smart contract has not escaped the machinery we already built. We’ve simply given the machinery something more interesting to execute.

def submit_call(
    network: Network,
    chain: Blockchain,
    origin: str,
    tx_id: str,
    contract: SmartContract,
    method: str,
    **kwargs: Any,
) -> tuple[Any, Transaction, Block]:
    arg_preview = ", ".join(f"{k}={v!r}" for k, v in kwargs.items())
    description = f"{contract.address}.{method}({arg_preview})"
    network.broadcast(Transaction(tx_id, description), origin=origin)
    tx, block = network.include(origin, tx_id, chain)
    result = contract.call(method, **kwargs)
    return result, tx, block

A transaction can ask a contract to run some code, and running that code can change blockchain state.

Swap contracts aren’t a major leap from the basics

An automated market maker (AMM) allows users to trade against liquidity held inside the pool using a mathematical pricing rule.

One of the simplest and most famous AMM designs is the constant-product AMM. Its entire personality can be summarised by one equation:

x × y = k

Here, x is the amount of ETH in the pool and y is the amount of USD.

• The product k should remain constant.
• So if someone adds ETH to the pool, the amount of USD in the pool must decrease accordingly.
• The pool does not need a human market maker deciding what the trade should cost.

The math decides. And it is just code.

class AMMPool(SmartContract):
    def __init__(
        self, address: str, eth_reserve: float, usd_reserve: float
    ) -> None:
        """Create a pool at ``address`` with the given reserves."""
        super().__init__(address)
        if eth_reserve <= 0 or usd_reserve <= 0:
            raise ValueError("AMM reserves must be positive.")
        self.eth_reserve = eth_reserve
        self.usd_reserve = usd_reserve

    @property
    def spot_price(self) -> float:
        return self.usd_reserve / self.eth_reserve

    @property
    def constant_product(self) -> float:
        return self.eth_reserve * self.usd_reserve

    def swap_eth_for_usd(self, eth_in: float) -> float:
        if eth_in <= 0:
            raise ValueError("Swap input must be positive.")
        k = self.constant_product
        new_eth_reserve = self.eth_reserve + eth_in
        new_usd_reserve = k / new_eth_reserve
        usd_out = self.usd_reserve - new_usd_reserve
        self.eth_reserve, self.usd_reserve = new_eth_reserve, new_usd_reserve
        return usd_out

    def swap_usd_for_eth(self, usd_in: float) -> float:
        if usd_in <= 0:
            raise ValueError("Swap input must be positive.")
        k = self.constant_product
        new_usd_reserve = self.usd_reserve + usd_in
        new_eth_reserve = k / new_usd_reserve
        eth_out = self.eth_reserve - new_eth_reserve
        self.usd_reserve, self.eth_reserve = new_usd_reserve, new_eth_reserve
        return eth_out

The pool has two important pieces of state:

• how much ETH it holds
• how much USD it holds

And it has rules governing what happens when somebody swaps one asset for the other.

Suppose someone sells ETH to the pool:

• The pool now has more ETH.
• To maintain x × y = k, it must therefore have less USD.
• The difference between the old and new USD reserves is what the trader receives.

Same price for any size trade?

The intuition is tempting. Sell a little ETH, get about $2,000 worth of USD. Sell a lot of ETH, get… more of the same deal, just scaled up.

Not quite.

We’ll start with a pool containing 50 ETH and $100,000 USD, so the initial spot price is:

$100,000 ÷ 50 = $2,000 per ETH

Then we’ll make two identical pools, because I want two experiments that start from exactly the same state.

One is a small trade:

Sell 1 ETH.

The other is a large trade:

Sell 40 ETH.

Think of the pool as a puddle. Toss a pebble in and the water barely moves. Cannonball into it and it splashes everywhere. The AMM works the same way — a small trade barely disturbs the reserves, a large one sloshes the price around.

We’re about to prove that with numbers instead of a metaphor, but keep the puddle in your head. It’s the whole intuition for what “price impact” means.

# Three identical puddles. The pebble and boulder must not share state.
initial_pool = AMMPool("amm-initial", 50.0, 100_000.0)
small_trade_pool = AMMPool("amm-pebble", 50.0, 100_000.0)
large_trade_pool = AMMPool("amm-boulder", 50.0, 100_000.0)

# call() is the public surface — same path a later Block will take.
small_usd_out = small_trade_pool.call("swap_eth_for_usd", eth_in=1.0)
large_usd_out = large_trade_pool.call("swap_eth_for_usd", eth_in=40.0)
small_impact = (small_trade_pool.spot_price / initial_pool.spot_price - 1) * 100
large_impact = (large_trade_pool.spot_price / initial_pool.spot_price - 1) * 100
constant_product_preserved = abs(
    large_trade_pool.constant_product - initial_pool.constant_product
) < 1e-6

print(
    f"Initial pool: {initial_pool.eth_reserve:.2f} ETH and "
    f"${initial_pool.usd_reserve:,.2f}; spot price ${initial_pool.spot_price:,.2f}/ETH"
)
print(
    f"Small 1 ETH sale: receives ${small_usd_out:,.2f}; "
    f"price ${small_trade_pool.spot_price:,.2f}/ETH ({small_impact:.2f}%)"
)
print(
    f"Large 40 ETH sale: receives ${large_usd_out:,.2f}; "
    f"price ${large_trade_pool.spot_price:,.2f}/ETH ({large_impact:.2f}%)"
)
print(f"x * y preserved within floating-point tolerance: {constant_product_preserved}")

The output:

Initial pool: 50.00 ETH and $100,000.00; spot price $2,000.00/ETH
Small 1 ETH sale: receives $1,960.78; price $1,922.34/ETH (-3.88%)
Large 40 ETH sale: receives $44,444.44; price $617.28/ETH (-69.14%)
x * y preserved within floating-point tolerance: True

And there’s our first glimpse of price impact.

• Selling just 1 ETH moves the displayed price from $2,000 to about $1,922 — a roughly 3.9% decrease.
• But selling 40 ETH — almost the entire original ETH reserve — moves the displayed price all the way down to about $617.

The AMM is doing exactly what we told it to do. The pool is simply responding to a very large trade relative to its available liquidity.

There is no external ETH/USD price feed involved. The AMM doesn’t know what ETH is worth anywhere else. It only knows the ratio of the two assets sitting inside itself.

And because that number exists on-chain, another smart contract can read it.

That opens up a much more interesting possibility: What if a lending protocol uses this number to decide whether someone’s loan is safe?

The lending contract: a loan that asks the puddle

Now let’s give our AMM a customer who cares rather more about its price than a trader does.

We’ll build a tiny lending protocol (another smart contract). It accepts ETH as collateral and allows a borrower to take on USD-denominated debt. If the value of the collateral falls too far relative to the debt, the position can be liquidated.

We’ll set the minimum collateral ratio at 1.5. Concretely in code:

@dataclass(frozen=True)
class Loan:
    collateral_eth: float
    debt_usd: float

class LoanNotFoundError(Exception):
    """Raised when a borrower has no open loan."""


class PositionNotLiquidatableError(Exception):
    """Raised when liquidation is attempted on a still-healthy position."""


class LendingProtocol(SmartContract):
    def __init__(
        self,
        address: str,
        pool: AMMPool,
        liquidation_ratio: float = 1.5,
        price_source=None,
    ) -> None:
        """Configure the protocol's price source and liquidation threshold."""
        super().__init__(address)
        if liquidation_ratio <= 0:
            raise ValueError("Liquidation ratio must be positive.")
        self.pool = pool
        self.liquidation_ratio = liquidation_ratio
        self.price_source = price_source
        self.loans: dict[str, Loan] = {}

    def open_loan(
        self, borrower: str, collateral_eth: float, debt_usd: float
    ) -> Loan:
        """Open a loan for ``borrower`` and return it."""
        return self.add_loan(borrower, Loan(collateral_eth, debt_usd))

    def add_loan(self, borrower: str, loan: Loan) -> Loan:
        """Register an open loan for a borrower."""
        if not borrower:
            raise ValueError("Borrower name must be non-empty.")
        self.loans[borrower] = loan
        return loan

    def collateral_ratio(self, loan: Loan) -> float:
        """Return collateral value divided by debt."""
        price = (
            self.price_source.price
            if self.price_source is not None
            else self.pool.spot_price
        )
        return loan.collateral_eth * price / loan.debt_usd

    def liquidate(self, borrower: str) -> Loan:
        """Seize and remove a borrower's loan if it is unhealthy."""
        if borrower not in self.loans:
            raise LoanNotFoundError(f"No loan for {borrower}.")
        loan = self.loans[borrower]
        if self.collateral_ratio(loan) >= self.liquidation_ratio:
            raise PositionNotLiquidatableError("Position is still healthy.")
        return self.loans.pop(borrower)

There are a lot of lines here, but most of them are bookkeeping. The interesting part is much smaller:

When the protocol wants to calculate the collateral ratio, it asks for a price:

price = (
    self.price_source.price
    if self.price_source is not None
    else self.pool.spot_price
)

Right now, we haven’t given it another price source, so it falls back to the AMM.

baseline_pool = AMMPool("amm-baseline", 50.0, 100_000.0)
baseline_protocol = LendingProtocol("lending-baseline", baseline_pool)
victim_loan = baseline_protocol.call(
    "open_loan", borrower="victim", collateral_eth=10.0, debt_usd=12_000.0
)
baseline_ratio = baseline_protocol.collateral_ratio(victim_loan)

print(f"At ${baseline_pool.spot_price:,.2f}/ETH, victim collateral ratio: {baseline_ratio:.2f}")
print("Liquidation threshold: 1.50; verdict: HEALTHY")

The output:

     
At $2,000.00/ETH, victim collateral ratio: 1.67
Liquidation threshold: 1.50; verdict: HEALTHY

The position is healthy. The collateral ratio is 1.67 which is above the target ratio of 1.5.

Put the contracts on the chain

At this point we have two contracts.

• amm.eth is the puddle. It holds ETH and USD, and its reserve ratio gives us a price.
• lending.eth is the loan desk. It holds loans and decides whether they are healthy.

No new block is required for that inner call. Using the same classes from articles 2 and 5:

# Same validators / Network / Blockchain as articles 2 and 5. 
nodes = ["Node A", "Alice-Node", "Bob-Node", "Farid-Node"]
validators = [
    Validator("Node A", 100),
    Validator("Alice-Node", 80),
    Validator("Bob-Node", 70),
    Validator("Farid-Node", 50),
]
network = Network(nodes, random.Random(7))
chain = Blockchain(validators)

#   amm     = the puddle    (AMMPool, which IS a SmartContract)
#   lending = the loan desk (ALSO a SmartContract). No water of its own.
amm = AMMPool("amm.eth", 50.0, 100_000.0)
lending = LendingProtocol("lending.eth", amm)

# 'Deploy' here is a receipt, not bytecode. The objects already exist in 
# memory. The notary files the form.
network.broadcast(Transaction("tx-deploy-amm", "Deploy AMMPool at amm.eth"), origin="Node A")
network.broadcast(Transaction("tx-deploy-lending", "Deploy LendingProtocol at lending.eth"), origin="Node A")
_, deploy_amm_block = network.include("Node A", "tx-deploy-amm", chain)
_, deploy_lending_block = network.include("Node A", "tx-deploy-lending", chain)

# Bob's loan, then Alice's pebble. Two shouts into the group chat, two stamps.
bob_loan, bob_tx, bob_block = submit_call(
    network,
    chain,
    "Bob-Node",
    "tx-open-loan",
    lending,
    "open_loan",
    borrower="Bob",
    collateral_eth=10.0,
    debt_usd=12_000.0,
)
alice_usd, alice_tx, alice_block = submit_call(
    network,
    chain,
    "Alice-Node",
    "tx-swap-1eth",
    amm,
    "swap_eth_for_usd",
    eth_in=1.0,
)
bob_ratio_after_pebble = lending.collateral_ratio(lending.loans["Bob"])
valid, message = chain.is_valid()

Alice’s 1 ETH sale barely registers on her — but it moves the one number Bob’s entire position depends on. His collateral ratio slides from 1.67 to 1.60. Still healthy, still above the 1.50 line — but Bob never touched his loan. He just happened to be priced against a puddle someone else disturbed.

That’s the whole danger of an on-chain price feed in one sentence: your safety depends on everyone else’s behavior toward the same pool.

And that is where things get interesting. Because the blockchain has absolutely no idea what ETH is worth outside its own state.

Introducing Oracles

A smart contract is deterministic. Every node executes the same transaction and must land on the same result — if one node computes $2,000 and another computes $1,742.31, they no longer agree on the state of the blockchain, and the whole system has a rather serious problem.

That determinism comes with an awkward limitation: a smart contract cannot simply look outside the blockchain for information. It cannot make an HTTP request to an exchange, read a local file, check the weather, or ask an external database what happened five seconds ago.

Every node needs to be able to execute the same logic from the same available inputs, so allowing arbitrary external information into that process would destroy the very consistency we rely on.

This is the same trade-off we have been seeing throughout the series. The blockchain is extremely good at agreeing on what happened inside the system. It is much less capable of knowing what is happening outside the system.

A lending protocol, however, needs information from outside. So somebody has to tell it.

That is the job of an oracle: a mechanism for bringing external information into the deterministic world of the blockchain.

For our toy implementation, we will keep this deliberately simple. A price feed is just another smart contract at another address, with storage for the reports it receives.

We will create a PriceReport to represent an individual oracle, and two small pieces of logic for the lending protocol: one to calculate the collateral ratio at a given price, and one to decide whether that ratio has crossed the liquidation threshold.

@dataclass(frozen=True)
class PriceReport:
    source: str
    eth_price_usd: float


def collateral_ratio(
    collateral_eth: float, debt_usd: float, eth_price_usd: float
) -> float:
    if collateral_eth <= 0 or debt_usd <= 0 or eth_price_usd <= 0:
        raise ValueError("Collateral, debt, and price must be positive.")
    return collateral_eth * eth_price_usd / debt_usd


def should_liquidate(ratio: float, threshold: float = 1.5) -> bool:
    return ratio < threshold

In a real oracle system, “source” would need to mean something more substantial than a string supplied by the caller. In our toy implementation, it is deliberately just a label — because I want the reader to see exactly where the trust problem begins.

The interesting question is no longer what the lending contract does once it has a price. We already know that part: multiply the collateral by the price, divide by the debt, and liquidate if the ratio falls below 1.5.

The interesting question is which price should it use in the first place?

That question turns out to be much harder.

Take the median

Let’s start with the simplest possible price feed. It receives reports from different sources and stores them on-chain.

In this toy model, I’m splitting the oracle into two pieces: PriceFeed represents the on-chain feed that stores reports, while MedianOracle represents the aggregation rule that decides which of those reports the protocol should use.

class PriceFeed(SmartContract):
    def __init__(self, address: str) -> None:
        """Create an empty feed at ``address``."""

        super().__init__(address)
        self.reports: list[PriceReport] = []

    def report(
        self,
        source: str,
        eth_price_usd: float,
    ) -> PriceReport:
        if eth_price_usd <= 0:
            raise ValueError(
                "Reported price must be positive."
            )

        posted = PriceReport(source, eth_price_usd)
        self.reports.append(posted)
        return posted

    @property
    def latest(self) -> PriceReport:
        return self.reports[-1]

    @property
    def price(self) -> float:
        return statistics.median(
            report.eth_price_usd
            for report in self.reports
        )

There are two interesting things hiding in this very small class.

• First, the feed does not know whether a report is true. The source field is just a label.
• Second, the feed now has a choice about what it considers its price. It can use latest, meaning whatever the most recent report said, or it can aggregate several reports using some rule.

For our first experiment, let’s give it three reports: two around $2,000 and one deliberately wrong report at $1,200.

# Fourth box, fourth address.
feed = PriceFeed("feed.eth")

network.broadcast(
    Transaction(
        "tx-deploy-feed",
        "Deploy PriceFeed at feed.eth",
    ),
    origin="Node A",
)

_, deploy_feed_block = network.include(
    "Node A",
    "tx-deploy-feed",
    chain,
)

assert isinstance(deploy_feed_block, Block)

collateral_eth = 10
debt_usd = 12_000

incoming_reports = [
    ("tx-report-a", "independent-feed-a", 2_005.0),
    ("tx-report-lie", "malicious-feed", 1_200.0),
    ("tx-report-b", "independent-feed-b", 1_995.0),
]

print(
    f"Same loan: {collateral_eth} ETH / "
    f"${debt_usd:,} debt. Threshold 1.50."
)

print(
    f"Deployed {feed.address} "
    f"in Block #{deploy_feed_block.index}"
)

print()

for tx_id, source, price in incoming_reports:
    _, tx, block = submit_call(
        network,
        chain,
        "Node A",
        tx_id,
        feed,
        "report",
        source=source,
        eth_price_usd=price,
    )

    assert isinstance(block, Block)

    latest_ratio = collateral_ratio(
        collateral_eth,
        debt_usd,
        feed.latest.eth_price_usd,
    )

    latest_verdict = (
        "LIQUIDATE (wrong)"
        if should_liquidate(latest_ratio)
        else "HEALTHY"
    )

    print(block)

    print(
        f"  latest on {feed.address}: "
        f"${feed.latest.eth_price_usd:,.0f}/ETH "
        f"from {feed.latest.source}"
    )

    print(
        f"  if lending trusts only Block #{block.index}: "
        f"ratio {latest_ratio:.2f} -> {latest_verdict}"
    )

And this is where the problem becomes visible:

Same loan: 10 ETH / $12,000 debt. Threshold 1.50.
Deployed feed.eth in Block #5

Block #6 proposed by Node A
  data: feed.eth.report(
      source='independent-feed-a',
      eth_price_usd=2005.0
  )

  latest on feed.eth: $2,005/ETH from independent-feed-a
  if lending trusts only Block #6:
      ratio 1.67 -> HEALTHY

Block #7 proposed by Node A
  data: feed.eth.report(
      source='malicious-feed',
      eth_price_usd=1200.0
  )

  latest on feed.eth: $1,200/ETH from malicious-feed
  if lending trusts only Block #7:
      ratio 1.00 -> LIQUIDATE (wrong)

Block #8 proposed by Node A
  data: feed.eth.report(
      source='independent-feed-b',
      eth_price_usd=1995.0
  )

  latest on feed.eth: $1,995/ETH from independent-feed-b
  if lending trusts only Block #8:
      ratio 1.66 -> HEALTHY

The loan has not changed at all. Bob still has 10 ETH locked as collateral and still owes $12,000.

What changed was the number that the lending protocol treated as the price of ETH.

When the latest report says $2,005, Bob’s collateral ratio is 1.67 and the position is healthy. When the latest report suddenly says $1,200, the ratio falls to exactly 1.00 and the same liquidation rule says Bob should be liquidated. When another report of $1,995 arrives, the ratio climbs back to 1.66.

Nothing about the blockchain itself has gone wrong here. Every report was a valid transaction, every transaction was included in a valid block, and the PriceFeed stored exactly what it was instructed to store.

The problem is that a valid piece of blockchain state is not necessarily a true statement about the outside world.

So instead of trusting whichever report arrived last, one simple approach is the median: sort the values and take the one in the middle — yup, it’s that simple.

class MedianOracle:
    def __init__(
        self,
        reports: list[PriceReport],
    ) -> None:
        if not reports:
            raise ValueError(
                "At least one price report is required."
            )

        self.reports = reports

    @property
    def price(self) -> float:
        return statistics.median(
            report.eth_price_usd
            for report in self.reports
        )

Now we can apply that rule to the three reports already stored in feed.eth.

median_oracle = MedianOracle(feed.reports)

median_ratio = collateral_ratio(
    collateral_eth,
    debt_usd,
    median_oracle.price,
)

print(
    f"Median of every report stored at {feed.address}: "
    f"${median_oracle.price:,.0f}/ETH"
)

print(
    f"If lending reads the median instead of the latest Block: "
    f"ratio {median_ratio:.2f} -> HEALTHY"
)

print(
    f"Chain length: {len(chain.chain)}. "
    "The three reports are still sitting on their own Blocks."
)

The median is $1,995, giving Bob a collateral ratio of 1.66.

Why median rather than average? Because the median is resistant to a single extreme outlier. With reports of $2,005, $1,200 and $1,995, the average is pulled down by the malicious report, while the median simply takes the middle value: $1,995.

This is a useful defence, but it is important to understand what it actually defended against.

It did not make the AMM more honest. The AMM was already being completely honest about its own state. If somebody trades a large amount of ETH into the pool, its reserves really do change, and its reserve ratio really does change with them.

The defence is instead about which information the lending protocol chooses to treat as authoritative.

More oracles ≠ more truth

The same problem appears in our toy example in another form. The source field looks reassuring because we have names such as independent-feed-a and independent-feed-b, but the blockchain has no idea whether those sources are actually independent.

The blockchain gives us a remarkably strong guarantee about the information it contains: nodes can agree on what was submitted and what the contracts did with it.

It does not give us a guarantee that somebody submitted the truth.

At this point, our little financial system has all the pieces needed to become dangerous. The AMM provides a price based on its reserves. The lending protocol uses a price to decide whether a loan is safe. The price feed provides another route for information to enter the system. Every individual component can behave exactly according to its rules while the overall system still produces a very bad outcome.

The next question is what happens when someone deliberately takes advantage of that gap.

Which is a story for another time.

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

Introducing Smart Contracts was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

The one time gossip pays off

In my previous article on permissioned chains, we encountered the problem of race conditions.

In a system where transactions are constantly being proposed against shared state, two perfectly legitimate transactions can race against each other. One may change the state before the other reaches validation, making the second transaction stale. Multi-version concurrency control (MVCC) catches that conflict; the client can then re-execute against the latest state and try again.

That got me wondering: what happens in public chains, where participants may not even see the same information at the same time?

Transactions and blocks have to propagate across a distributed network, and that propagation isn’t instantaneous. A transaction might reach one node before another. A block might arrive after a competing block has already been seen elsewhere. At any given moment, different participants can therefore have different views of what is happening.

So what does each participant actually know at any given moment — and how does the network eventually converge on a shared history?

This article explores how this gap is plugged on public blockchains.

As before, all my code can be found in my GitHub repository.

The idea of networks

“The blockchain” is not a single thing sitting somewhere on the internet. A blockchain is a sequence of blocks. But that sequence has to be stored, checked, and updated by computers participating in the blockchain network. These computers are called nodes.

A node is simply a computer running the blockchain’s software. It maintains its own local view of the blockchain and communicates with other nodes over the network.

The network is therefore the collection of nodes and the connections between them. The blockchain is the history those nodes are collectively maintaining.

You can think of it like a shared document, except there is no single document sitting on a central server. Instead, many participants keep their own copy and communicate with one another to keep those copies in agreement.

That distinction becomes important because the copies are not necessarily identical at every instant.

When a new transaction is created, it has to travel through the network before other nodes can learn about it. When a new block is created, it also has to propagate through the network. Network communication takes time, so different nodes can temporarily have different information. Conceptually:

                 NETWORK
        ┌───────────┼───────────┐
        │           │           │
      NODE A      NODE B      NODE C
        │           │           │
     mempool     mempool     mempool
        │           │           │
        ▼           ▼           ▼
   candidate     candidate    candidate
   transactions  transactions transactions
        │           │           │
        └───────────┼───────────┘
                    │
              consensus /
             block creation
                    │
                    ▼
              NEW BLOCK
                    │
                    ▼
              propagated
              through network
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      NODE A      NODE B      NODE C
        │           │           │
        └── blockchain history ┘

This is where mempools come in.

A mempool is a node’s local collection of valid transactions that it has heard about but that have not yet been included in a block.

There is therefore no single, global mempool shared by the entire network.

Think of it like a group chat where everyone is receiving the same messages, but not necessarily at the same time or in the same order. Alice might have already received messages A, B, and C. Bob might have A and C but not B. Carol might have heard about B first.

They’re all participating in the same conversation. They just don’t have exactly the same view of it yet.

Our toy network models this deliberately. Each node gets its own mempool, and transactions propagate between nodes independently.

Assuming we are recording a list of transactions in a public blockchain:

from dataclasses import dataclass 

@dataclass(frozen=True)
class Transaction:
    tx_id: str
    description: str

A network is then a set of nodes, each with its own mempool:

class Network:
    """A set of nodes, each holding its own local mempool.

    There is no shared, global mempool here on purpose: `broadcast`
    delivers a transaction to each peer independently and probabilistically,
    modelling how gossip reaches honest nodes at different times.
    """

    def __init__(self, node_names: list[str], rng: random.Random) -> None:
        """Create one empty mempool per node.
        """
        if not node_names:
            raise ValueError("A network needs at least one node.")
        self.node_names = list(node_names)
        self.rng = rng
        self.mempools: dict[str, dict[str, Transaction]] = {
            name: {} for name in node_names
        }

    def broadcast(self, transaction: Transaction, origin: str) -> None:
        """Deliver a transaction to its origin, then probabilistically to peers.
        """
        if origin not in self.mempools:
            raise ValueError(f"Unknown origin node: {origin}")
        self.mempools[origin][transaction.tx_id] = transaction
        for name in self.node_names:
            if name != origin and self.rng.random() < 0.5:
                self.mempools[name][transaction.tx_id] = transaction

    def mempool_ids(self, node_name: str) -> list[str]:
        """Return a node's currently known transaction IDs, sorted.
        """
        if node_name not in self.mempools:
            raise ValueError(f"Unknown node: {node_name}")
        return sorted(self.mempools[node_name])

The important ideas here are that:

• The network does not contain a single blockchain object
• The network has no global mempool

Instead, each node maintains its own local copy of the chain. The network is the communication layer through which nodes exchange transactions and blocks.

At some point, honest nodes may look like this:

Alice
  blockchain: [B1, B2, B3]
  mempool:    [TX4, TX5]

Bob
  blockchain: [B1, B2, B3]
  mempool:    [TX4]

Carol
  blockchain: [B1, B2, B3]
  mempool:    [TX5, TX6]

Their blockchain histories currently agree, but their mempools do not.

Gossip: Useful precisely because it is imperfect

Gossip is how transactions spread through the network. A node forwards information to its peers, which can then forward it to their peers, and so on.

It improves the chance that other nodes — including a future block proposer — receive a transaction. But it does not guarantee that every node receives it immediately, or even that every node has heard about it at the same moment.

Our code makes this imperfection explicit. We use a seeded random generator so the demonstration is repeatable. The 50% probability is deliberately artificial; it gives us a simple way to model transactions reaching honest nodes at different times.

Watch for the different transaction lists at each node, rather than treating any one node as having the network’s definitive mempool:

nodes = ["Node A", "SketchyGuy-Node", "Emma-Node", "Farid-Node"]
network = Network(nodes, random.Random(7))
transactions = [
    Transaction("tx1", "Alice pays Bob"),
    Transaction("tx2", "Carol pays Titus"),
    Transaction("tx3", "Titus pays Alice"),
    Transaction("tx4", "Bob pays Carol"),
]
origins = ["Node A", "SketchyGuy-Node", "Emma-Node", "Node A"]

for transaction, origin in zip(transactions, origins):
    network.broadcast(transaction, origin)

print("Each node has its own mempool:")
for node in nodes:
    print(f"  {node}: {network.mempool_ids(node)}")

mempool_sizes = [len(network.mempool_ids(node)) for node in nodes]
print(f"Average local mempool size: {statistics.mean(mempool_sizes):.2f}")

Pause and predict: after four broadcasts, will every node have all four transaction IDs?

Output:

Each node has its own mempool:
  Node A: ['tx1', 'tx2', 'tx3', 'tx4']
  SketchyGuy-Node: ['tx1', 'tx2', 'tx4']
  Emma-Node: ['tx1', 'tx3', 'tx4']
  Farid-Node: ['tx2', 'tx3', 'tx4']
Average local mempool size: 3.25

Node A has all four transaction IDs, while every other node is missing one.

Nothing has gone wrong. The nodes simply have different views because the transactions have not propagated to everyone yet.

And this distinction matters when we move from transactions to blocks.

A transaction being present in one node’s mempool does not mean that every node knows about it. Likewise, a transaction being known by many nodes does not mean that it has become part of the blockchain.

A transaction can be submitted to a node, propagated through gossip, included in a proposed block, and eventually confirmed as that block becomes part of the accepted chain.

Each stage depends on information reaching the relevant participants.

Which brings us to the next question:

If a block proposer can only see the transactions that have reached its own node, what happens when it has an incomplete view of the network?

From transactions to block proposals

Transactions sitting in mempools are not yet part of the blockchain. A node must turn these transactions into a block proposal.

In a proof-of-stake blockchain, that job is assigned to a validator selected by the protocol. The proposer looks at the transactions available to it and constructs a candidate block.

And there is an important constraint here: A proposer can only choose from the information it has received.

Simply sending a transaction directly to the next scheduled proposer is not a great solution.

The scheduled proposer might be delayed. It might be temporarily unavailable. It might refuse to relay the transaction. And even if that proposer receives it, the rest of the network still needs an opportunity to learn about and independently validate the resulting block.

Gossip solves a different problem.

Rather than trying to predict exactly which validator will propose the next block, a transaction can spread through the network so that many independently validating nodes have an opportunity to receive it.

That means a future proposer is more likely to have the transaction in its local mempool when its slot arrives. The question is:

“Which transactions does the proposer know about when it is time to build a block?”

Introducing the idea of slots

We now need one more piece of the puzzle: time.

Proof of stake divides time into discrete slots. For each slot, the protocol determines which eligible validator gets the opportunity to propose a block (like my elaboration in my previous article on PoS blockchains).

All validators need to be able to independently determine who that proposer is. Otherwise, different validators could disagree about who was entitled to propose the block.

For this article, I do this deterministically in code. I’m deliberately simplifying the real mechanism here: what matters is that every validator can independently arrive at the same proposer assignment.

def assign_proposer(
    validators: list[Validator], slot: int, epoch_seed: str
) -> Validator:
    """Deterministically pick a slot's proposer from a stake-weighted lottery.

    This hashes a documented ``epoch_seed`` and ``slot`` number so every
    validator can reproduce the same assignment independently -- a real
    protocol needs that reproducibility (a stand-in for VRF/RANDAO-style
    eligibility proofs), whereas per-call proposer selection does not.
    """
    if not validators or sum(v.stake for v in validators) <= 0:
        raise ValueError("Proposer assignment needs positive validator stake.")
    seed = hashlib.sha256(f"{epoch_seed}:{slot}".encode()).digest()
    pick = int.from_bytes(seed, "big") % sum(v.stake for v in validators)
    cumulative = 0
    for validator in validators:
        cumulative += validator.stake
        if pick < cumulative:
            return validator
    raise RuntimeError("Unreachable proposer-selection state.")

The epoch seed is shared, and every validator can run the same calculation to arrive at the same result.

Caveat: Real proof-of-stake protocols use more sophisticated randomness and selection mechanisms. Ethereum, for example, uses RANDAO-based pseudo-random proposer selection, weighted by effective validator balance.

And now we have all the pieces needed for the interesting part.

We have a network where nodes can have different local views, a gossip mechanism that takes time to propagate information, and a protocol that assigns a specific proposer to each slot.

So what happens if the protocol correctly selects the next proposer, but that proposer has not yet received the previous block?

A fork caused by delay, not dishonesty

We will re-use our Block and Blockchain classes from the PoS article. This time, we’ll schedule different proposers while deliberately giving them different views of the chain.

The slot 2 proposer has not received Block #1, so it honestly builds on the latest tip it knows: Genesis. Both candidate blocks therefore point to Genesis.

validators = [
    Validator("Node A", 100),
    Validator("SketchyGuy-Node", 80),
    Validator("Emma-Node", 70),
    Validator("Farid-Node", 50),
]
validators_by_name = {validator.name: validator for validator in validators}
epoch_seed = "notebook-5"

chain = Blockchain(validators)
genesis = chain.chain[0]
slot_1_proposer = assign_proposer(validators, 1, epoch_seed)
slot_2_proposer = assign_proposer(validators, 2, epoch_seed)
assert slot_1_proposer.name != slot_2_proposer.name

block_1 = chain.propose_candidate(
    ", ".join(network.mempool_ids(slot_1_proposer.name)), slot_1_proposer.name
)
proposal_time_views = {
    "Node A": {genesis.hash},
    "SketchyGuy-Node": {genesis.hash, block_1.hash},
    "Emma-Node": {genesis.hash, block_1.hash},
    "Farid-Node": {genesis.hash, block_1.hash},
}
assert block_1.hash not in proposal_time_views[slot_2_proposer.name]
block_2_alt = chain.propose_candidate(
    ", ".join(network.mempool_ids(slot_2_proposer.name)), slot_2_proposer.name
)

print(f"Slot 1 proposer: {slot_1_proposer.name} creates Block #1.")
print(
    f"Slot 2 proposer: {slot_2_proposer.name} has NOT received Block #1; "
    "it builds on Genesis."
)
print("\nPropagation fork (both arrows leave Genesis):")
print("          Genesis")
print("     +----+----+")
print("     |         |")
print("   Block #1    Block #2-alt")
print(f"   {slot_1_proposer.name:<12} {slot_2_proposer.name}")

Pause and predict: if the next proposer has not seen a valid earlier block, can deterministic proposer assignment alone prevent a fork?

The output:

Slot 1 proposer: Farid-Node creates Block #1.
Slot 2 proposer: Node A has NOT received Block #1; it builds on Genesis.

Propagation fork (both arrows leave Genesis):
          Genesis
     +----+----+
     |         |
   Block #1    Block #2-alt
   Farid-Node   Node A

Farid-Node proposes Block #1, while Node A honestly proposes Block #2-alt from Genesis because its local view is delayed.

The fork is caused by information asymmetry, not dishonest behaviour.

This is an important distinction.

Farid-Node and Node A are two different validators, each honestly proposing for its own correctly assigned slot. Neither validator has signed two conflicting blocks for the same slot.

So, in this scenario, neither validator gets slashed. They simply proposed blocks based on different views of the latest chain tip.

The deterministic proposer schedule answered one question:

Who is supposed to propose?

It did not answer another:

What block does that proposer believe is the latest valid block?

And that second question depends on network propagation.

Attestations: turning local views into votes

We now have two competing blocks, both produced honestly:

• Block #1 was proposed by Farid-Node in slot 1.
• Block #2-alt was proposed by Node A in slot 2, because Node A had not yet received Block #1.

The network now needs to decide which branch to follow.

This is where attestations come in.

Validators don’t magically acquire a global view of the network before voting. They attest to the chain they currently see. In our toy model, that means each validator votes for the candidate tip present in its local view.

This gives us an interesting consequence:

Different validators can vote for different blocks without any of them necessarily being dishonest.

At the moment of attestation, Block #1 has had longer to propagate. Block #2-alt is newer and, in our deliberately simplified scenario, has only reached its own proposer.

We therefore derive each validator’s vote directly from the blocks it has actually received rather than hand-picking the votes to produce a particular outcome.

The code below then assigns each vote the validator’s stake and adds the stake supporting each candidate.

def attestation_weight(
    tip_hash: str,
    votes: dict[str, str],
    validators_by_name: dict[str, Validator],
) -> int:
    """Sum the stake of every validator whose vote names ``tip_hash``."""
    unknown = set(votes) - set(validators_by_name)
    if unknown:
        raise ValueError(f"Unknown attesters: {sorted(unknown)}")
    return sum(
        validators_by_name[name].stake
        for name, voted_hash in votes.items()
        if voted_hash == tip_hash
    )

Our fork-choice function is intentionally tiny. It simply selects the candidate with the greatest attestation weight.

def fork_choice_two_tips(
    candidate_tips: list[Block],
    votes: dict[str, str],
    validators_by_name: dict[str, Validator],
) -> tuple[Block, dict[str, int]]:
    """Pick the candidate tip with the most attestation-weighted stake."""
    candidate_hashes = {block.hash for block in candidate_tips}
    invalid_votes = set(votes.values()) - candidate_hashes
    if invalid_votes:
        raise ValueError("An attestation names an unknown candidate tip.")
    weights = {
        block.hash: attestation_weight(block.hash, votes, validators_by_name)
        for block in candidate_tips
    }
    if len(set(weights.values())) != len(weights):
        raise ValueError("Teaching model requires an explicit tie-break rule.")
    winner_hash = max(weights, key=weights.get)
    return next(block for block in candidate_tips if block.hash == winner_hash), weights

There is one deliberate simplification here.

A real blockchain’s fork-choice mechanism is considerably more sophisticated than “add up the stake and pick the largest number.” It has to account for things such as the protocol’s voting rules, chain structure, and tie-breaking behaviour.

But for this article, we only need one idea:

Fork choice gives weight to the different views held by validators.

Let’s see what happens with our actual network state.

# By attestation time, Block #1 (slot 1) has had longer to propagate, so every
# node that already had it in `proposal_time_views` still has it. Block #2-alt
# is brand new: only its own proposer has received it so far. No node holds
# both, so each vote below is just "the block this node has actually seen" —
# read out of `proposal_time_views`, not hand-picked to fit a story.
attestation_time_views = dict(proposal_time_views)
attestation_time_views[slot_2_proposer.name] = attestation_time_views[
    slot_2_proposer.name
] | {block_2_alt.hash}


def vote_for_known_tip(known_block_hashes: set[str]) -> str:
    """Return the block hash a validator with this local view would vote for.

    Prefers Block #1 whenever it is known -- in this scenario no validator
    ever holds both candidates at once, so this never needs a real
    tie-break rule between two simultaneously-known tips.
    """
    return block_1.hash if block_1.hash in known_block_hashes else block_2_alt.hash


votes = {
    name: vote_for_known_tip(known_hashes)
    for name, known_hashes in attestation_time_views.items()
}

print("\nView-derived attestations:")
for name, voted_hash in votes.items():
    label = "Block #1" if voted_hash == block_1.hash else "Block #2-alt"
    print(f"  {name} received {label} and votes for {label}.")

winner, weights = fork_choice_two_tips(
    [block_1, block_2_alt], votes, validators_by_name
)
winner_label = "Block #1" if winner.hash == block_1.hash else "Block #2-alt"
print(f"Block #1 stake weight: {weights[block_1.hash]}")
print(f"Block #2-alt stake weight: {weights[block_2_alt.hash]}")
print(f"Canonical tip: {winner_label}")

chain.accept_candidate(winner)
valid, message = chain.is_valid()
print(
    f"Chain length after fork resolution: {len(chain.chain)}; "
    f"valid? {valid} -- {message}"
)

The output:

View-derived attestations:
  Node A received Block #2-alt and votes for Block #2-alt.
  SketchyGuy-Node received Block #1 and votes for Block #1.
  Emma-Node received Block #1 and votes for Block #1.
  Farid-Node received Block #1 and votes for Block #1.
Block #1 stake weight: 200
Block #2-alt stake weight: 100
Canonical tip: Block #1
Chain length after fork resolution: 2; valid? True -- Chain is valid.

Block #1 wins because SketchyGuy-Node, Emma-Node, and Farid-Node already had it in their local view, contributing 80 + 70 + 50 = 200 stake, versus 100 stake from Node A, which has only its own Block #2-alt proposal.

Fork choice follows the attestation weight behind each received view, not the block’s slot number.

Thinking about what we just learnt

A transaction originates somewhere. Gossip carries it between nodes. Different nodes receive it at different times. A proposer builds a block from its local view. Other validators attest to the blocks they have seen. Fork choice then gives the network a mechanism for converging on one history.

That is the connection between the network and the blockchain.

The blockchain is the shared history. The network is the collection of nodes that propagate, validate, propose, and vote on that history.

At any given moment, individual nodes may have incomplete or even conflicting views. But through communication and consensus, those local views can eventually converge on a common chain.

In other words, we have been studying how a blockchain deals with incomplete and inconsistent information inside its own network.

But there is a more fundamental problem.

Suppose the transaction says:

"Team A won the football match 2–1."

Our validators can check whether the transaction is properly formed and whether it was included in a valid block. But they cannot determine from the blockchain itself whether Team A actually won the match.

The network can agree on a fact. It cannot, by itself, discover whether that fact is true in the outside world.

So how does information from outside the blockchain get into the network in the first place? And once it arrives, how can the blockchain trust it?

That’s a rabbit hole for another time: oracles.

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

Introducing mempools - The one time gossip pays off was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my previous articles, I covered blockchains that operate using (i) proof-of-work (PoW), aka mining, and (ii) proof-of-stake (PoS). In the third article, I extended the PoS blockchain with Merkle trees to explore how the same ideas can be used to create tamper-evident educational credentials.

All three articles have something in common: the blockchain is public and permissionless.

In the PoW blockchain, miners race to perform computational work for the right to add the next block. In the PoS blockchain, proposers are randomly selected, weighted by the stake they put up. Other participants then independently verify that the proposed block follows the rules.

But nobody ever had to prove who they were. If "Sketchy-Guy-Node” played by the rules, his block does get added to the blockchain as well. That makes sense when the whole point is to build a network that anyone can participate in.

But what if that isn’t what we want?

Imagine three banks running a shared settlement ledger. They don’t necessarily want random strangers joining the network. They don’t need a proof-of-work energy bill or a speculative token just so participants can stake it. And they probably don’t want "51% of the CPU" or "51% of the stake" deciding the truth when the actual participants are a small, known, named group of institutions — institutions that would very much like a court to be able to determine who signed what.

This is where permissioned blockchains come in.

Instead of asking:

Who has earned the right to write the next block?

we can ask:

Who is allowed to participate, and whose approval is required for this transaction?

That seemingly small change gives us a very different kind of blockchain. In this article, we’ll build our own permissioned consortium chain, modelled loosely on Hyperledger Fabric.

Hyperledger Fabric is an open-source, enterprise-grade permissioned distributed ledger platform designed for situations where the participants in a blockchain network are known organizations rather than anonymous strangers. Unlike Bitcoin or Ethereum, participants have cryptographic identities, and policies can specify which organizations are allowed to perform particular actions or must approve particular transactions. Its modular architecture was designed with enterprise use cases such as banking, finance, insurance and supply chains in mind.

And the architecture is quite different from the toy PoW and PoS chains we’ve built so far. Our Fabric-inspired chain will follow:

execute → endorse → order → validate

Multiple known organizations can independently execute a proposed transaction and cryptographically endorse its result. An ordering service then determines transaction order and packages transactions into blocks. Finally, peers validate that the required endorsements and other rules have been satisfied before committing the transaction to their ledgers.

Same broad goal — multiple parties maintaining a shared, tamper-evident history.

Very different assumptions about who those parties are.

As before, all my codes for this article can be found in my GitHub repository.

Writing our Membership Service — gives permission to even show up

MembershipService is a deliberately tiny stand-in for one part of what Hyperledger Fabric handles through Membership Service Providers (MSPs). In a real Fabric network, participants have cryptographic identities — typically X.509 certificates issued by trusted Certificate Authorities (CAs) — while MSP configuration defines which identities an organization recognizes and what roles those identities can play.

We’re going to collapse all of that machinery into a humble Python class 😂

No entry in the registry, no participation: Peer.endorse() checks is_registered() before doing anything else and throws if you’re not on the list.

This is the permissioned chain’s first and most fundamental departure from the previous articles:

Identity is a precondition, not an emergent property of computational effort or economic stake.

import hashlib

def sha256(data: str) -> str:
    """Return the hex-encoded SHA-256 digest of a UTF-8 encoded string."""
    return hashlib.sha256(data.encode()).hexdigest()


class MembershipService:
    def __init__(self) -> None:
        """Initialize an empty registry of member organizations."""
        self.registered_orgs: set[str] = set()

    def register(self, org_name: str) -> None:
        """Add an organization to the registry, granting it participant identity."""
        print(f"  [MembershipService] Registered org: {org_name}")
        self.registered_orgs.add(org_name)

    def is_registered(self, org_name: str) -> bool:
        """Return True if the given organization is a registered participant."""
        return org_name in self.registered_orgs

Writing the ledger’s state: a versioned key-value world, not just a list of blocks

In this blockchain, multiple orgs can concurrently propose transactions against the same shared state, so we need to answer a sharper question than “what’s the current balance?” — we need to ask “what version of this key was I looking at when I computed my answer?”

Our WorldState therefore tracks two things: the current value associated with each key, and the version of that key.

from dataclasses import dataclass, field

@dataclass
class WorldState:
    """Versioned key-value ledger state: current balances 
    plus a per-key write version counter."""

    balances: dict[str, float] = field(default_factory=dict)
    versions: dict[str, int] = field(default_factory=dict)

    def version_of(self, key: str) -> int:
        """Return the current version number of a key, or 0 if it 
        has never been written."""
        return self.versions.get(key, 0)


@dataclass
class ExecutionResult:
    """The proposed effect of a chaincode run: what it wants to write, 
    and the versions it read."""

    write_set: dict[str, float]
    read_versions: dict[str, int]

Hang onto version_of() — it's the hook the whole optimistic-concurrency story further down is built on.

ExecutionResult is what a chaincode run produces: a write_set (what it wants to change) and read_versions (what versions it assumed were current when it computed that write set). Neither is applied to WorldState yet — this is a proposal, not a commit.

Chaincode: the business logic, run speculatively

“Chaincode” is Fabric’s term for the business logic encoded in a smart contract. transfer_chaincode is about as simple as one gets: check a balance, then compute a new pair of balances.

The important part isn’t the arithmetic — it’s when this runs.

Executing this function does not touch the real ledger. It runs speculatively against the current state and produces an ExecutionResult: the values it wants to write, plus the versions of the values it read along the way.

An endorsing peer can then sign the result of that simulation.

For our toy implementation, we’ll make this especially visible: multiple peers independently execute the same proposal, hash the resulting write_set, and we’ll require those hashes to agree. Real Fabric carries considerably more information in its proposal responses and endorsements, but the intuition we’re trying to capture is the same:

def transfer_chaincode(state: WorldState, frm: str, to: str, amount: float) -> ExecutionResult:
    if state.balances.get(frm, 0) < amount:
        raise ValueError(f"Insufficient funds: {frm} has {state.balances.get(frm, 0)}, needs {amount}")
    return ExecutionResult(
        write_set={frm: state.balances.get(frm, 0) - amount, to: state.balances.get(to, 0) + amount},
        read_versions={frm: state.version_of(frm), to: state.version_of(to)},
    )

Execution produces a proposed state change; it does not commit that change.

And now: Execute → Endorse → Order → Validate

Why bother separating execution from ordering?

Public and permissioned blockchains still share one awkward problem: multiple organizations that do not necessarily trust one another are trying to maintain a shared ledger.

Fabric tackles that problem by separating responsibilities.

First, endorsing peers simulate a proposed transaction and sign the resulting proposal response. The client collects enough endorsements to satisfy the transaction’s endorsement policy.

Only then does the transaction move to the ordering stage.

The ordering service has a deliberately narrower job: establish a consistent transaction order and package transactions into blocks. It does not execute the chaincode to decide what the transaction should do.

Our toy OrderingService.order() is therefore almost insultingly simple on purpose:

proposals in → ordered proposals out

from collections.abc import Callable

@dataclass
class Endorsement:
    peer_name: str
    result_hash: str


@dataclass
class Peer:
    name: str
    membership: MembershipService

    def endorse(self, chaincode: Callable, state: WorldState, *args) -> tuple[Endorsement, ExecutionResult]:
        if not self.membership.is_registered(self.name):
            raise PermissionError(f"{self.name} is not a registered participant.")
        result = chaincode(state, *args)
        result_hash = sha256(json.dumps(result.write_set, sort_keys=True))
        return Endorsement(peer_name=self.name, result_hash=result_hash), result


@dataclass
class ProposedTransaction:
    description: str
    endorsements: list[Endorsement]
    execution_result: ExecutionResult


class OrderingService:
    def __init__(self, name: str) -> None:
        self.name = name

    def order(self, proposals: list[ProposedTransaction]) -> list[ProposedTransaction]:
        print(f"  [{self.name}] Sequencing {len(proposals)} proposal(s).")
        return list(proposals)

Real Fabric ordering services are distributed systems in their own right. Modern Fabric deployments can use a Raft-based ordering service so multiple ordering nodes agree on the sequence of transactions even if individual nodes fail.

And importantly, being ordered does not mean a transaction is valid.

That comes next.

Finally, the ledger itself

This block looks quite different from the PoW and PoS blocks we built earlier.

There’s no nonce, because nobody is mining. There’s no proposer or stake, because nobody is winning a validator lottery either. Instead, there’s an orderer field: not the winner of a competition, just a record of which ordering service sequenced these transactions into this block.

There’s another important difference.

In our earlier toy chains, we tended to ask whether an entire block was valid before accepting it.

Fabric separates those ideas more sharply:

A transaction can be ordered into a block and still fail validation afterward.

If that happens, the transaction remains part of the blockchain’s immutable history, but its write set is not applied to world state.

That distinction is important enough that we’ll model it explicitly.

class Block:
    """A tamper-evident block carrying a batch of ordered transactions, 
    each pending its own validation code."""

    def __init__(
        self,
        index: int,
        transactions: list[ProposedTransaction],
        previous_hash: str,
        orderer: str,
    ) -> None:
        """Create and hash a new block from an already-ordered batch of 
        transactions.
        """
        self.index = index
        self.timestamp = time.time()
        self.transactions = transactions
        self.previous_hash = previous_hash
        self.orderer = orderer

        # Validation happens after ordering.
        self.validation_codes = ["NOT_VALIDATED"] * len(transactions)

        self.hash = self.compute_hash()

    def compute_hash(self) -> str:
        """Compute this block's SHA-256 hash over its index, timestamp, 
        transactions, previous hash, and orderer."""
        tx_contents = [
            {
                "description": tx.description,
                "write_set": tx.execution_result.write_set,
                "read_versions": tx.execution_result.read_versions,
                "endorsements": [
                    {
                        "peer_name": e.peer_name,
                        "result_hash": e.result_hash,
                    }
                    for e in tx.endorsements
                ],
            }
            for tx in self.transactions
        ]

        block_contents = json.dumps(
            {
                "index": self.index,
                "timestamp": self.timestamp,
                "transactions": tx_contents,
                "previous_hash": self.previous_hash,
                "orderer": self.orderer,
            },
            sort_keys=True,
        )
        return hashlib.sha256(block_contents.encode()).hexdigest()

    def __repr__(self) -> str:
        """Return a human-readable summary of the block, including 
        per-transaction validation codes."""
        return (
            f"Block #{self.index}: "
            f"{len(self.transactions)} transaction(s), "
            f"validation={self.validation_codes}\n"
        )

A very different looking blockchain

Notice that the main event, validate_and_commit_block() below, happens after a block has already been created and appended to the chain.

That is a very different mental model from the is_valid() method in the previous articles. There, validation meant re-walking the blockchain and checking that the chain itself had not been tampered with.

Here, we’re asking a different question:

Which transactions inside this already-ordered block are actually allowed to change world state?

The block stays in the chain either way. Validation determines whether each transaction’s write set gets applied.

class PermissionedBlockchain:
    """A consortium ledger where blocks are cut by ordering, then 
    validated (and applied to state) after the fact."""

    def __init__(
        self,
        required_endorsers: set[str],
        min_endorsements: int,
        orderer_name: str,
    ) -> None:
        """Initialize the chain with an empty genesis block and an empty world 
        state.
        """
        self.required_endorsers = required_endorsers
        self.min_endorsements = min_endorsements
        self.orderer_name = orderer_name

        self.chain: list[Block] = [
            Block(
                index=0,
                transactions=[],
                previous_hash="0" * 64,
                orderer=orderer_name,
            )
        ]

        self.state = WorldState()

    def add_ordered_block(
        self,
        transactions: list[ProposedTransaction],
    ) -> Block:
        """Cut a new block from an already-ordered batch of transactions and 
        append it to the chain.

        This is the ordering-service side of the pipeline: it has no opinion
        on whether any transaction in the batch is actually valid.
        """
        previous_block = self.chain[-1]

        block = Block(
            index=len(self.chain),
            transactions=transactions,
            previous_hash=previous_block.hash,
            orderer=self.orderer_name,
        )

        self.chain.append(block)

        print(
            f"  [{self.orderer_name}] "
            f"Created Block #{block.index} with "
            f"{len(transactions)} transaction(s)."
        )

        return block

    def validate_and_commit_block(self, block: Block) -> list[bool]:
        """Validate every transaction in a block and apply valid ones to world
        state.

        For each transaction, checks (in order): the endorsement policy is
        satisfied, a minimum number of endorsements was collected, all
        endorsers agree on the result, and no read key's version has changed
        since the transaction was endorsed (MVCC). The block's
        `validation_codes` are updated in place; the block itself is never
        removed or re-sequenced, even if every transaction in it turns out
        invalid -- only the *state-changing effect* of invalid transactions
        is withheld.
        """
        results: list[bool] = []

        for i, tx in enumerate(block.transactions):
            print(f"  Validating: {tx.description}")

            endorser_names = {e.peer_name for e in tx.endorsements}

            if not endorser_names.issuperset(self.required_endorsers):
                print("    INVALID: missing required endorsers")
                block.validation_codes[i] = "INVALID_ENDORSEMENT_POLICY"
                results.append(False)
                continue

            if len(tx.endorsements) < self.min_endorsements:
                print("    INVALID: not enough endorsements")
                block.validation_codes[i] = "INVALID_QUORUM"
                results.append(False)
                continue

            if len({e.result_hash for e in tx.endorsements}) > 1:
                print("    INVALID: endorsers disagree")
                block.validation_codes[i] = "INVALID_ENDORSER_MISMATCH"
                results.append(False)
                continue

            mvcc_conflict = False

            for key, read_version in tx.execution_result.read_versions.items():
                current_version = self.state.version_of(key)

                if current_version != read_version:
                    print(
                        f"    INVALID: MVCC CONFLICT on '{key}' -- "
                        f"endorsed against version {read_version}, "
                        f"current is {current_version}"
                    )
                    block.validation_codes[i] = "INVALID_MVCC_CONFLICT"
                    results.append(False)
                    mvcc_conflict = True
                    break

            if mvcc_conflict:
                continue

            for key, new_value in tx.execution_result.write_set.items():
                self.state.balances[key] = new_value
                self.state.versions[key] = self.state.version_of(key) + 1

            block.validation_codes[i] = "VALID"
            results.append(True)

            print("    VALID: write set committed to WorldState")

        return results

This is where “permissioned” earns its keep:

• add_ordered_block() does the ordering service's job: take whatever batch of transactions arrived, cut a Block around them, append it to the chain. It has zero opinion on whether any of those transactions are legitimate.
• validate_and_commit_block() does the committer's job: walk every transaction in that already-appended block and, for each one, check:

1. Endorsement policy — did all required_endorsers actually sign off? (Here: both banks, always — a strict "everyone must agree" policy. Real Fabric policies can be richer, e.g. "any 2 of 3".)
2. Quorum — at least min_endorsements signatures, full stop.
3. Agreement — do all endorsers’ result_hashes match? If two honest-looking endorsers computed different write sets, something is wrong (bug, malicious peer, or stale state) — mark it invalid rather than guess who's right.
4. MVCC conflict check — for every key the transaction read, is state.version_of(key) still what the endorsers assumed? If someone else's transaction already landed and bumped that version, this proposal is stale — mark it invalid, no matter how honest it was.

Only a transaction that passes all four gates gets its write set applied to WorldState, with its validation_codes entry set to "VALID". Everything else gets a specific INVALID_* code — and stays on the chain anyway, permanently, as a record that it was ordered but failed validation.

The block itself is never rolled back or re-cut just because something inside it turned out to be invalid. That’s the whole point of separating “put these transactions in order” from “decide which of them may update world state.”

Real Fabric follows the same broad principle: transaction validation happens after ordering, and an invalid transaction can remain recorded in the blockchain while its state changes are excluded from world state. A block does not have to disappear merely because transactions inside it fail validation.

Then: what happens when two transactions collide?

Gate #4 above is where optimistic concurrency control (OCC) lives.

“Optimistic” because nobody locks anything up front — every peer just executes hopefully, assuming nothing else will change the state before their transaction lands.

Most of the time that’s true, and we avoid the cost of locking.

When it isn’t, validate_and_commit_block() catches the stale read during validation, marks that transaction INVALID_MVCC_CONFLICT, and leaves it right where it is in the blockchain.

Nobody cheated. The transaction wasn’t necessarily malformed. The world simply changed between execution and validation.

The client can respond with a shrug: re-run EXECUTE against whatever the state looks like now, collect fresh endorsements, get the new transaction ordered into a fresh block, and try again.

That’s what propose_with_retry() below demonstrates.

def propose_with_retry(
    description: str,
    peers: list[Peer],
    chaincode: Callable,
    chain: PermissionedBlockchain,
    orderer: OrderingService,
    args: tuple,
    max_attempts: int = 3,
) -> bool:
    """The client-side retry loop -- what a real Fabric SDK does
    automatically. On an MVCC conflict, don't give up: re-run EXECUTE
    against whatever the CURRENT state now is, and try again. This is
    the 'optimistic' half of optimistic concurrency control -- pay the
    retry cost only on an actual collision, not on every transaction.

    Every attempt still gets ordered into its own block and validated,
    even a failing one -- a rejected attempt leaves an INVALID block
    behind on the chain, it just never touches WorldState.
    """
    for attempt in range(1, max_attempts + 1):
        print(f"  Attempt {attempt}: {description} (fresh EXECUTE against current state)")
        endorsements: list[Endorsement] = []
        execution_result: ExecutionResult | None = None
        for peer in peers:
            endorsement, result = peer.endorse(chaincode, chain.state, *args)
            endorsements.append(endorsement)
            execution_result = result
        tx = ProposedTransaction(description, endorsements, execution_result)
        ordered = orderer.order([tx])
        block = chain.add_ordered_block(ordered)
        results = chain.validate_and_commit_block(block)
        if results[0]:
            return True
        print("    -> stale, retrying...\n")
    print(f"  Gave up after {max_attempts} attempts.")
    return False

Time to give our permissioned chain a spin.

Demo: The tale of three banks with one shared ledger

The scenario: Bank-A, Bank-B, and Bank-C jointly run a settlement ledger. None of them trusts the other two's arithmetic, so the endorsement policy requires all three to independently compute and agree on every transaction before it commits. Nobody is mining. Nobody is staking. Everybody is, presumably, billing hours.

membership = MembershipService()
membership.register("Bank-A")
membership.register("Bank-B")
membership.register("Bank-C")
peer_a = Peer("Bank-A", membership)
peer_b = Peer("Bank-B", membership)
peer_c = Peer("Bank-C", membership)
peers = [peer_a, peer_b, peer_c]

chain = PermissionedBlockchain(
    required_endorsers={"Bank-A", "Bank-B", "Bank-C"},
    min_endorsements=3,
    orderer_name="Shared-Ordering-Service",
)
orderer = OrderingService("Shared-Ordering-Service")
chain.state.balances = {"Alice-Account": 1000.0, 
                        "Bob-Account": 500.0, 
                        "Carol-Account": 0.0}

Here comes the race condition

Two clients prepare transactions at roughly the same time:

• Alice pays Bob $200
• Alice pays Carol $150

Both transactions are executed and endorsed before either one has changed WorldState, so both simulations see Alice-Account at version 0, with a balance of $1,000.

Let’s create both transactions first without ordering or committing either one:

e_a1, res1 = peer_a.endorse(
    transfer_chaincode, chain.state,
    "Alice-Account", "Bob-Account", 200.0
)
e_b1, _ = peer_b.endorse(
    transfer_chaincode, chain.state,
    "Alice-Account", "Bob-Account", 200.0
)
e_c1, _ = peer_c.endorse(
    transfer_chaincode, chain.state,
    "Alice-Account", "Bob-Account", 200.0
)

tx1 = ProposedTransaction(
    "Alice pays Bob $200",
    [e_a1, e_b1, e_c1],
    res1,
)

e_a2, res2 = peer_a.endorse(
    transfer_chaincode, chain.state,
    "Alice-Account", "Carol-Account", 150.0
)
e_b2, _ = peer_b.endorse(
    transfer_chaincode, chain.state,
    "Alice-Account", "Carol-Account", 150.0
)
e_c2, _ = peer_c.endorse(
    transfer_chaincode, chain.state,
    "Alice-Account", "Carol-Account", 150.0
)

tx2_stale_attempt = ProposedTransaction(
    "Alice pays Carol $150",
    [e_a2, e_b2, e_c2],
    res2,
)

At this point, nothing has been committed.

Both transactions have all three required endorsements, and because neither transaction has changed WorldStateyet, both were calculated against Alice-Account version 0.

But look at what they independently calculated:

Transaction 1

Alice: $1,000 → $800
Bob: $500 → $700

Transaction 2

Alice: $1,000 → $850
Carol: $0 → $150

Both calculations are perfectly correct given the state they saw when they executed.

The problem appears when we try to put them in order.

print("=== ORDER + VALIDATE: Tx1 happens to get sequenced first ===\n")
ordered1 = orderer.order([tx1])
block1 = chain.add_ordered_block(ordered1)
chain.validate_and_commit_block(block1)

The output:

=== ORDER + VALIDATE: Tx1 happens to get sequenced first ===

  [Shared-Ordering-Service] Sequencing 1 proposal(s).
  [Shared-Ordering-Service] Created Block #1 with 1 transaction(s).
  Validating: Alice pays Bob $200
    VALID: write set committed to WorldState
[True]

Now transaction 2 will fail because the WorldStatehas changed:

print("\n=== Tx2's ORIGINAL (now-stale) endorsement finally reaches ORDER + VALIDATE ===\n")
ordered2 = orderer.order([tx2_stale_attempt])
block2 = chain.add_ordered_block(ordered2)
results = chain.validate_and_commit_block(block2)
print(f"  First attempt succeeded? {results[0]}\n")

The output:

=== Tx2's ORIGINAL (now-stale) endorsement finally reaches ORDER + VALIDATE ===

  [Shared-Ordering-Service] Sequencing 1 proposal(s).
  [Shared-Ordering-Service] Created Block #2 with 1 transaction(s).
  Validating: Alice pays Carol $150
    INVALID: MVCC CONFLICT on 'Alice-Account' -- endorsed against version 0, current is 1
  First attempt succeeded? False

And there it is.

Transaction 2 was perfectly valid when it was executed and endorsed. But by the time it reached validation, Transaction 1 had already changed Alice-Account from version 0 to version 1.

Why not just apply Transaction 2 anyway?

Because its write set says Alice’s new balance should be $850 — a number calculated from the old $1,000 balance.

But Alice is now actually at $800. Blindly applying that stale write set would overwrite $800 with $850, effectively making $50 of Alice’s first payment disappear.

So the validator doesn’t try to be clever. It simply asks:

“You calculated this using version 0. Is version 0 still current?”

No. Alice is now at version 1.

Transaction 2 is therefore marked INVALID_MVCC_CONFLICT. It stays recorded in Block #2, but its write set never touches WorldState.

Our client retries:

print("=== Client retries automatically, re-executing against CURRENT state ===\n")
success = propose_with_retry(
    "Alice pays Carol $150", peers, transfer_chaincode, chain, orderer,
    ("Alice-Account", "Carol-Account", 150.0),
)
print(f"\n  Eventually succeeded? {success}\n")

The output:

=== Client retries automatically, re-executing against CURRENT state ===

  Attempt 1: Alice pays Carol $150 (fresh EXECUTE against current state)
  [Shared-Ordering-Service] Sequencing 1 proposal(s).
  [Shared-Ordering-Service] Created Block #3 with 1 transaction(s).
  Validating: Alice pays Carol $150
    VALID: write set committed to WorldState

  Eventually succeeded? True

The final state:

=== Final state ===
  Balances: {'Alice-Account': 650.0, 'Bob-Account': 700.0, 'Carol-Account': 150.0}
  Versions: {'Alice-Account': 2, 'Bob-Account': 1, 'Carol-Account': 1}
  Chain length: 4 blocks

And now the numbers add up.

Alice started with $1,000, paid Bob $200, then successfully retried her $150 payment to Carol:

$1,000 − $200 − $150 = $650

Notice the versions too. Alice-Account changed twice, so it has reached version 2. Bob and Carol were each updated once, so both are at version 1.

And the chain contains four blocks:

• Block #0 — genesis
• Block #1 — Alice → Bob $200: VALID
• Block #2 — original Alice → Carol $150: INVALID_MVCC_CONFLICT
• Block #3 — retried Alice → Carol $150: VALID

Block #2 didn’t disappear just because its transaction failed.

The blockchain remembers what happened. World state remembers what actually took effect.

Concluding thoughts

A permissioned chain starts from a fundamentally different assumption than a public chain: we already know who is allowed to participate.

That changes the mechanism.

In our toy public chains, PoW and PoS determine who gets to propose the next block — either by winning computational work or by being selected according to stake. In our permissioned chain, there is no mining race and no validator lottery. Known members execute transactions, endorse their results, an ordering service sequences them, and validators check whether those transactions are still valid when they reach the commit stage.

And that’s where things get interesting.

In a system where transactions are constantly being proposed against shared state, two perfectly legitimate transactions can race against each other. One may change the state before the other reaches validation, making the second transaction stale. MVCC catches that conflict; the client can then re-execute against the latest state and try again.

Which led me to another question.

What happens on a public blockchain when different participants don’t see the same information at the same time?

Transactions and blocks have to propagate across a distributed network, and that propagation isn’t instantaneous. A transaction might reach one node before another. A block might arrive after a competing block has already been seen elsewhere. So what does each participant actually know at any given moment — and how does the network eventually converge on a shared history?

That sent me down another rabbit hole.

A story to be shared another time.

Disclaimer: All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.

Introducing permissioned chains was originally published in MITB For All on Medium, where people are continuing the conversation by highlighting and responding to this story.