The Shift in Blockchain Development

The blockchain developer mindset has long prioritized flexibility. Developers write functions that return objects. They chain those objects together in Programmable Transaction Blocks (PTBs). They give human developers the power to compose arbitrarily complex workflows. This approach has served the ecosystem well for years.

However, AI agents are evolving from chatbots that give advice into autonomous actors that hold private keys, manage real money, and execute multi-step financial strategies without human oversight. This evolution demands a new contract design philosophy on Sui, specifically a security-and-restriction-first approach.

This article explains the pattern that Sui Security and protocol developers are adopting in 2026. The article covers why traditional patterns create vulnerabilities for AI agents, how to implement layered permission systems, and exactly what code changes you need to make today.

Why AI Agents Break Traditional Assumptions

Before diving into code, it is essential to understand the problem deeply. Traditional Move smart contracts were designed with assumptions that no longer hold when AI agents are the callers.

The Human Developer Assumption

Human developers are generally trustworthy when given powerful tools. They might make mistakes, but they rarely act maliciously against their own interests. When a developer chains together a PTB with ten function calls, they intend for those calls to work together productively. They will not deliberately route a withdrawn fee to an attacker's address.

The AI Agent Reality

Autonomous AI agents operate differently. They can be exploited through several attack vectors:

• Model hallucinations: The AI might generate a transaction sequence that does not align with the protocol’s intended logic. It could construct a PTB that chains operations in ways the developers never anticipated.
• Prompt injection: Attackers can manipulate the AI’s instructions through carefully crafted inputs. A malicious prompt could instruct the AI to transfer fees to a new address, and the AI might comply without understanding the context.
• Unrestricted chaining: Without restrictions, an AI could withdraw fees in one step and immediately transfer them to an external destination in the next step. Traditional design patterns enable this behavior.

The traditional composability-first approach gives AI agents too much freedom. Developers need to restrict agents to exactly the operations they intend.

Core Sui Concepts for the New Pattern

This article assumes basic familiarity with Move, but three Sui-specific concepts are essential for understanding the new design patterns.

Object-Centric Design

Sui differs fundamentally from Ethereum and other account-based chains. Every asset exists as a distinct object with a unique ID and explicit ownership rules. A Coin is not merely a balance entry in a mapping. It is a distinct object that developers must explicitly pass around and track. This object-centric model enables powerful composition through Programmable Transaction Blocks.

Programmable Transaction Blocks

PTBs are Sui’s mechanism for transaction composition. A single PTB can contain up to 1,024 Move function calls that execute atomically. Developers can pass objects directly from one function’s output into another function’s input. This enables building complex logic without multiple separate transactions.

For example, a user might withdraw liquidity from a pool, swap the tokens, deposit them into a lending protocol, and collateralize a loan all in one atomic transaction. This is powerful for human developers building sophisticated DeFi strategies.

The Return-Pattern Problem

Historically, public functions were written to return objects. This pattern enabled maximum PTB flexibility. Consider this classic pattern:

public fun withdraw_fee(...) returns Coin<T>

The function returns a coin object. The caller then feeds that coin into another function or transfers it wherever they want. This design maximized composability for human-driven applications.

However, returning objects to AI agents creates attack surfaces. The AI receives a loose object that it can potentially misuse.

The New Design Philosophy: Encapsulated Operations

For functions that AI agents are allowed to call, developers now follow three strict principles.

Principle 1: Layered Permission Management

Implement permission checks directly inside the contract using on-chain state. Specifically, maintain a whitelist of approved agent addresses stored within the shared or owned object itself. Do not rely solely on transaction sender checks at the PTB level. Embed the authorization logic deep in the contract.

Principle 2: Encapsulate the Entire Operation

Create one public function that performs the complete operation internally. Do not expose intermediate steps as separate public functions that the AI could combine in unexpected ways. The function should handle all asset movements, including withdrawal, transfer, deposit, and other operations entirely within its own execution.

Principle 3: Never Return Objects

The function must return nothing. No Coin<T> objects. No capability objects. Nothing that the AI can subsequently misuse or re-compose into dangerous transaction sequences. The AI only receives an event emission and a success or failure indication.

This approach restricts the AI’s autonomy to exactly the operation the developer intended. It prevents classic risks, including the AI taking a returned coin and sending it to a malicious address, chaining withdrawals across multiple PTB steps in ways the contract never anticipated, and generating transaction sequences that were not anticipated by the developers.

Code Example: Position Manager Refactor

This section demonstrates how to transform a contract from the traditional pattern to the new AI-safe pattern. The example uses a DeFi Position Manager module, which could be part of a liquidity protocol or perpetual exchange.

The Traditional Design (Composability-First)

Here is what the traditional pattern looks like. Notice how the functions return objects that callers can freely use.

module protocol::position_manager {
    use sui::coin::{Self, Coin};
    use sui::balance::{Self, Balance};
    use sui::object::{Self, UID};
    use sui::tx_context::TxContext;

    struct PositionManager has key {
        id: UID,
        fee_balance: Balance<SUI>,
        protocol_balance: Balance<SUI>,
    }

    // Anyone can call this and receive a Coin object
    public fun withdraw_from_fee(
        pm: &mut PositionManager,
        amount: u64,
        ctx: &mut TxContext
    ): Coin<SUI> {
        // Logic to split fees from the fee balance
        coin::from_balance(
            balance::split(&mut pm.fee_balance, amount),
            ctx
        )
    }

    // Anyone can add a coin to the protocol balance
    public fun add_to_balance(
        pm: &mut PositionManager,
        fee: Coin<SUI>
    ) {
        balance::join(&mut pm.protocol_balance, coin::into_balance(fee));
    }
}

How an AI agent would interact dangerously:

The AI constructs a PTB like this:

1. Call withdraw_from_fee and receive a Coin<SUI> object back.
2. In the same PTB, transfer that coin to an attacker-controlled address.
3. Alternatively, swap it for another token or hold it for later misuse.

The risks are significant:

• An AI bug or hallucination could drain the fee pool.
• Malicious prompt injection could instruct the AI to send all fees to a new address, and the AI might comply.
• There is no built-in restriction on what the returned object can be used for.

This is why the traditional pattern of returning objects worked well for human developers composing PTBs, but is unsafe when the caller is an autonomous AI.

The New Design (AI-Agent-First)

Now, let us implement the secure pattern. We will add the layered permission system, encapsulate the operation, and ensure no objects are returned.

module protocol::position_manager {
    use sui::coin::{Self, Coin};
    use sui::balance::{Self, Balance};
    use sui::object::{Self, UID, ID};
    use sui::tx_context::{Self, TxContext};
    use sui::clock::Clock;
    use sui::event;
    use sui::vec_set::{Self, VecSet};
    use std::type_name;

    // Error codes
    const ENotAllowed: u64 = 0;

    // Events for observability
    public struct FeeTransferredToBalance has copy, drop {
        pm_id: ID,
        coin_type: std::ascii::String,
        amount: u64,
        timestamp: u64,
    }

    // Main storage object
    public struct PositionManager has key {
        id: UID,
        fee_balance: Balance<SUI>,
        protocol_balance: Balance<SUI>,
        agents: VecSet<address>,  // Whitelist of approved AI agents
    }

    // Only this function is exposed to AI agents
    public fun agent_transfer_fee_to_balance<T>(
        pm: &mut PositionManager,
        amount: u64,
        clk: &Clock,
        ctx: &mut TxContext,
    ) {
        // Layered permission check
        // Only whitelisted AI agents can call this function
        assert!(
            vec_set::contains<address>(&pm.agents, &ctx.sender()),
            ENotAllowed
        );

        // Internal operations begin here
        // The fee never leaves the contract as a return value
        let fee = withdraw_from_fee(pm, amount, ctx);
        add_to_balance(pm, fee);

        // Only an event is emitted
        // AI or off-chain monitors can listen to this event
        event::emit(FeeTransferredToBalance {
            pm_id: object::id(pm),
            coin_type: type_name::with_defining_addresses<T>().into_string(),
            amount,
            timestamp: clk.timestamp_ms(),
        });
    }

    // Internal helper functions
    // These are NOT public or entry functions
    fun withdraw_from_fee(
        pm: &mut PositionManager,
        amount: u64,
        ctx: &mut TxContext
    ): Coin<SUI> {
        coin::from_balance(
            balance::split(&mut pm.fee_balance, amount),
            ctx
        )
    }

    fun add_to_balance(
        pm: &mut PositionManager,
        fee: Coin<SUI>
    ) {
        balance::join(&mut pm.protocol_balance, coin::into_balance(fee));
    }

    // Admin function to manage the whitelist
    public fun add_agent(
        pm: &mut PositionManager,
        agent: address,
        ctx: &mut TxContext
    ) {
        // This would typically check for admin permissions
        vec_set::insert(&mut pm.agents, agent);
    }

    public fun remove_agent(
        pm: &mut PositionManager,
        agent: address,
        ctx: &mut TxContext
    ) {
        // This would typically check for admin permissions
        vec_set::remove(&mut pm.agents, &agent);
    }
}

Key Observations About the New Pattern

This section breaks down exactly what makes this design AI-safe.

Public Function, Restricted Access

The function agent_transfer_fee_to_balance is public. This means the AI agent's wallet can call it directly. However, the permission check at the beginning ensures only pre-approved addresses can execute the logic. The whitelist is stored on-chain in the PositionManager object itself, specifically in the pm.agents: VecSet<address> field.

Mutable Reference Without Exposure

The function takes a mutable reference to the PositionManager object. This allows it to modify the internal state, including updating balances. But it never returns any capability or asset object to the caller.

Private Helper Functions

The withdraw_from_fee and add_to_balance functions are private. They are marked with fun rather than public fun. This means external callers, including AI agents, cannot invoke them directly. They can only be called internally by other functions in the same module. This prevents the AI from constructing PTB sequences that bypass the main permission check.

No Return Type

Notice the function signature has no return type after the parameter list. There is no -> SomeType return declaration. This means the AI receives nothing it can misuse. It cannot take a returned object and transfer it elsewhere. It cannot chain this operation with unexpected subsequent calls. The operation is fully contained.

Event-Driven Observability

Since the AI receives no return value, how do systems know what happened? The contract emits an event specifically FeeTransferredToBalance. Off-chain systems, monitoring services, and the AI itself can listen to this event for feedback. The AI can verify that its operation succeeded without needing to hold the actual assets.

Comparison: Traditional versus New Design

The Broader Context: Sui’s Agentic Infrastructure

This design pattern is not isolated. It represents part of a broader 2026 trend on Sui, specifically transforming the blockchain into execution infrastructure for AI agents that hold economic value.

AI is transitioning from an advisor role to an autonomous actor that holds money, executes multi-step workflows, and needs blockchain infrastructure with bounded authority, programmable guardrails, and verifiable outcomes.

Sui’s object model and PTBs already support atomic workflows. But contract-level design must now add restrictions for safety. This article demonstrates exactly how contract authors should adapt their Move code to be AI-ready without sacrificing security.

Practical Implementation Checklist

For retrofitting an existing Sui Move contract for AI agent compatibility, the following checklist could be followed:

• Identify all public functions that AI agents will call.
• Add a VecSet<address> field to your main storage object for the agent whitelist.
• Implement admin functions to add and remove agents from the whitelist.
• Create new encapsulated public functions that perform complete operations internally.
• Change return types to unit type for AI-facing functions.
• Move asset-returning logic into private helper functions.
• Add comprehensive event emissions for observability.
• Remove or restrict public functions that return objects if they are not needed by human callers.
• Document the permission model clearly for integrators.

Conclusion

Sui’s object model and PTBs are powerful because they let developers build atomic, composable workflows around explicit on-chain objects. Those same strengths make interface design more consequential when the caller is automated. A function that returns a transferable object may be perfectly reasonable for a human-led integration and still be too permissive for a bounded autonomous role.

The practical conclusion is straightforward: Keep the internals composable and the external agent-facing interface narrower. Check permissions on chain, execute the full intended workflow inside the contract, and use events for monitoring when possible. That approach does not guarantee safety on its own, but it does reduce unnecessary discretion at exactly the point where protocol authors most need control.

AI-Safe SUI Move Smart Contracts was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

The role of large language models in enterprise software has changed substantially. What began as an exercise in crafting clever prompts has matured into the engineering of autonomous, multi-step agentic systems — systems that plan, invoke external tools, and reason over structured data at runtime.

At the center of this shift is the Model Context Protocol (MCP), a standardized, open framework that decouples an AI host’s reasoning capabilities from the tools and data sources it depends upon. Rather than hard-coding integrations between a model and each individual service, MCP defines a shared protocol layer — comprising tool descriptions, invocation semantics, JSON-RPC messaging, and transport contracts — so that any compliant host can discover and use any compliant server without bespoke glue code.

The LLM host focuses on orchestration and reasoning. MCP servers expose domain capabilities, including file access, database queries, HTTP calls, and computational tasks. A shared protocol governs how they communicate. Choosing the right language, the right crates, and the right security posture for that protocol layer is what this article is about.

Why Rust?

Choosing an implementation language for MCP components has real consequences. MCP servers sit at the boundary between an AI agent and the systems it manipulates. They process untrusted, LLM-generated inputs, invoke real-world operations, and must remain correct even under adversarial conditions. Rust earns its place here for four practical reasons.

Safety without a garbage collector. Rust’s ownership model eliminates entire classes of memory vulnerability — use-after-free, buffer overflows, data races — at compile time, with no garbage-collector pauses to worry about. For long-running, high-throughput MCP servers, this translates directly into correctness and predictable latency.

Performance that scales. The pmcp crate, which uses hardware-level SIMD optimizations for message parsing, reports a 16x speed improvement and 50x reduction in memory usage compared to an equivalent TypeScript implementation, based on its own published benchmarks. These gains are specific to pmcp's optimizations, but they reflect what becomes possible when the runtime has no GC overhead and message parsing is taken seriously.

Errors are enforced, not optional. Rust’s Result<T, E> type requires every failure to be explicitly handled, forwarded, or deliberately discarded. You cannot accidentally ignore an error. In practice, this means avoiding .unwrap() in production code. Calling .unwrap() on a failed result causes a panic that terminates the in-flight tool invocation and breaks the server's response contract with the host. Using the ? operator instead propagates the error as a well-formed response the LLM can reason about and recover from.

A mature, purpose-built ecosystem. The Rust MCP ecosystem now includes six active crates covering everything from minimalist stdio servers to enterprise-grade HTTP deployments with OAuth 2.1 support. You are not building on experimental ground.

Choosing the Right MCP Crate

There is no single correct crate. The right choice depends on your deployment context, performance requirements, and protocol version needs. The following is a structured comparison.

rmcp — The Official Rust SDK

rmcp is the official Rust SDK for MCP, providing core implementations of protocol primitives and the stdio transport. As the reference implementation, it tracks the canonical specification most closely and is designed for clarity and interoperability.

Best suited for: Standard local servers communicating via stdio, rapid prototyping, and situations where official protocol conformance is the primary requirement.

rust-mcp-sdk — High-Performance Async Toolkit

rust-mcp-sdk is built for servers that need to serve many concurrent clients over HTTP/SSE rather than stdio. It integrates with the Axum web framework and includes DNS rebinding protection, which prevents browser-based clients from being tricked into sending requests to a local server they were not intended to reach.

Best suited for: High-concurrency, network-exposed MCP servers and teams already invested in the Axum ecosystem.

pmcp — Production-Ready with Observability

pmcp is designed for enterprise deployments where operational visibility is as important as raw performance. It bundles SIMD-accelerated message parsing, built-in metrics instrumentation, and quality gates for integration into CI/CD pipelines to enforce performance and reliability thresholds before deployment.

Best suited for: Enterprise deployments where performance SLAs must be measurable and teams running CI/CD pipelines with performance regression testing.

mcpkit — Advanced Protocol Features with Reduced Boilerplate

mcpkit targets teams building complex tool ecosystems who want to minimize repetitive configuration code. Its #[mcp_server] macro unifies tool definition and registration into a single declarative annotation, and it uses typestate validation to catch configuration errors at compile time rather than at runtime.

Notably, mcpkit implements the 2025-11-25 protocol specification (verify the current version at modelcontextprotocol.io), adding support for the following advanced features.

• Tasks: long-running, asynchronous tool invocations with progress reporting.
• Elicitation: structured mechanisms for the server to request additional information from the user mid-invocation.
• OAuth 2.1: standardized authorization flows for servers accessing protected third-party APIs on behalf of users.

Best suited for: Teams building feature-rich, multi-tool servers and deployments requiring the latest protocol capabilities.

async-mcp — Minimalist Async Implementation

async-mcp is a deliberately lightweight crate that implements the core MCP protocol with minimal dependencies. It is appropriate when you need the protocol without the infrastructure overhead that higher-level crates carry.

Best suited for: Simple client/server applications, resource-constrained or embedded environments, and cases where a minimal dependency footprint is a hard requirement.

mcp_protocol_sdk — Comprehensive Specification Compliance

mcp_protocol_sdk complies with the 2025-06-18 specification and introduces capabilities that reflect the evolving multimodal direction of AI systems, specifically the following.

• Audio content: support for audio data as a first-class content type in tool responses.
• Annotations: enhanced metadata attachable to content for richer model context.
• Argument autocompletion: enables MCP clients to provide completion suggestions for tool parameters.

Best suited for: Teams building multimodal tool servers and applications requiring argument completion in their client tooling.

Supporting Utilities

Two additional crates round out the ecosystem.

• mcp-tester: Scenario-based automated testing for MCP servers, covering edge cases and malformed requests.
• rmcp-openapi: Converts existing OpenAPI specifications into MCP tool definitions, providing a practical migration path for organizations that already maintain OpenAPI-described APIs.

Building Your First MCP Tool

The following example builds a File Explorer MCP server using rmcp. It exposes two tools — one that lists directory contents and one that reads a file — and is kept deliberately simple to focus on the MCP-specific constructs.

Cargo.toml

[package]
name = "file-explorer-mcp"
version = "0.1.0"
edition = "2021"

[dependencies]
rmcp = { version = "0.1", features = ["server", "transport-io"] }
serde = { version = "1", features = ["derive"] }
schemars = "0.8"
anyhow = "1"
tokio = { version = "1", features = ["full"] }

Server Implementation

use rmcp::{tool, tool_box, ServerHandler, transport::StdioTransport};
// ServerHandler is the trait that #[tool_box] auto-implements for FileServer.
// The import is required because the proc macro generates the implementation
// but the compiler still needs the trait in scope.
use serde::Deserialize;
use schemars::JsonSchema;
use anyhow::Result;
#[derive(Clone)]
struct FileServer;
#[derive(Deserialize, JsonSchema)]
struct PathRequest {
    /// The absolute path to the target directory or file.
    path: String,
}
#[tool_box]
impl FileServer {
    #[tool(description = "List the contents of a directory, returning file and folder names.")]
    fn list_dir(&self, #[tool(aggr)] req: PathRequest) -> Result<Vec<String>> {
        Ok(std::fs::read_dir(&req.path)?
            .filter_map(Result::ok)
            .map(|entry| entry.file_name().to_string_lossy().to_string())
            .collect())
    }
    #[tool(description = "Read the UTF-8 text content of a file at the given path.")]
    fn read_file(&self, #[tool(aggr)] req: PathRequest) -> Result<String> {
        Ok(std::fs::read_to_string(&req.path)?)
    }
}
#[tokio::main]
async fn main() -> Result<()> {
    let transport = StdioTransport::new();
    let server = FileServer;
    server.serve(transport).await?;
    Ok(())
}

What Each Annotation Does

#[tool_box] — Registers all annotated methods in the impl block as discoverable MCP tools and auto-implements ServerHandler for the struct. The runtime uses this to respond to tools/list requests from the AI host.

#[tool(description = "...")] — Attaches the human-readable description passed to the LLM. This string is part of your API contract. A clear, accurate description is what allows the model to invoke the right tool at the right time.

#[derive(Deserialize, JsonSchema)] — serde::Deserialize parses incoming JSON-RPC parameters into the request struct. schemars::JsonSchema generates the JSON Schema the SDK uses for parameter validation and input-shape communication to the host.

#[tool(aggr)] — Maps the entire JSON parameters object to the annotated struct, rather than individual named parameters. This is the idiomatic pattern for structured tool inputs.

? operator — Propagates any failure from read_dir or read_to_string as a structured MCP error response. The host receives a well-formed error it can surface to the model, which can then attempt recovery or inform the user.

Connecting to Claude Desktop

Claude Desktop supports local MCP servers via the stdio transport, spawning the server as a child process and communicating over standard input and output. The configuration lives in the Claude Desktop settings file:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

For development, point Claude Desktop at cargo run:

{
  "mcpServers": {
    "rust-file-explorer": {
      "command": "cargo",
      "args": [
        "run",
        "--manifest-path",
        "/absolute/path/to/your/rust-project/Cargo.toml"
      ]
    }
  }
}

For daily use, build the release binary first to avoid recompilation on every launch:

cargo build --release

Then point Claude Desktop at the compiled binary directly:

{
  "mcpServers": {
    "rust-file-explorer": {
      "command": "/absolute/path/to/your/rust-project/target/release/file-explorer-mcp",
      "args": []
    }
  }
}

After editing the configuration file, completely restart Claude Desktop. A simple window close is not sufficient. The host process must be fully terminated and restarted to reload the server registry and spawn new child processes.

Once connected, Claude Desktop displays available tools and invokes them when relevant to a task. The exact UI representation may vary across application versions — refer to Anthropic’s current Claude Desktop documentation for the latest behavior.

For Cursor users, the configuration follows the same pattern using a .cursor/mcp.json file in the project root:

{
  "mcpServers": {
    "rust-file-explorer": {
      "command": "cargo",
      "args": ["run"]
    }
  }
}

The MCP Attack Surface

MCP gives an AI model the ability to invoke real-world operations. This creates attack surfaces that are qualitatively different from those in traditional API security. What follows covers the most significant threat categories and their mitigations.

1. Tool Poisoning and Rug Pulls

Threat: Tool descriptions are not merely documentation. They are executable context loaded directly into the model’s reasoning. An attacker who controls a tool server can embed hidden instructions inside a description to manipulate the model’s behavior. A \textit{rug pull} is a related variant — a description that appears benign at approval time is later modified to include malicious instructions, without triggering a new consent prompt.

Mitigations:

• Treat tool descriptions as code. Subject them to the same review, versioning, and testing as application logic.
• Pin tool versions and use cryptographic signing to bind tool definitions to verified, immutable versions.
• Monitor descriptions for changes between sessions and force re-approval whenever a description changes.

2. The Confused Deputy Problem

Threat: An MCP proxy acting on behalf of multiple users may connect to third-party APIs using a single, static client identity. If user-specific authorization is not correctly propagated, an attacker can access a third-party API as a different user, bypassing individual consent.

Mitigations:

• Maintain a per-client consent registry mapping specific OAuth client IDs to the users who approved them.
• Prohibit \textit{token passthrough}, which is the anti-pattern of forwarding a user’s token to a downstream API without re-validation. This eliminates the audit trail and scope enforcement that proper token exchange provides.
• Use token exchange (RFC 8693). The MCP server presents the original user’s token to the authorization server and receives a new, properly scoped downstream token, preserving user attribution at each hop.

3. SSRF via OAuth Metadata Discovery

Threat: During OAuth metadata discovery, a malicious server can supply URLs pointing to internal infrastructure, including private IP ranges, cloud metadata endpoints (e.g., 169.254.169.254), or localhost services, causing the MCP client to make unauthorized requests on its behalf.

Mitigations:

• Enforce HTTPS for all OAuth-related URLs in production environments.
• Block requests to private and reserved IP address ranges, including loopback (127.0.0.0/8), link-local (169.254.0.0/16), and RFC 1918 private ranges.
• Validate redirect targets strictly and consider routing OAuth discovery requests through an egress proxy that enforces allowlist-based network policies.

4. Prompt Injection via Sampling

Threat: The MCP sampling feature allows a server to request the AI model to generate content. A malicious server can craft sampling requests containing injected instructions that manipulate the model’s subsequent reasoning, or request that data from other servers be included in the sampling context, thereby exfiltrating information it was never intended to access.

Mitigations:

• Enforce strict context isolation on the client side. A server’s sampling requests must be limited to its own context and must not pull in data from other connected servers.
• Implement runtime monitoring to detect anomalous invocation patterns and unexpected parameter values that may indicate an injection attempt.

5. Cross-Server Data Exfiltration

Threat: In multi-tenant or multi-server deployments, a malicious server can manipulate the shared agent context such that the AI agent inadvertently acts as a data bridge — reading sensitive data from a legitimate server and passing it to the malicious one.

Mitigations:

• Establish behavioral baselines and monitor invocation graphs — records of which tools invoke which other tools — to detect anomalous cross-server data flows.
• Maintain comprehensive audit trails with strict user attribution, logging the originating user, the invoked tool, and the full parameters for every call.

6. Local Compromise and Command Injection

Threat: Local MCP servers are binaries executed directly on the user’s machine. Without sandboxing, a compromised server configuration or an exploited vulnerability can result in arbitrary code execution with the host user’s full OS privileges.

Mitigations:

• Run MCP servers in sandboxed environments — containers or VMs — using minimal base images (distroless or Alpine) with seccomp profiles to restrict available system calls.
• Implement default-deny egress network policies so a compromised server cannot reach arbitrary internet destinations.
• Display a clear, untruncated pre-connection consent dialog showing the exact commands that will be executed before any new local server is connected.

7. Session Hijacking

Threat: An attacker who obtains a valid session ID can impersonate a legitimate client, enqueue malicious tool invocations, or read responses intended for the legitimate user.

Mitigations:

• Never use session identifiers as authentication. They are continuity tokens, not identity assertions.
• Generate session IDs using a cryptographically secure random source to ensure they are non-deterministic and computationally infeasible to guess.
• Bind session IDs to user-specific context (e.g., a compound key of the form <user_id>:<session_id>) so a stolen or guessed session ID cannot be used to impersonate a different user.

8. Scope Creep at Authorization

Threat: Granting broad OAuth scopes (e.g., files:*) at initial authorization increases the blast radius if a token is stolen. It enables lateral data access, privilege chaining, and lets an attacker invoke high-risk tools without triggering any additional authorization prompt.

Mitigations:

• Implement a progressive, least-privilege scope model — request only the minimum scopes needed at initial authorization.
• Use incremental elevation via targeted WWW-Authenticate scope challenges when a higher-privilege operation is first attempted at runtime, deferring scope grants until they are actually required.

Final Thoughts

Rust is not the easiest starting point for MCP development. It requires a steeper initial learning curve than TypeScript or Python, and that trade-off is real. For production deployments where correctness, performance, and security are non-negotiable, however, the properties Rust offers are genuinely well-suited to what MCP demands.

A well-written Rust MCP server eliminates an entire class of memory corruption vulnerabilities at compile time and operates with more predictable resource usage than equivalent implementations in garbage-collected languages. That said, Rust does not secure your application for you. Access control, token scoping, input validation, and infrastructure hardening remain the developer’s responsibility regardless of language.

The ecosystem is ready. Whether you need the official conformance of rmcp, the enterprise observability of pmcp, the protocol cutting-edge of mcpkit, or the minimalism of async-mcp, there is a crate positioned for your use case. Start simple, avoid .unwrap() in production code from day one, and build the security perimeter before you build the features.

Why Rust is the Right Language for the Model Context Protocol (MCP) was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

As agents become the primary intermediaries for the web, the very nature of design is being inverted. For decades, product development has been optimized for human eyes by focusing on visual hierarchies, hooks, and the journalistic five W’s. However, the rise of autonomous agents suggests a fundamental shift in how digital content is structured and consumed.

Beyond the Hook: Prioritizing Comprehensive Data

Traditional content strategies rely on catchy leads to grab human attention, as readers often skim or miss details buried deep in a text. Agents do not prioritize a catchy lead. They can ingest a 50-page document instantly to find a single insight buried on page 49. This capability renders the hook less relevant for machine consumption. Instead of front-loading information for impatient human readers, the new imperative is to create content that remains legible and structurally sound for an AI that reads every word with equal attention.

The Shift to Machine Legibility

The industry is moving from human-centric UI, such as clicking through complex Salesforce menus or staring at Grafana dashboards, to machine legibility. In previous workflows, a human engineer might piece together data from a visual dashboard to diagnose an issue. In the emerging model, an agent will ingest telemetry data directly and report hypotheses into Slack.

Visual design becomes less central to overall comprehension as agent usage grows. The new optimization is not visual hierarchy but machine legibility, and that will change the way creators work and the tools they use.

The Emergence of GEO Tools

This shift gives rise to GEO, or Generative Engine Optimization. Companies are already using GEO tools to ensure their products are the ones recommended when an agent, rather than a human, scours the web. Just as SEO optimizes content for search engine ranking algorithms, GEO optimizes content for agent ingestion and synthesis. Organizations now face the question of what AI agents want to see to ensure they appear when consumers prompt platforms like ChatGPT for the best corporate card or shoes.

The Content Cliff and Future Risks

A significant risk involves a content cliff where the cost of creation hits zero. This economic shift could lead to a flood of high-volume, low-quality content designed solely to capture agent attention. In this scenario, creators might generate vast amounts of hyper-personalized material, utilizing specific keywords intended for the era of agents to ensure relevance across diverse queries. This creates a digital environment where the primary audience for the vast majority of web content is no longer human but algorithmic.

Conclusion

The era of designing for humans first is evolving into an era of designing for AI agents. As the optimization target shifts from visual engagement to data legibility, the definitions of quality content and effective software interface are being rewritten. Success in this new landscape will depend on the ability to structure information in a way that machines can not only read but also prioritize and act upon.

Designing for Machines: The Era of Generative Engine Optimization (GEO) was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

The evolution of distributed systems often involves a transition from theoretical speed to practical reliability. This trajectory is evident in the recent update to the Sui consensus engine. The shift from Mysticeti v1 to Mysticeti v2 marks a move from an experimental design to a production-grade protocol.

This article outlines the specific engineering changes between the two versions. It focuses on the resolution of liveness vulnerabilities and the restructuring of the transaction submission pipeline.

1) The Liveness Challenge: Round Jumping vs. Backfilling

The most critical differentiator between v1 and v2 is how the protocol handles validator latency. In any distributed network, validators may fall behind due to network connection issues or processing delays. The mechanism used to catch up to the rest of the network determines the stability of the chain.

A) The Mechanism in Mysticeti v1

In the first iteration, the protocol utilized a Round Jumping mechanism. If a validator went offline and reconnected to find the network was several rounds ahead, it was programmed to immediately synchronize with the current round.

This approach prioritised speed. The lagging validator would skip the intermediate rounds to rejoin the active consensus tip immediately. However, researchers identified a theoretical flaw in this logic. If a sufficient number of honest validators utilized this jumping mechanism simultaneously, they would fail to produce the necessary votes (vertices) for the rounds they skipped.

This created a potential deadlock. The network could not finalize past blocks because validators had skipped the work required to validate them, yet the validators were already operating in future rounds. This resulted in a stalled chain.

B) The Solution in Mysticeti v2

Mysticeti v2 introduces a Modified Round-Jumping behavior that enforces backfilling.

When a validator in v2 determines it is behind the network tip, it is prevented from simply jumping to the front. Instead, the protocol requires the validator to generate vertices for the rounds it missed.

The functional difference is as follows:

• v1 approach: A validator sees the network is at Round r+3. It immediately starts participating in r+3. Rounds r+1, r+2 are left without its contribution.
• v2 approach: A validator sees the network is at Round r+3. It rapidly reconstructs and signs its participation for Rounds r+1 and r+2 before joining Round r+3.

This ensures that the Directed Acyclic Graph (DAG) remains dense and connected. Even if network instability causes many validators to lag, the history remains fully validated. This guarantees liveness and prevents the consensus engine from stalling.

2) Architectural Refactoring: Transaction Submission

The second major shift involves the architecture of transaction submission. This change moves transaction management closer to the consensus core to reduce latency and system complexity.

A) Mysticeti v1: The Quorum Driver

In v1, transaction submission relied on an external component known as the Quorum Driver. This component operated somewhat independently of the consensus engine. Its role was to gossip transactions to validators and aggregate signatures to form a certificate.

This process occurred pre-consensus. While effective for certain loads, it introduced an additional hop in the data pipeline. The validators had to wait for this external aggregation before the data could be ordered by the consensus protocol.

B) Mysticeti v2: The TransactionDriver

Mysticeti v2 deprecates the Quorum Driver in favor of an integrated TransactionDriver.

In this updated architecture, the submission logic is embedded directly within the validator node. Validators now ingest transactions directly into the DAG without requiring a separate, pre-consensus handshake to form certificates.

Key Technical Implications:

• RPC Changes: RPC handlers previously used for signing transactions and aggregated submissions have been disabled.
• Pipeline Efficiency: By removing the pre-consensus signature aggregation step, the protocol achieves a consensus latency of approximately 300ms. The validation and ordering occur in a single, streamlined workflow.

3) Formal Verification

The final distinction between the two versions lies in the level of mathematical assurance provided.

Distributed consensus protocols are notoriously difficult to prove correct due to the complexity of asynchronous network states. Mysticeti v1 was released with manual proofs. Subsequent auditing revealed gaps in these proofs, specifically regarding the liveness issues described above.

Mysticeti v2 has undergone Mechanized Safety and Liveness Proofs. The engineering team utilized the LiDO-DAG framework to formally verify the protocol. This process involves using software to check the logic against all possible network states. This verification mathematically guarantees that the v2 code will not fork (safety) and will not stall (liveness) under defined adversarial conditions.

4) Summary

The transition to Mysticeti v2 is not merely an optimization update. It represents a fundamental repair of the synchronization logic and a simplification of the submission architecture.

For developers and node operators, v2 offers a stable foundation that eliminates the edge cases present in the experimental v1 release.

Technical Comparison of Mysticeti v1 and v2 was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Web3 technologies have not just digitized money; they have fundamentally altered the physics of financial crime. A new academic survey reveals that crypto laundering is no longer about finding a single loophole, it is about exploiting the structural features of decentralized systems, that is permissionless access, cross-chain interoperability, and data fragmentation.

This article breaks down the new Placement-Layering-Integration (PLI) lifecycle, the six specific strategies criminals use to break transaction chains, and the emerging arms race between privacy and detection.

1) A New Crime Lifecycle

In traditional finance, money laundering follows a strict sequence: Placement (cash enters the bank) → Layering (moving it around) → Integration (buying a house).

In Web3, this model is breaking down.

• The Placement Bypass: For Web3-native crimes like DeFi hacks, scams, or code exploits, the Placement phase is often skipped entirely. The funds are already digital and already in the system at the moment of the crime.
• Compressed Stages: The distinctions between layering and integration blur. For example, buying a high-value NFT can serve as both a layering technique (hiding the trail) and integration (holding a valuable asset) simultaneously.

Key Insight: Investigators can no longer rely on following the deposit. When the crime originates on the blockchain, the investigation must start immediately with the Layering phase.

2) The Taxonomy of Disguise: Six Core Strategies

The survey identifies that regardless of the platform used, criminals rely on six fundamental strategies to clean funds. These are categorized by their intent: Confuse, Sever, or Exploit.

A. Strategies of Confusion (Obfuscation)

These tactics aim to drown the investigator in data noise.

1. Transaction Flow Obfuscation (TFO): This involves creating complex graphs that mimic legitimate activity.

• Peeling Chains: A large amount of crypto is peeled off in small chunks over time to different addresses, making it look like normal spending rather than a bulk transfer.
• Dusting: Sending tiny amounts of crypto to many wallets to clutter the analysis or poison a user’s transaction history.

2. Commingling: The digital equivalent of mixing bad money with good. By pooling funds from multiple sources (e.g., in a CoinJoin or a DeFi pool), the direct link between sender and receiver becomes probabilistic rather than deterministic.

B. Strategies of Disconnection (Severing Ties)

These are more advanced tactics designed to break the on-chain link entirely.

3. Chain-Hopping: Criminals move assets across different blockchains (e.g., converting Ethereum to Bitcoin). Since blockchains are isolated state machines, the transaction trail ends on one chain and begins anew on another, requiring investigators to stitch together disparate datasets.

4. Disconnected Fund Flow (DFF): This achieves near-total anonymity.

• The DRT Technique: Disjoint Reciprocal Transfers involve two parties exchanging assets without a direct transaction link, often orchestrated off-chain or through matching orders that don’t look like a direct swap.
• Privacy Coins & ZKPs: Using protocols like Monero or Zcash that cryptographically hide amounts and sender/receiver addresses.

C. Strategies of Exploitation

5. Subjective Valuation: Using assets with no fixed price (like NFTs) to justify massive transfers. A criminal buys their own worthless NFT for $1 million using illicit funds, legitimizing the wealth as art trading profits.

6. Regulatory Arbitrage: Routing funds through Non-Compliant exchanges or jurisdictions with weak AML (Anti-Money Laundering) enforcement to cash out.

3) The Launderer’s Toolkit: Intermediary Mechanisms

Strategies need tools. The report highlights that criminals repurpose legitimate Web3 infrastructure for illicit ends.

4) The Detective’s Problem: The Data Gap

The biggest misconception is that blockchains are perfectly transparent. While transactions are visible, identities and intent are not.

The survey identifies three data silos that hinder investigations:

1. On-Chain Data: Public but noisy. It requires sophisticated heuristic clustering to guess if 100 addresses belong to one person.
2. Off-Chain Data: The Rosetta Stone (KYC records, IP addresses) is held by centralized exchanges (CEXs). Access requires subpoenas and international cooperation, which is slow and often blocked by jurisdictional borders.
3. Cross-Chain Traces: The Black Hole. When funds move from Bitcoin to Ethereum via a centralized swap, the link exists only in the exchange’s private database. If the exchange is non-compliant, the trail goes cold.

5) Countermeasures & Future Outlook

The industry is currently in an arms race between obfuscation technologies (like privacy-preserving mixers) and deanonymization tools (forensic AI).

The Limits of Current Defense

• Rule-Based Failures: Traditional systems that flag transactions over $10k fail in crypto, where criminals use software to split millions into thousands of micro-transactions (smurfing/peeling).

• The Privacy Paradox: Privacy tools (Zero-Knowledge Proofs) are essential for legitimate business confidentiality but are inherently dual-use, protecting criminals just as effectively.

The Path Forward

The survey suggests the future lies in Compliance-Aware Privacy:

• Smart Contract Blocklists: DeFi protocols embedding code to automatically reject funds from sanctioned addresses.
• Zero-Knowledge Compliance: New cryptographic tools that allow users to prove they are not criminals (e.g., I am not on a sanctions list) without revealing their identity or entire transaction history.

Final Thought

As Web3 matures, money laundering is evolving from a series of transfers into a complex interaction of code, liquidity protocols, and cross-chain messaging. Effective prevention requires moving beyond Know Your Customer (KYC) to Know Your Transaction (KYT), analyzing behavioral flows across the entire decentralized map.

Web3 Money Laundering: A Taxonomy of Strategies, Mechanisms, and Countermeasures was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

The blockchain industry is moving beyond speculative tokens toward Real-World Asset (RWA) tokenization — institutional-grade securities such as equity, debt, and funds that must operate within strict legal and compliance frameworks. For these assets to scale, they cannot rely on off-chain processes alone.

ERC-3643 (also known as the Token for Regulated Exchanges protocol) addresses this gap by embedding compliance directly into token transfer logic. It enables permissioned digital assets that retain familiar ERC-20 usability while enforcing on-chain identity, KYC/AML eligibility, and transfer restrictions, ensuring only qualified participants can hold and move the asset under the applicable rules.

Why ERC-20 isn’t enough for regulated assets

ERC-20 is great at answering: Does Alice have enough balance to send Bob tokens?

It is not designed to answer:

• Is Bob KYC-verified?
• Is Bob in a permitted jurisdiction?
• Would this transfer exceed a cap on investors in a country?
• Is Alice currently sanctioned or offboarded?
• Is this transfer allowed under the offering’s rules right now?

In traditional markets, these checks live in intermediaries — transfer agents, brokers, custodians, fund administrators — and are enforced through processes and legal agreements.

ERC-3643’s key idea is to push parts of that enforcement into the token’s transfer logic so the asset itself refuses non-compliant moves.

What ERC-3643 is

ERC-3643 (EIP-3643) — also known as the Token for Regulated Exchanges (T-REX) standard/protocol — is a suite of interfaces and smart contracts for issuing and transferring security tokens in a compliant way, using an automated on-chain validator system and on-chain identities for eligibility checks.

In practice, it separates concerns into modular components: identity is handled by an identity system and registries; compliance rules live in a dedicated compliance contract; and the token consults them before completing transfers.

The building blocks: identity + rules + token

ERC-3643’s architecture is easiest to understand as three cooperating pieces:

1) The Permissioned Token (ERC-20 compatible behavior, stricter transfer rules)

This is the asset contract: balances, transfers, allowances — plus hooks to consult identity and compliance components before a transfer finalizes. Many implementations describe this as a permissioned token that “holds references” to identity and compliance contracts and consults them before transfers.

2) Identity Registry (who is allowed to hold/receive)

The Identity Registry maps wallet addresses to verified identities and associated attributes (commonly including jurisdiction/country). It also manages claims linked to identities, with claims issued by trusted entities (“claim issuers”). The registry interacts with compliance logic to ensure only eligible participants transact.

3) Compliance Contract (what transfers are allowed)

The Compliance layer encodes offering/transfer rules — think “policy-as-code.” A common pattern described in ERC-3643 materials is a canTransfer check (often implemented in a modular compliance contract) that determines whether a transfer should be permitted under current rules and state.

Supporting registries: who can attest, and what counts as a valid claim

The EIP also describes registries that define:

• Trusted Issuers (which entities can issue valid claims), and
• Claim Topics (which claim types are required, e.g., “KYC passed”, “accredited investor”, “not sanctioned”).

This is what turns a whitelist into a more flexible identity-and-claims system.

A concrete transfer flow: where KYC/AML is enforced on-chain

Here’s what a compliance-by-design lifecycle looks like in practice:

Step 1 — Onboard an investor (off-chain verification, on-chain attestation)

• Investor completes KYC/AML with a provider (or regulated institution).
• A trusted claim issuer writes an attestation/claim to the investor’s on-chain identity (not necessarily personal data — often just the fact that requirements are met).

Step 2 — Link wallet(s) to the verified identity

• The investor’s wallet address is registered in the Identity Registry and marked verified/eligible according to the required claim topics.

Step 3 — Attempt a transfer

When Alice transfers to Bob, the token checks:

• Is Bob’s wallet linked to a verified identity? (Identity Registry)
• Does this specific transfer satisfy offering rules right now? (Compliance / canTransfer)

If the answer is no at any point, the transfer reverts — meaning the non-compliant movement simply cannot settle on-chain.

Step 4 — Ongoing monitoring and updates

Compliance isn’t static. If an investor becomes ineligible (expired KYC, sanctions update, change in residency), the identity/compliance layer can be updated so future transfers are blocked. This is one reason ERC-3643 focuses on registries and modular rules, rather than hardcoding logic directly into an immutable token contract.

What KYC/AML enforcement on-chain really means (and what it doesn’t)

ERC-3643 is often summarized as “KYC and AML on-chain”. That’s directionally true, but it’s worth being precise:

What it can enforce on-chain

• Eligibility gating: only verified identities can hold/receive.
• Transfer restrictions: jurisdiction rules, investor caps, holding limits, or other offering constraints encoded in compliance modules.
• Operational control points: controlled onboarding/offboarding via agents/issuer roles (common in T-REX implementations).

What it doesn’t replace

• The off-chain work of verifying documents, screening, risk scoring, suspicious activity reporting, and regulatory filings still lives in regulated entities and service providers.
• ERC-3643 helps ensure that the result of those processes (eligibility status and rules) is enforced at settlement.

Think of it as programmable settlement constraints, not a full compliance department in Solidity.

Where ERC-3643 shines: real-world patterns

Regulated securities and funds

Private funds and security tokens often need strict control over who can hold, how many holders can exist in a jurisdiction, and whether secondary trading is allowed. ERC-3643 is explicitly positioned for these regulated contexts.

Tokenized RWAs on permissionless chains (with permissioned holders)

A common misconception is that permissioned assets require permissioned blockchains. ERC-3643’s model is: permissionless chain, permissioned token holders — enabled by identity and compliance gates.

Institutional distribution with audit-friendly controls

Because the compliance decision is executed by code and recorded on-chain, auditors and operators get clearer evidence of what rules were enforced and when, compared to fragmented off-chain systems.

Edge cases you’ll hit in production (and how ERC-3643 helps)

1) Wallet rotation and lost keys

Investors change wallets, custodians rotate addresses, and smart contract wallets upgrade. With an identity registry approach, you can re-associate a verified identity to a new wallet without changing the investor’s eligibility model.

2) Sanctions list updates and instant offboarding

If a participant becomes ineligible, you need future transfers blocked immediately. ERC-3643’s registry + compliance design supports revoking eligibility (or failing required claim topics), stopping new settlements.

3) Custody and omnibus accounts

Institutions often use omnibus wallets holding assets on behalf of many beneficial owners. ERC-3643 can support this pattern, but you’ll need clear policy decisions:

• Is the custodian the verified holder, or are beneficial owners individually verified?
• How do you reconcile on-chain eligibility with off-chain sub-ledgers?

4) Secondary markets and controlled liquidity

Many offerings allow primary issuance but restrict secondary transfers (or restrict to specific venues). Encoding these constraints in compliance logic helps prevent accidental free-for-all liquidity.

5) Cross-chain bridges

Bridging is where compliance often breaks: tokens move to another chain, and suddenly the destination has no idea who’s eligible.

A compliance-aware bridge pattern typically means:

• The bridge contract on the source chain only accepts deposits from verified identities.
• The minted/wrapped token on the destination chain enforces the same identity + compliance checks (or refuses transfers entirely unless a parallel identity system exists there).

In other words: bridging value is easy; bridging eligibility is the hard part. ERC-3643 gives you a blueprint for making eligibility a first-class primitive rather than an off-chain assumption.

Benefits and tradeoffs

Benefits

• Compliance-by-design: rules enforced at settlement, not just in paperwork.
• Modularity: identity, rules, and token logic are separated for clearer governance and upgrades.
• Interoperability mindset: built around ERC-20-like tokens, but with required compliance hooks.

Tradeoffs/risks

• Privacy: Don’t put personal data on-chain. Use attestations/claims and minimize metadata.
• Trust model: You must trust claim issuers and the governance around who is trusted.
• Operational overhead: Onboarding/offboarding, claim expiry handling, incident response, and audits become part of the product — not an afterthought.

Conclusion

ERC-3643 doesn’t magically solve regulation. What it does do is remove a common failure point in tokenization: assets that are legally restricted but technically unrestricted.

By making identity and transfer rules part of the token’s settlement path, ERC-3643 acts as a practical bridge between two worlds that usually clash — open blockchain rails and regulated market constraints.

ERC-3643: The On-Chain Compliance Bridge for Regulated Digital Assets was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.