We believe in win-win scenarios, and so we’re launching the R0GUE Referral Program for any facilitator who connects us with qualified clients: founders, CTOs, protocol teams, enterprise leads, fintech operators.

If they need consulting across our core verticals (AI, Blockchain, Rust/EVM Smart Contracts, Rust-based tooling/integrations) and the engagement closes, you earn a competitive referral fee, 5–10% of the contract value depending on pre-qualification, via revenue sharing.

No complicated tiers. You make an introduction, we close the deal, win-win.

Who We Are And What We Do

R0GUE was founded by former Parity engineers from the Ecosystem Development team: the go-to-market engineering group responsible for consulting teams building their own chains, smart contracts, and integrations across the Polkadot ecosystem.

We’ve carried that expertise forward and sharpened it. Some highlights from our work so far:

Testimonials from our Partnership engagements:

“Collaborating with the R0GUE team was highly positive: the robust documentation, user-friendly Pop CLI, and excellent support to deploying teams were consistently impressive.” — Web3 Foundation

“Working with R0GUE to explore our specific business use case on the Polkadot blockchain was a fruitful experience. R0GUE’s deep understanding of the Polkadot ecosystem and its nuances proved incredibly valuable as we assessed the best path forward.” — Raise

“R0GUE quickly understood the challenge, cut through the complexity, and delivered fast under tight constraints. No fluff, no friction, just sharp execution when it counted.” — Interlay

Public Good and Developer Infrastructure Showcases:

• Pop CLI: The only quickstart development tool for building smart contracts and appchains in the Polkadot docs
• ink!: Polkadot’s native Rust smart contract language (eDSL)
• Paseo: Core co-maintainers of Polkadot’s community testnet

Delivery Statistics: 5 blockchains built — 26+ projects advised — 76 blockchains supported.

Years of hands-on consulting, from chain architecture to smart contract deployment to AI infrastructure, have given us a depth of Rust-native blockchain expertise that few teams can match on execution.

How We Deliver

We are not a slide deck consultancy. We embed and co-execute.

Engagement Options

Our consulting delivery model is built around three modes:

• Co-Build: Our engineers work alongside yours. Shared repos, shared standups, shared accountability. We ship together.
• Full-Build: We own the delivery end-to-end: architecture, implementation, testing, deployment. Production-grade output with full handover.
• Advisory & Architecture: For teams with strong internal engineering that need strategic direction, architecture review, or specialist Rust/blockchain expertise on-demand.

Every engagement includes knowledge transfer. We don’t create dependency. We build capacity.

What We Deliver / Where We See Opportunity

We build across many verticals, including:

Protocol Development: Smart Contracts & Chains

This is our foundation. Custom smart contract development, blockchain architecture, runtime engineering, and end-to-end chain builds on Polkadot SDK. From single-contract deployments to full chain launches, we handle the design, implementation, testing, and deployment. Teams come to us when they need blockchain engineering done right the first time.

Engagements include contract and runtime development, chain architecture design, testnet deployment, production launch support, and ongoing maintenance.

Confidential AI and Inference

Enterprises need to run AI workloads on sensitive data without exposing it. Confidential computing is scaling at ~64% CAGR. TEE-protected inference is production-ready. The intersection of blockchain verification and confidential AI is where we operate: verifiable, private, trust-minimised. We don’t just build AI agents, we build custom architecture to leverage AI-enabled blockchain use cases.

Recent delivery includes architecture and implementation of TEE-protected inference pipelines and on-chain verification layers. Typical engagements range from architecture design through to production deployment.

Stablecoins

The GENIUS Act is signed into law. MiCA enforcement hits full stride in July 2026. Every bank, fintech, and payment processor touching stablecoins needs infrastructure, integration architecture, and technical advisory. We build the rails to make this happen.

RWA Tokenization

Tokenized real-world assets on-chain have grown fivefold in three years. Institutional players are deploying capital into private credit, treasuries, and real estate on-chain. They need custom runtime logic, compliance frameworks, and smart contract infrastructure built by teams that understand both the technology and the regulatory landscape.

Got other ideas in mind? We are out-of-the-box thinkers and would love to hear them!

Who Should You Refer?

Anyone building serious infrastructure in these spaces:

• Enterprise teams & Startups (Series A+) deploying confidential AI inference, verifiable compute, or needing blockchain expertise
• Fintech teams integrating stablecoin payments or issuing tokens under GENIUS Act or MiCA
• Asset managers and financial institutions tokenizing real-world assets
• Protocol teams building DeFi, cross-chain bridges, or on-chain compliance systems
• Web3 projects that need Rust protocol/smart contract, or EMV development expertise

How It Works

1. You introduce us. Email, DM, warm intro. Whatever works.
2. We take it from there. Discovery, scoping, proposal. You stay informed but don’t need to do the selling.
3. The deal closes. You receive a referral fee on revenue generated. Straightforward, transparent, paid promptly.

We’ll provide you with a simple overview of our services and the types of engagements we take on, so you can spot opportunities when they come up in conversation.

Get Started

Reach out to us directly to join the referral program. We’ll set you up with everything you need: a clear brief on what we do, the verticals we serve, and how to identify a good-fit introduction.

Build networks. Share upside.

Go R0GUE.

Lets Talk!

At R0GUE, we’ve spent the last year getting our hands dirty with AI in the only way that matters, solving our own problems and those of our partners.

Sometimes that’s been external, building agent workflows for clients, prototyping AI systems that touch real organisational processes, and architecting TEE-backed infrastructure where blockchain attestations anchor trust in environments where verification is mandatory.

And sometimes it’s been internal. We rolled out RAI (R0GUE AI) across the team, started building our own agents, and pushed our experiments far enough that the line between “technical” and “non-technical” have begun to slightly blur. When teammates who don’t write code, are able to push mergeable GitHub commits because an agent made it feel natural, it bridges an execution gap.

That shift matters materially, because now, in an agent-enabled world where words are cheaper than ever, being able to inform, understand, and take action to solve problems quickly and autonomously becomes the source of fundamental value.

Quietly, we’ve been assembling our own “army” of agents inside R0GUE: purpose-built, specialized, and getting sharper every day.

What follows is a major piece of research we needed to do, delegated to subagents.

AI Generated Research Start

The Agentic Web: Why Autonomous AI Demands Verifiable Infrastructure

40% of enterprise applications will ship with task-specific AI agents by 2026. That’s up from less than 5% in 2025.1

75% of enterprises are adopting confidential computing. The market hits $350 billion by 2032.2 3

By 2029, Gartner projects 75% of operations on untrusted infrastructure will be secured by confidential computing.4

These numbers tell a story. Not about hype cycles or speculative trends. About a fundamental replatforming of how computation gets processed, protected, and verified.

The question isn’t whether confidential computing becomes foundational infrastructure. That’s already happening. The question is whether the agentic web: the emergent network of autonomous AI systems managing real assets and making consequential decisions, will be built on verifiable guarantees or trust assumptions that collapse under adversarial conditions.

The Problem: AI Agents on Broken Infrastructure

AI agents are shipping. They manage portfolios, execute trades, coordinate workflows, and make decisions with real economic consequences. Gartner projects agentic AI could drive 30% of enterprise application software revenue by 2035, exceeding $450 billion.5

The infrastructure they run on was never designed for this.

Traditional cloud infrastructure requires trust. Trust in the provider. Trust in the hypervisor. Trust that your data isn’t being observed, copied, or manipulated. For AI agents operating autonomously, especially those handling financial assets, personal data, or enterprise workflows, this trust model doesn’t hold.

The security numbers are brutal:

• 6% of organizations have an advanced AI security strategy.6
• 40%+ of agentic AI projects will be canceled by end of 2027: escalating costs, unclear value, inadequate risk controls5
• 40% of AI data breaches by 2027 will trace to improper cross-border GenAI use7
• Shadow Agents: unsanctioned AI tools deployed without IT approval, now exceed 50% of enterprise AI usage6

One security analyst framed it directly: “An agent is always on, never sleeps, never eats; but if improperly configured, it can access the keys to the kingdom: privileged access to critical APIs, data, and systems, and it’s implicitly trusted. If enterprises aren’t as intentional about securing these agents as they are about deploying them, they’re building a catastrophic vulnerability.”6

The agentic web demands verifiable guarantees. Not promises.

The Transparency-Confidentiality Paradox

Blockchains solved half the trust equation. Transparency. Immutability. Verifiable execution. Every transaction auditable. Every state change provable. Exactly what autonomous agents need for accountability.

But blockchains achieve this through radical openness. Every computational step executes across thousands of nodes. Every byte of state gets replicated, inspected, permanently recorded. For value transfers and deterministic logic, this works. For AI inference, it creates an impossible architecture.

Consider what on-chain inference would actually require.

A single forward pass through a large language model: billions of floating-point operations across matrices with hundreds of millions of parameters. Ethereum’s block gas limit sits at 60 million gas units. The math doesn’t work. Not by a small margin. By orders of magnitude.

Even if compute weren’t a constraint, the transparency model breaks AI at a fundamental level.

Model weights become public state. Deploy inference logic to a smart contract and your weights are readable by anyone querying the chain. Model IP, training investments, competitive differentiation: all exposed.

User inputs become transaction data. Every prompt, every query, every sensitive document you send for processing gets broadcast to the mempool, visible to validators during execution, immutably recorded for permanent retrieval.

Validators see everything. This isn’t a bug. It’s how consensus works. Nodes must execute identical computations to agree on state. There is no encryption scheme that lets validators verify execution without seeing what they’re executing.

The result: AI agents get forced off-chain, posting only results back to the blockchain. But this reintroduces exactly the trust assumptions blockchain was supposed to eliminate. When inference happens in an opaque environment, “verified on-chain” means nothing more than “someone claims this is the output.” The chain becomes an expensive database for unverifiable assertions.

This is the paradox. Blockchain’s transparency enables trust but destroys confidentiality. Off-chain execution preserves confidentiality but abandons verifiability.

The agentic web requires both. Until now, no architecture delivered them together.

Confidential Computing: The Third Pillar

The solution: Trusted Execution Environments. Hardware-isolated enclaves that protect code and data during execution. A TEE functions as a cryptographic vault embedded directly into the CPU and GPU. Computation happens in isolation from the host system, the hypervisor, and even the infrastructure operator.

Gartner defines confidential computing as technology that “uses hardware-based trusted execution environments (TEEs) to keep data and workloads protected while in use… facilitating secure processing of sensitive data and AI, meeting strict privacy and compliance demands in any environment.”4

For decades, we protected data at rest with disk encryption. Data in transit with TLS. TEEs complete the triad: protecting data in use.

Before any sensitive operation begins, a process called attestation cryptographically proves the enclave is authentic and untampered. Only then is private data or a proprietary model unlocked for use inside the secure boundary. Trust that is verifiable, not assumed.

Performance matters here. Unlike fully homomorphic encryption or multi-party computation, TEEs execute at near-native speeds. Phala Network’s 2025 benchmarks: 0.5–5% overhead in production conditions, processing over 1.34 billion LLM tokens in a single day.8

For real-time AI inference with tight SLAs, this is the difference between viable and theoretical.

Confidential Inference: AI That Proves Its Integrity

Confidential inference combines TEE isolation with cryptographic attestation. The result: AI systems where:

• Model integrity is verifiable: Attestation proves which model is running, that it hasn’t been tampered with
• Inputs remain private: User data never leaves the encrypted enclave
• Outputs are authenticated: Signed, tamper-evident responses prove they originated from the attested model
• The infrastructure operator is untrusted: Even the cloud provider cannot observe computation

This isn’t theoretical.

NVIDIA’s Confidential Computing extends TEE protections to GPU memory and execution flows, enabling secure training and inference where both model and data remain confidential.9

The NVIDIA H100 Tensor Core GPU was first to support confidential computing with a hardware-based TEE anchored in an on-die hardware root of trust. The latest NVIDIA Vera Rubin NVL72 delivers rack-scale confidential computing across NVLink: a unified security domain spanning 72 GPUs, 36 CPUs, and interconnects.9

For AI agents on blockchain infrastructure, this changes everything. An agent can prove it executed a specific model, followed a specific policy, produced a specific output: without revealing the model weights, the input data, or any proprietary logic.

The Hard Truth: TEEs Are Not a Silver Bullet

TEE security has been broken before. It will be broken again.

Late 2025, security researchers disclosed WireTap: a physical attack that compromises Intel SGX on server processors using DRAM bus interposition. The attack exploits deterministic encryption in Intel’s Total Memory Encryption. As documented: “a given plaintext and key will result in a fixed ciphertext over every execution,” enabling attackers to map encrypted memory to unencrypted values.10

The practical impact:

• Researchers extracted SGX attestation keys
• They forged valid SGX quotes that pass Intel’s verification
• Working attacks demonstrated on live production infrastructure
• Hardware required: less than $1,000

Intel’s response is that physical access attacks remain “out of scope” for SGX.

The consequences were real. Integritee Network, a Polkadot-based confidential computing project, shut down in late 2025 partly due to WireTap’s implications. Their post-mortem was direct: “Today, only permissioned (data center-controlled) deployments are considered viable. That breaks the premise of trustless oracles, which relied on not having to trust operators or data centers at all.”11

This is not an argument against TEEs. It is an argument against single-layer security assumptions.

Defense in Depth: Proof of Cloud

The emerging response: defense in depth. Requiring attackers to breach multiple independent security barriers rather than one.

Proof of Cloud represents this approach: a vendor-neutral alliance maintaining a signed, append-only registry that binds TEE hardware identities to verified physical locations.12

Three components:

1. Hardware Identity Binding: TEE attestation generates quotes linking unique hardware identifiers (Intel’s DCAP PPID, AMD’s Chip ID) to workload measurements
2. Independent Verification: Alliance members independently verify hardware locations through facility visits, extracting IDs via attestation and cross-validating findings
3. Transparent Registry: Verified entries populate an append-only signed log resembling Certificate Transparency, requiring supermajority signatures for updates

The security model is explicit: attackers must breach both TEE security and physically compromise a facility verified by multiple independent organizations. Neither layer alone is sufficient. Both together materially raise the cost of attack.

This is how production infrastructure actually gets secured. Not through perfect components. Through layered defenses where each failure mode requires independent compromise.

Enterprise Adoption: Beyond Pilots

The shift to confidential computing is not speculative. Adoption has crossed from experimentation to production.

The Numbers

A global IDC survey of 600+ IT leaders across 15 industries: 75% of organizations are now adopting confidential computing.2

Not pilot-phase curiosity. Of these organizations:

• 18% already in production
• 57% actively piloting or testing
• 71% of public cloud users implementing

Gartner positioned confidential computing as one of its Top 10 Strategic Technology Trends for 2026, alongside AI supercomputing as a foundational enabler. Gartner places it among the three core “Architect” technologies shaping enterprise infrastructure over the next five years.4

Market projections:

These aren’t incremental growth numbers. This is fundamental replatforming.

Adoption Drivers:

Measurable benefits:

Regulatory Acceleration

The regulatory environment is forcing this shift:

• EU DORA explicitly requires encryption for data at rest, in transit, and in use. 77% of organizations more likely to consider confidential computing due to DORA requirements.2
• EU AI Act adds compliance pressure for AI systems processing sensitive information. Fines: 7% of global revenue.
• Colorado SB24–205 mandates risk management and impact assessments for high-risk AI, effective June 2026 (delayed from February 2026 via SB 25B-004)
• Singapore MAS guidelines recommend confidential computing for data-in-use protection

Gartner predicts by 2027, at least one global company will see its AI deployment banned by a regulator for noncompliance with data protection or AI governance legislation.7

Vertical Adoption: Where Confidential Computing Ships Today

Finance and Banking

Market position: BFSI accounted for 46.8% of confidential computing revenue in 2024. Largest vertical.3

Financial institutions were early adopters: stringent regulatory mandates, high-value data. Key use cases:

Fraud Detection and AML: Banks pool encrypted transaction data for cross-institutional fraud pattern detection. Multiple institutions train AI models on combined, never-decrypted datasets to identify fraud patterns. No single bank sees another’s raw data.13

Multi-Party Computation: Federated learning enables competing banks to craft money laundering detection models using each other’s transaction data without exposing sensitive raw data to competitors.

Secure Cloud Migration: Financial institutions can now move workloads previously deemed too risky for public cloud, with cryptographic assurance that data remains confidential.

Risk Analytics: Firms outsource complex risk calculations to third-party providers with proprietary models and portfolio data protected within enclaves.

Healthcare

Healthcare organizations use confidential computing to solve a fundamental tension: the need to analyze patient data for better outcomes versus the obligation to protect that data under HIPAA and GDPR.

Decentriq and Datavant partnered to enable privacy-preserving data collaboration between health researchers and European hospitals. Confidential computing deployed a secure data clean room where patient-level data could be analyzed without ever being exposed. GDPR compliance maintained, clinical research advanced across borders.14

Super Protocol and Yma Health demonstrated real-world patient information can be safely used for AI-driven innovation without compromising privacy or compliance. All operations, from EHR extraction to AI inference, run entirely inside TEEs. Sensitive data never exposed, even to infrastructure providers.15

Government and Defense

Government agencies implement confidential computing for workloads where the traditional cloud trust model is unacceptable:16

• Classified data processing: Secure analysis of sensitive defense information in cloud environments
• Multi-level security: Operations requiring different classification levels within single environments
• Secure communications: Protecting military communications during processing and routing
• Joint operations: Secure information sharing between allied forces and agencies

This isn’t about cost optimization. It’s about capability: enabling cloud adoption for workloads that could never move off-premise under traditional security models.

Retail and E-Commerce

Growth rate: 66.9% CAGR. Fastest growing vertical.3

The driver: privacy-preserving analytics. Merchants segment customers, personalize recommendations, analyze purchasing patterns without exposing raw purchase histories.

Cloud Provider Positioning

The hyperscalers have made their positions clear.

Microsoft Azure

First to market in 2017. Broadest offering. Contributed the Open Enclave SDK to the Confidential Computing Consortium. Supports Intel SGX, AMD SEV-SNP, and Intel TDX.

Latest developments:

• Azure Intel TDX Confidential VMs (DCesv6, ECesv6 series): GA expected Q1 202617
• Azure Integrated HSM security chip rolled out across all Azure servers (August 2025)
• Confidential GPUs via NCCads_H100_v5 VM series extending TEE to attached GPUs

Azure CTO Mark Russinovich stated publicly: “What we ultimately believe and what we’re pushing for is that confidential computing, at least as a basic capability, will eventually be ubiquitous.”

Google Cloud

Confidential VMs, Confidential GKE, Confidential Dataproc, and Confidential Space. AMD SEV for full VM memory encryption with strict Zero Trust enforcement. Expanded to Confidential Accelerators with NVIDIA H100 GPUs for AI workloads.18

AWS

Proprietary approach with Nitro Enclaves: isolated execution environments within EC2 instances. Unlike Azure and Google, AWS doesn’t build on Intel SGX or AMD SEV. Custom Nitro architecture instead.

The Verification Stack: Blockchain as Trust Anchor

Confidential computing solves execution privacy. But the agentic web requires more: a verification layer that establishes agent identity, enforces policies, creates an auditable record of autonomous actions.

Blockchain infrastructure becomes essential.

Identity and Attestation

Decentralized Identity provides agents with verifiable credentials not controlled by any single authority. Combined with TEE attestation, this creates agents that can prove both who they are and what they’re running.19

Policy Enforcement

Smart contracts encode the rules agents must follow. Asset limits, approved actions, risk parameters: all enforced on-chain where they can’t be silently modified. The agent operates within boundaries that are transparent and immutable.

By 2026, Gartner predicts most enterprises will rely on an AI gateway layer to centralize routing, policy enforcement, cost controls, and observability across LLMs, agents, and tools.6

Audit Trail

Every material action recorded on-chain. Not the sensitive computation itself, but the attestation proofs, the policy checks, the economic outcomes. Accountability without sacrificing confidentiality.

Oasis Network articulates the standard: “If an agent is not open source, backed by a decentralized key management service, audited, with a reproducible build, and running in a TEE periodically attested on-chain, then it shouldn’t be trusted.”20

This is the standard the agentic web requires.

Governance Agents

Sophisticated approaches emerging: governance agents that monitor other AI systems for policy violations. Security agents that detect anomalous agent behavior. The shift in 2026 is from viewing governance as compliance overhead to recognizing it as an enabler.5

The Infrastructure Landscape

The decentralized AI compute stack is fragmenting into specialized layers: privacy-first infrastructure, compute aggregation, verification, and incentive coordination. The trend is toward composable architectures where projects integrate across layers.

Privacy-First Infrastructure

Oasis Network deployed Runtime Offchain Logic (ROFL), extending confidentiality and verifiability to off-chain computations. Intel TDX live on mainnet, TEE-enabled GPU support in development. Partnered with io.net to extend confidential computing across decentralized GPU infrastructure.20

Phala Network provides TEE-based confidential computing for AI inference. 2025 benchmarks: 0.5–5% overhead, 1.34 billion LLM tokens processed in a single day. Partnerships with Hyperbolic, OLLM, and 0G extend its TEE worker nodes across ecosystems.8

Super Protocol combines NVIDIA H100 Confidential Computing with blockchain orchestration. Confidential AI training where models learn from sensitive datasets without data ever leaving its owner.21

iExec has operated confidential computing infrastructure since 2019, now deploying fully confidential AI agent support with Intel TDX integration on its 2026 roadmap.22

Verified Inference and AI Oracles

Ritual Network supports TEEs via a dedicated precompile contract on its upcoming L1, combining hardware enclaves with zero-knowledge proofs for dual-layer computational integrity. Its Infernet oracle already connects on-chain contracts to off-chain AI models on existing chains.23

Hyperbolic AI pairs Proof of Sampling (probabilistic verification of inference correctness) with Phala’s TEE infrastructure for a hybrid verification model: cheaper than full re-execution, stronger than either layer alone.24

Chutes (Bittensor Subnet 64) ships confidential inference via sek8s: Intel TDX confidential VMs with NVIDIA Protected PCIe creating encrypted CPU-to-GPU channels. Cosign-verified container images and strict egress controls. Enterprise-grade TEE on a permissionless subnet.25

Compute Aggregation Networks

Bittensor coordinates 129+ subnets through validator consensus and TAO incentives. No native protocol-level confidentiality, but subnet operators like Chutes and Targon Compute (Subnet 4) are independently layering TEE on top. The architecture enables confidential computing without mandating it.26

Akash Network runs a Kubernetes-based compute marketplace with reverse auction pricing. AEP-65 targets confidential computing via Kata Containers with Intel TDX, AMD SEV-SNP, and NVIDIA NVTrust support. Estimated completion: July 2026.27

io.net aggregates 327,000+ GPUs from data centers and individual contributors. Partnered with Oasis Network to integrate confidential computing, including TEE-enabled GPU attestation via ROFL. Not native yet, but actively building toward it.28

Training Verification

Gensyn takes a different approach: probabilistic proof of learning for ML training verification via its Verde arbitration protocol. Over 1 million models trained on testnet. No native TEE, but verification guarantees complement confidential compute layers in a composable stack.29

The pattern: raw compute is commoditizing. Verification and confidentiality are where defensibility lives. Projects that started as GPU marketplaces are racing to add TEE support. Projects that started privacy-first are scaling compute capacity. The stack is converging.

The Adoption Gap

Despite strong momentum, challenges remain. The IDC study identifies primary barriers:2

Gartner warns: “Integrating TEEs across different chip types, cloud providers, and environments can be complex… specialized skills or third-party platforms may be needed to orchestrate and manage confidential computing as adoption grows.”4

The technology is mature enough for production. Market demand is clear. Regulatory pressure mounting. What’s missing: execution capacity. Teams who understand both cryptographic foundations and operational realities of deploying these systems at scale.

End AI Generated Research

R0GUE’s Position

At R0GUE, our work at the intersection of blockchain infrastructure, protocol engineering, and AI systems positions us to help teams navigate this emerging architecture.

The agentic web will not be built on trust assumptions. We already see this reflected in our own work. It will be built on cryptographic proofs, hardware isolation, and verifiable on-chain records. The teams shipping production systems in this space need protocol-level expertise combined with an understanding of AI infrastructure and constraints.

Looking Ahead

The question is whether the future of AI will operate on infrastructure that provides verifiable guarantees, or whether we’ll accept the same trust assumptions of Web2 that don’t hold under adversarial conditions. In most cases, due to regulatory pressure and confidentiality, organisations will choose the former.

The necessary Web3 + AI hybrid infrastructure stack is materialised:

• TEEs for confidential execution
• Blockchain for persistent verification and accountability
• Attestation for auditability
• Proof of Cloud for hardware security

No single component is sufficient, real commercial implementation requires a multidisciplinary team to execute.

Book an exploratory call with us to find out how we can help delivering your project

https://www.r0gue.io/

Go R0GUE.

References

1. Gartner. “Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5% in 2025.” August 2025. https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025 ↩
2. Confidential Computing Consortium / IDC. “New Study Finds Confidential Computing Emerging as a Strategic Imperative for Secure AI and Data Collaboration.” December 2025. https://confidentialcomputing.io/2025/12/03/new-study-finds-confidential-computing-emerging-as-a-strategic-imperative-for-secure-ai-and-data-collaboration/ ↩ ↩2 ↩3 ↩4
3. Fortune Business Insights. “Confidential Computing Market Size | Forecast Analysis [2032].” https://www.fortunebusinessinsights.com/confidential-computing-market-107794 ↩ ↩2 ↩3
4. Gartner. “Gartner Identifies the Top Strategic Technology Trends for 2026.” October 2025. https://www.gartner.com/en/newsroom/press-releases/2025-10-20-gartner-identifies-the-top-strategic-technology-trends-for-2026 ↩ ↩2 ↩3 ↩4
5. Gartner. “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027.” June 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027 ↩ ↩2 ↩3
6. Lasso Security. “Enterprise AI Security Predictions for 2026: Agents, Intent, Gateways.” https://www.lasso.security/blog/enterprise-ai-security-predictions-2026 ↩ ↩2 ↩3 ↩4
7. Gartner. “Gartner Predicts 40% of AI Data Breaches Will Arise from Cross-Border GenAI Misuse by 2027.” February 2025. https://www.gartner.com/en/newsroom/press-releases/2025-02-17-gartner-predicts-forty-percent-of-ai-data-breaches-will-arise-from-cross-border-genai-misuse-by-2027 ↩ ↩2
8. Phala Network. “Confidential Computing Trends 2025.” https://phala.com/learn/confidential-computing-trends-2025 ↩ ↩2
9. NVIDIA. “AI Security with Confidential Computing.” https://www.nvidia.com/en-us/data-center/solutions/confidential-computing/ ↩ ↩2
10. WireTap Research. “Breaking Server SGX via DRAM Bus Interposition.” https://wiretap.fail/ ↩
11. Integritee Network. “This is the End: Looking Back.” November 2025. https://medium.com/integritee/this-is-the-end-8fb08e9f6d94 ↩
12. Proof of Cloud. “Verifiable Cloud Hardware Registry.” https://www.proofofcloud.org/ ↩
13. Anjuna Security. “Financial Services Turn to Confidential Computing for Key Use Cases.” https://www.anjuna.io/blog/financial-services-confidential-computing-key-use-cases ↩
14. Decentriq. “What is Confidential Computing? Definition + Use Cases.” https://www.decentriq.com/article/what-is-confidential-computing ↩
15. Super Protocol. “Confidential AI for Healthcare.” https://superprotocol.com/resources/confidential-ai-for-healthcare ↩
16. Collab9. “Confidential Computing: Securing Government Data.” https://www.collab9.com/confidential-computing-government/ ↩
17. Microsoft Azure. “Azure Intel TDX Confidential VMs Momentum.” https://techcommunity.microsoft.com/blog/azureconfidentialcomputingblog/azure-intel%C2%AE-tdx-confidential-vms-momentum/4470736 ↩
18. Google Cloud. “How Confidential Accelerators Can Boost AI Workload Security.” https://cloud.google.com/blog/products/identity-security/how-confidential-accelerators-can-boost-ai-workload-security ↩
19. AWS Industries Blog. “Securing the Future: How AI Agents, Web3, and Post-Quantum Cryptography Are Helping Redefine Digital Trust.” https://aws.amazon.com/blogs/industries/securing-the-future-how-ai-agents-web3-and-post-quantum-cryptography-are-helping-redefine-digital-trust/ ↩
20. Oasis Network. “The Future of Crypto x AI: Trustless Agents.” https://oasis.net/blog/trustless-agents ↩ ↩2
21. NVIDIA Developer Blog. “Exploring the Case of Super Protocol with Self-Sovereign AI and NVIDIA Confidential Computing.” https://developer.nvidia.com/blog/exploring-the-case-of-super-protocol-with-self-sovereign-ai-and-nvidia-confidential-computing/ ↩
22. Cointelegraph. “This Platform Simplifies Launching Privacy-First AI Applications for Developers.” https://cointelegraph.com/news/this-platform-simplifies-launching-privacy-first-ai-applications-for-developers ↩
23. Ritual. “Frequently Asked Questions.” https://www.ritualfoundation.org/docs/reference/faq ↩
24. Phala Network. “Hyperbolic and Phala Announce Strategic Partnership to Advance Secure & Verifiable AI Computing.” https://phala.com/posts/hyperbolic-and-phala-announce-strategic-partnership-to-advance-secure-verifiable-ai-computing ↩
25. Chutes. “Confidential Compute for AI Inference: How Chutes Delivers Verifiable Privacy with Trusted Execution Environments.” https://chutes.ai/news/confidential-compute-for-ai-inference-how-chutes-delivers-verifiable-privacy-with-trusted-execution-environments ↩
26. Bittensor. “Subnet Statistics.” https://taostats.io/subnets ↩
27. Akash Network. “AEP-65: Confidential Computing.” https://akash.network/roadmap/aep-65/ ↩
28. Oasis Network. “Oasis x io.net: Accelerating Decentralized AI With Confidential Compute.” https://oasis.net/blog/accelerating-decentralized-ai-with-confidential-compute ↩
29. Gensyn. “Documentation.” https://docs.gensyn.ai/ ↩

2025, the Year of the Snake, marked a period of reflection, transformation, renewal, and reinvention. At R0GUE, we lived this symbolism fully; shedding our skin and transitioning from a focus on core Polkadot product development into a new paradigm of tier-1 Web3 and AI consulting.

It was a year of great change, vision refinement, evolution, and, as always, challenging the status quo.

We consciously expanded from our Polkadot ecosystem DevX roots, and we transitioned from our core product focus to high-impact consulting, focused on visionary partnerships and the delivery of real-world, high-stakes Web3 systems.

At the same time, we made deep strides into Artificial Intelligence, expanding both our technical capabilities and client engagements across blockchain, AI, trusted execution environments, and confidential inference.

As we move forward with deliberate intent, it is equally important to reflect on what has been achieved. Now venturing into 2026, the Year of the Horse, symbolizing speed, momentum, and bold action; we take a moment to reflect on what we shipped, shaped, and brought forth into existence over the past year, while looking forward to some exciting things on the horizon.

R0GUE Reforged: Recalibrated for Impact

2025 was the year R0GUE made its position explicit.

We transitioned fully into a blockchain consultancy, built for teams operating at the edge of what’s possible, where architectural precision matters, trade-offs are material, and success is the only option.

This was a process of refinement and full articulation of our mission, vision, and ideals, covering:

• A complete website redesign and rebrand
• Clear articulation of our services, products, and proof of work
• A sharp outline, visible to everyone, of our blockchain development expertise, infrastructure, and delivery

The result is a R0GUE that looks the way it works: precise, pragmatic, and built to challenge convention through execution. We ship verifiable proof-of-work to deliver high-impact material change.

Strategic Partnerships: Network Drives Impact

R0GUE x Xcavate: Building Decentralized Systems for Human Impact

Our partnership with Xcavate represents a manifestation of our ethos, one focused on real-world impact and long-term societal utility.

In 2025, R0GUE formed a strategic partnership with Xcavate, evolving from mainnet readiness support into a long-term collaboration centered around RealXEducation and decentralized knowledge infrastructure.

This partnership strengthens how education platforms can be built on-chain:

• Low-trust credentialing and verification systems
• Programmable learning outcomes and incentives
• Market-driven knowledge coordination with minimal institutional overhead

We are humbled to have been invited by Xcavate to the “Web3 Education, Innovation & Opportunity” event at the House of Lords in October 2025.

Together, we are building infrastructure that treats education not as static content, but as composable, verifiable, and economically aligned on-chain systems, enabling new knowledge markets that scale globally without relying on heavy centralized institutions. We are humbled by the vision of Xcavate, this is just the beginning.

R0GUE x Braille: Execution Partners

Our rebrand was only the beginning.

In 2025, R0GUE entered into a strategic partnership with Braille, formalizing a collaboration that brings together world-class design and protocol-level engineering.

This partnership strengthens how we deliver end-to-end systems:

• UX that respects both user and protocol needs
• Engineering that doesn’t get convoluted by misaligned abstractions
• Design that understands engineering constraints, not just aesthetics (and vice-versa)

Together, we’ve built an engagement model where design and infrastructure evolve in unison, enabling products and platforms that are aesthetically pleasing, durable, and conducive to user adoption. We are honoured to be a trusted collaborator.

Building on these foundational partnerships, R0GUE has been actively cultivating strong relationships across AI infrastructure, decentralized compute, and the broader Web3 ecosystem.

As new collaborations materialise, we will be excited to formally announce them and clearly articulate the strategic direction they represent.

Polkadot Ecosystem Work

R0GUE’s roots in the Polkadot ecosystem run very deep, and in 2025, our work became even more focused, intentional, and impactful.

We concentrated on the areas where we consistently create the most ecosystem impact: developer experience, tooling, smart contract infrastructure, and ecosystem reliability.

Pop CLI: The shortest distance from idea → build → deploy on Polkadot

In 2025, through a very fruitful and collaborative partnership with the Web3 Foundation, as part of the Decentralised Futures Program, Pop CLI became core developer infrastructure for building on Polkadot, and was added to the official Polkadot documentation as the only quickstart parachain development tool.

The shared understanding behind Pop’s development was to materially enhance Polkadot’s developer experience (DevX) landscape, by giving developers one tool to achieve their objectives. The story of Pop CLI goes all the way back to 2023 with what started as a beta prototype to simplify parachain and smart contract workflows has now evolved into a production-grade, ecosystem-integrated developer tool, tightly aligned with Polkadot’s official tooling.

This was no minor feat; it was an intensively collaborative, milestone driven delivery, of public good infrastructure. We are grateful for having had the opportunity to work so closely with the Web3 Foundation on this initiative.

We are also very thankful for their kind words and support of R0GUE’s delivery capabilities in respect to their collaboration with us.

“Collaborating with the R0GUE team was highly positive — the robust documentation, user-friendly Pop CLI, and excellent support to deploying teams were consistently impressive.”

Through this partnership and a subsequent proposal funded by the Polkadot community, Pop CLI continued to evolve from a scaffolding tool into a developer platform, designed around how teams actually build:

• Faster onboarding with fewer fragmented tools to consider
• Clearer workflows for smart contracts and chains
• Reduced friction between local development and real networks

Pop CLI remains one of R0GUE’s most tangible contributions to the Polkadot ecosystem, a reflection of our core beliefs that powerful infrastructure requires equally powerful tooling.

ink! Alliance: Stewardship Beyond Code

As a member of the ink! Alliance, R0GUE played an instrumental role in supporting the ongoing stewardship of ink! (Polkadot’s native PVM compatible Rust smart contract language), not only through development contributions, but through sustained operational, coordination, and ecosystem support.

Throughout the year, the ink! Alliance brought forward multiple treasury proposals (September, October, and November 2025) aimed at securing long-term funding to take ink! v6 to production readiness. While these proposals ultimately did not pass, the work behind ink! did not stop.

R0GUE stepped up.

Our contribution extended well beyond writing code. We supported the Alliance across:

• Operational coordination and continuity during periods of funding uncertainty
• Ecosystem communication, helping clarify ink!’s status, risks, and dependencies transparently
• Strategic alignment, ensuring ink! remained technically and conceptually aligned with PolkaVM, the Hub, and the broader Polkadot roadmap
• Developer-facing stewardship, including hands-on support, mentorship, and tooling integration

This kind of work is often invisible, but it is essential.

Open-source languages don’t sustain themselves on pull requests alone. They require teams willing to carry responsibility during uncertainty, maintain coherence across contributors, and protect long-term outcomes even when short-term funding doesn’t materialize. Coordination in a decentralised ecosystem is a critical component to ensure strategic alignment.

R0GUE was proud to do exactly that for ink!.

We remain deeply convinced of ink!’s importance as Polkadot’s Rust-native smart contract pathway, and we stand behind the work delivered by the Alliance in 2025. Stewardship is not conditional on easy wins, and this year proved that commitment matters.

We are again humbled and thankful to have been able to provide both development and stewardship support to ink!.

This work reflects our core belief that strong developer experience and empirically driven decision-making are essential to driving real ecosystem adoption, a view reinforced by the fact that Rust is onboarding developers 30% faster than Solidity across Web3.

Paseo: Reliability at the Core

Throughout 2025, R0GUE continued as a core contributor and maintainer of Paseo, Polkadot’s community testnet.

Paseo is critical infrastructure, and that means dedication and consistency matters more than visibility. This is the work that most do not see, but without a carefully managed and reliable testnet, the ability to innovate, ship new features and bring forth adoption becomes unfeasible.

This year, we supported:

• 30 teams actively building and testing on Paseo
• Up to 50 chains running at the same time
• Ongoing onboarding, debugging, and upgrade support
• A stable, predictable environment for ecosystem experimentation

It’s not on the mainstage of narrative and conversations. But without the dedication provided by core maintainers to ensure stability and management of Paseo’s operations, little innovative progress would be possible.

Field Work: On the Ground With Builders

Beyond tooling and infrastructure, 2025 was about showing up, in person, on the ground, and in the midst of the innovative process.

R0GUE helped support the next generation of Polkadot developers by mentoring teams, answering hard technical questions, and helping projects move from concept to implementation.

In July 2025, we attended the Web3 Summit at Funkhaus Berlin, where we mentored builders working with ink! smart contracts. The momentum was clear: Rust-based ink! contracts led both interest and project submissions, outperforming Solidity-based approaches and reinforcing the growing shift toward Polkadot-native development.

In November 2025, we joined Sub0 Buenos Aires, mentoring teams at the Polkadot Builder Party hackathon. Once again, projects built with ink! stood out, with Web3 Foundation–selected winners disproportionately representing Rust-based ink! smart contract implementations based on the number of submissions.

Beyond events, we also got the opportunity to assist in long-term ecosystem education. As part of our ink! Alliance stewardship efforts, R0GUE sent a dedicated tutor to the Polkadot Blockchain Academy in Bali, supporting students directly in Rust and ink! smart contract development and helping build foundational skills for the next wave of Polkadot builders.

Across all of these efforts, our role remained consistent, we are:

• Builders
• Practitioners
• A team that ships and helps others ship

Because ecosystems are not built from slide decks, hype and narrative.

They are built by a strong community of engineers writing code, solving problems, and learning together.

Looking Ahead: 2026 and the Next Phase of R0GUE

If 2025 was the year of transformation, 2026, the Year of the Horse, is the year of acceleration; we are moving to a canter.

We are entering the next phase of R0GUE with a sharper operating model and a clear sense of purpose. Our services will continue to expand, intentionally, strengthening our ability to deliver end-to-end systems while preserving the technical depth that defines our work.

While blockchain and Web3 will remain our primary focus, we will continue advancing our AI partnerships and expanding delivery at the confluence of blockchain, AI, confidential compute, and trusted execution environments. The priority is building production-grade trust-minimised systems that solve real problems.

At the same time, we will deepen collaboration beyond Polkadot. While the ecosystem remains foundational to R0GUE’s DNA, 2026 will see us working more actively across multiple stacks and networks through partnerships and joint initiatives. Interoperability is not optional, it is how serious infrastructure and relationships get built.

Above all, 2026 is about fundamentals. Product design. Usability. Distribution. And shipping partner products to market.

2025 reforged R0GUE.

2026 is where we strike forward with clarity.

Go R0GUE

Building Web3 Infrastructure With Real-World Impact

Xcavate works with R0GUE as a collaborator, not a transactional client. The relationship is hands-on, we work side by side, on equal footing, to help visionary teams achieve their objectives and deliver Web3 systems designed to solve challenging problems.

This partnership reflects R0GUE’s core belief and our guiding principle:

“We challenge the status quo with emergent technologies, creating impactful solutions that transform industries.”

Over the past several months, Xcavate and R0GUE have been collaborating across multiple phases to design, implement, and harden the critical infrastructure underpinning Xcavate’s platform, laying the groundwork for a real-world asset (RWA) ecosystem focused on real estate investment and management.

What follows is a look at what we’ve built together so far, and how this partnership is evolving beyond a standard implementation engagement.

Phase One: Codebase Review & Runtime Uplift

Our collaboration began with a deep, joint review of Xcavate’s existing codebase. R0GUE embedded closely with the Xcavate team to assess architectural decisions, identify risks, and align the runtime with long-term scalability goals.

This phase included a detailed review of:

• Runtime pallets and token standards
• XCM and cross-chain integration patterns
• Upgrade paths and dependency management

In parallel, we supported Xcavate in upgrading their Substrate node, ensuring compatibility with the latest SDK while preserving existing functionality and minimizing disruption.

Milestone 1: Codebase & architecture review
Milestone 2: Node SDK upgrade to v2503

Phase Two: Token Generation Event (TGE) Infrastructure

With a solid technical foundation in place, we moved into the design and implementation of Xcavate’s Token Generation Event (TGE).

The plan: enable Xcavate to mint and vest 100 million XCAV tokens to recipients via a secure and auditable process.

R0GUE worked as a core technical partner throughout this phase, delivering:

• Custom tooling to generate vesting transactions and validate on-chain state
• End-to-end documentation for Xcavate’s multisig-based sudo process
• Support for deploying a runtime with vesting logic on Xcavate testnet
• This phase ensured that token infrastructure was not only functional, but transparent, reproducible, and built for safe distribution

Milestone 3: TGE Infrastructure

Phase Three: Bridging Ethereum to Xcavate via Hyperbridge

Now, we’re deep into one of the most technically complex milestones: enabling cross-chain transfers of stablecoins from Ethereum to Xcavate using Hyperbridge and ISMP (Interoperable State Machine Protocol).

Xcavate and R0GUE are collaborating on core cross-chain infrastructure to enable secure, long-term interoperability and real-world asset flows.

Key contributions include:

• ISMP integration into the Xcavate codebase.
• Designed a migration-safe token gateway and approval flow
• Implemented integration tests simulating token flows between Ethereum and Xcavate
• Built out documentation and architecture diagrams to support maintainability
• Flagged edge-case risks and proposed solutions

Delivery documentation included:

• Bridging existing ERC-20 tokens
• System architecture overview
• Runtime and cross-chain message simulation testing guides

Both teams have now successfully completed the first end-to-end asset transfer on Xcavate testnet, validating the bridge flow, asset minting, and supply correctness.

A transfer of 10 USD.h was executed on Ethereum Sepolia, resulting in the successful minting of the corresponding assets on Xcavate testnet . The receiving Xcavate account reflects the full 10 USD.h balance, and total USD.h supply on Xcavate has been verified for consistency.

Milestone 4: Cross-chain Stablecoin Integration

Looking Ahead: A Long-Term Technical Partnership

As core infrastructure comes online, our collaboration with Xcavate is expanding beyond discrete milestones. R0GUE will be serving as Xcavate’s core technical development partner rather than a one-off implementation provider.

Together, we are aligning on:

• Long-term platform architecture
• Mainnet readiness and operational resilience
• The evolution of Xcavate’s RWA platform to meet real human and institutional needs

Our shared goal is to build infrastructure that serves more than speculative use cases, technology that addresses real economic activity, accessibility, and societal impact.

Collaboration-forward Built For Human Impact

This collaboration exemplifies how R0GUE approaches every engagement. We don’t operate as a dev shop that ships code and walks away. We partner with founders and teams who are serious about building systems that matter.

We believe in Xcavate’s vision: making blockchain practical, accessible, and impactful for everyday people through use cases that serve fundamental human rights and needs. That belief is why we invest deeply, technically, strategically, and collaboratively, in the success of our partners.

At R0GUE, we exist to bring purpose-driven innovation to life, where emergent technologies don’t just challenge the status quo, but genuinely transform industries and improve lives.

Building something real with Web3?

We work with teams who are serious about shipping, scaling, and operating production-grade systems.

Go R0GUE and build the future of Web3 with us.

https://www.r0gue.io/

When it was announced that Kusama and Polkadot would migrate account balances and asset functionality to Asset Hub, Kusama on October 7th and Polkadot on November 4th respectively, every Rollup (Parachain) in the ecosystem had to adapt. This ecosystem-wide transition required Rollups to align their XCM reserve logic and runtime behavior to ensure uninterrupted token transfers. This was a critical upgrade as failure to do so would have potentially resulted in lost user funds.

Interlay engaged R0GUE to support both Interlay (Polkadot) and Kintsugi (Kusama) in preparing for this upgrade. Their runtimes were operating on a legacy Substrate, XCM and ORML stack (v0.9.42 / XCM v3), which required tailored adjustments to remain compatible with the migration’s reserve-based changes.

Together, we collaborated to design and deliver a migration-safe solution that preserved network stability throughout both transitions while delivering on a short timeline before the network upgrade deadlines.

Here’s how we delivered.

Phase One: Technical Review & Compatibility Assessment

R0GUE initiated the engagement by conducting a focused review of Interlay’s and Kintsugi’s runtime configurations, dependency constraints, and XCM implementations. Given the networks’ reliance on a legacy codebase and pinned tooling, our team developed a compatibility approach that preserved existing architecture while enabling the behaviors required by the Asset Hub migration.

To support this, R0GUE delivered:

• A dedicated ORML fork compatible with the networks’ pinned Substrate and Rust toolchain
• A compatibility backport of key migration-related XCM logic into the networks’ XCM v3 environment

These changes established a stable foundation for integrating the final migration logic.

Milestone 1: Runtime and dependency review
Milestone 2: Compatibility-layer implementation

Phase Two: Asset Hub Migration Patch Development

With the foundations stabilized, we moved into building Interlay’s and Kintsugi’s custom migration mechanism utilizing ORML, designed to protect user funds throughout both migrations.

R0GUE delivered:

• A new MigrationStatus storage item and root-only extrinsic for controlling migration phases
• A custom reserve provider to safely route KSM/DOT to the correct reserve pre- and post-migration
• Logic to disable unsafe pallet_xcm reserve transfers after migration while preserving all xtokens operations
• A migration flow precisely aligned with Polkadot’s chain-wide schedule
• Full xcm-simulator testing, guaranteeing the patch’s behavior under real conditions

These changes allowed Interlay to enact a controlled, safe transition without modifying their entire runtime architecture.

Milestone 3: Migration patch implementation & integration
Milestone 4: End-to-end testing and delivery

PR: https://github.com/interlay/interbtc/pull/1253

Phase Three: On-Chain Governance Enactment

Once the patches were delivered, Interlay applied the upgrades on-chain through referenda on both networks.

R0GUE supported the preparation and validation of the runtime, while the Interlay community executed the governance process.

• Kintsugi (Kusama) — Referendum 168 https://kintsugi.subsquare.io/democracy/referenda/168
  Enacted ahead of the early October Kusama migration.
• Interlay (Polkadot) — Referendum 133 https://interlay.subsquare.io/democracy/referenda/133
  Enacted ahead of the November 4 Polkadot migration.

Both enacted successfully, ensuring that users experienced no disruption, no incorrect balances, and no broken cross-chain transfers throughout the migration windows.

Looking Ahead

Interlay and Kintsugi completed the Asset Hub migrations without downtime, loss of funds, or service degradation. With the patch in place, both networks now have a stable foundation to pursue future upgrades.

Critical Support and Beyond

This collaboration wasn’t just a quick fix. It reflects R0GUE’s commitment to providing critical infrastructure support when Polkadot ecosystem teams need it most.

Interlay didn’t just need engineers, they needed a partner they could trust to meet their tight timelines and quickly understand their systems, XCM, ORML, migration logic, and cross-chain safety guarantees.

At R0GUE, we focus on helping teams navigate complex upgrades with clarity, reliability, and confidence. Whether it’s critical support, runtime and smart contract development, next-generation interoperability, and the integrations of blockchain systems across industries, we work alongside those who are strengthening and evolving the foundations of Web3 and utilizing it to its full potential.

Designing infrastructure that must operate reliably across chains, ecosystems, or enterprise environments?

We collaborate with leaders and teams who need technical firepower, battle-tested Rust and blockchain expertise, and the ability to deliver when timelines are non-negotiable.

Building something real with Web3?

Go R0GUE and build the future of Web3 with us!
https://www.r0gue.io/

The results show where ink! shines, where it still needs refinement, and most importantly how it’s evolving to deliver a world-class Rust smart contract language with supreme developer experience and high performance, within the Polkadot ecosystem.

TL;DR Benchmark Results

Code Size: ink! has 3× fewer lines of code
Binary Size: ink! is 11% smaller
Instructions: ink! has12% fewer RISC-V instructions
Deployment Cost: ink! is 11% cheaper
Gas Usage: ~Draw Only ~1% difference, bare bones rust is cheaper
Build Time: Bare Rust is 7× faster to build
Dependencies: Bare Rust has 20× fewer crates
Boilerplate: 45% of Bare Rust was boilerplate, this is auto-generated by ink! Type Safety: ink!’s compile-time safety vs Bare Rust runtime panics
Testing Support: ink! has a built-in #[ink::test] and e2e framework Control/Flexibility: Bare Rust has full low-level access

Full report: BENCHMARK_REPORT.md

What This Means

ink! makes building smart contracts simpler, safer, and faster (except compile time) without sacrificing performance.

The ink! implementation was 3x smaller in code, had fewer instructions, and still deployed more cheaply, all while providing auto-generated dispatch, ABI encoding, storage keys, and metadata that Bare Rust requires you to do yourself.

Over 40% of the Bare Rust implementation was just dispatch logic and storage boilerplate. With ink!, that’s gone.

This is a huge win for onboarding, productivity, and long-term maintainability.

Developer Experience: Built for Productivity

Using ink! instead of plain Rust dramatically reduces friction and the potential for errors.

ink! provides built‑in support for:

• ABIs (both native SCALE and Solidity)
• Typed storage and contract‑optimized data structures
• Dispatch code generation and cross‑contract calls
• Event handling and metadata generation
• A full tooling ecosystem for compilation, testing, and front‑end integration

On top of this, the ink! e2e testing framework makes it easy to write end‑to‑end tests in pure Rust (including interaction with the runtime), and Pop CLI provides a seamless workflow for building, testing, deploying, and interacting with contracts.

In contrast, a low‑level Rust contract on pallet‑revive leaves all of that to you; storage layout, ABI handling, metadata, serialization, and even tooling integration must be implemented manually.

For most developers and most use‑cases, this makes ink! far more productive, safer, and maintainable than “rolling your own” with raw Rust and FFI. The result is faster iteration, fewer bugs, and a significantly better developer experience.

What’s Next for ink!

Our focus this past year has been on PolkaVM support and developer experience, and that work is still ongoing. But as ink! stabilizes, we’re also starting to explore language-level optimizations (e.g. reducing compile times).

The goal is clear: make ink! not just easier to use, but faster, smaller, and more powerful!

At R0GUE, identity matters. The way we show up should match the way we build: sharp, deliberate, and uncompromising.

Over the past months, we partnered with Braille, a design studio founded by ex-Parity builders and deeply embedded in the Polkadot ecosystem, to reimagine how R0GUE presents itself. This wasn’t about cosmetics. It was about creating an identity that reflects who we are, what we’ve done, and where we’re going.

Why Now?

For years, at Parity and now at R0GUE, we’ve operated quietly in the background, launching chains for clients, supporting ecosystem teams, advancing ink!, maintaining Paseo, and developing Pop CLI. The networks and tools others rely on every day were shaped in that work.

That work proved what we’re capable of, but we kept a low profile and focused on building.

Today, the landscape is shifting. The Polkadot SDK is maturing. Teams are moving from experiments to production. Enterprises are starting to explore what’s possible.

This is the moment to step forward.

The rebrand marks R0GUE’s next chapter: bringing our skills, experience, and track record to the market, enabling builder teams and enterprises to build with confidence on the Polkadot SDK, from core protocol to full-stack delivery.

Step One: The Brand

The first step was sharpening the identity itself. With Braille, we refined everything:

• Brand guidelines creation.
• Honing down the identity.
• Voice and tone definition.
• Logo redesign.
• Imagery selection to define and support the brand identity.
• Colour palette design, iteration, and selection.

The result is a brand that feels distinctly R0GUE: bold, minimal, precise. Nothing extra.

Why Braille?

We chose Braille because they aren’t outsiders. They’re another Polkadot ecosystem team, led by ex-Parity founders who know the tech and the culture inside out. That shared DNA made the collaboration seamless. They understood not just the design, but the mission.

The Outcome

The collaboration with Braille gave us more than a new identity:

• A sharper brand that reflects who we are.
• A redesigned website that tells our story with clarity and impact.
• A voice that matches the work we deliver.
• A marketing approach rooted in proof, not fluff.

The rebrand marks the next chapter of R0GUE. The work ahead is about showing, once again, what we can build.

Step Two: The Website

With the brand identity defined, the next step was expressing it in how we communicate. The website is often where teams first encounter R0GUE, it needed to reflect who we are and the calibre of work we deliver.

The redesign process was closely tied to the new identity. Together with Braille, we moved through a structured sequence:

1. Concept & Direction: establishing tone, visual references, and interaction style.
2. Low-Fidelity Layouts: defining hierarchy, flow, and narrative.
3. High-Fidelity Design: bringing precision to typography, spacing, imagery, and motion.
4. Build & Implementation: delivered in Vercel, where we worked closely with Braille to refine details and ensure the design translated cleanly into the final experience.

The final website is not just a new front-end, it is a materialisation of everything we are, stand for, and believe in.

The website makes that explicit:

• Who we are: a team that has shipped real systems, our mission and our values.
• What we do: protocol architecture, smart contracts, runtime development, tooling, and full-stack delivery.
• How we work: strategically, collaboratively, and with precision.

This was not a marketing exercise.
It was a refinement and reaffirmation of identity, positioning, and invitation.

R0GUE remains a team of experienced protocol and product engineers highly focused on DevX and user experience, now collaborating more broadly with organizations to architect and deliver high-performance Web3 systems.

Building something real with Web3?

We collaborate with teams who want to launch, scale, and make a difference.

Go R0GUE and build the future of Web3 with us!
https://www.r0gue.io/

Currently, the assumptions have been that Solidity dominates in the smart contract field bringing guaranteed adoption pathways to the Hub. If Solidity dominates we would expect the data to show:

• Solidity has significantly more full-time developers over alternative smart contract choices.
• Solidity / EVM ecosystems bring in more new developers than non-Solidity ecosystems.
• Solidity developers like to explore (adopt) other EVM-compatible ecosystems.

Utilizing the most comprehensive data-set available for Web3 developers, https://developerreport.com by Electric Capital, we can confirm if these statements are true, and if Solidity’s “dominance” exists.

Smart Contract Choices

Before exploring the data, it’s important to clarify the main smart contract choices in Web3. There are two mainstream choices available:

• Solidity on EVM
• Rust on various VMs (usually WASM)

There are other choices, but the data is limited and shows that these are the only options worth discussing.

There is also Move that is used by Sui and Aptos. However, this has a relatively small developer base still, and is ultimately built-on Rust, powered by Rust, and inspired by Rust.

Parity was one of the first companies to recognize the importance of a Rust smart contract, creating the oldest Rust smart contract language in Web3, ink!, right next to Solana.

Full Time Developers

The first expectation for Solidity to dominate is that there should be significantly more Solidity developers than Rust developers (in Web3).

Of the top ecosystems sorted by full-time developer count, we see that a large portion of those ecosystems use Rust smart contracts directly.

Rust-based smart contracts make up 45.5% of these ecosystems, while 40.9% are EVM based.

If we count the ecosystems powered-by Rust (e.g., Aurora & Sui), we find that 52.4% are built on Rust, while 47.6% are non-Rust (this includes EVM chains, Cardano, and Bitcoin).

In current market conditions, the EVM stack has ~4,686 full-time developers, while Rust-ecosystems have ~3,963 full-time developers.

So, of the top-20 ecosystems, more of those ecosystems use Rust smart contracts than EVM and the most popular (by devs) are powered by Rust. Additionally, total EVM developers and total Rust-developers are similar.

New Developers

Once again, Polkadot Hub needs to attract as many new developers as possible to start building dApps and products. For Solidity we would expect the data to show that EVM-based chains bring in significant amounts of new developers, showcasing the “guaranteed adoption pathways” for the Hub.

Something interesting happened in 2024:

Ethereum and its L2s had reigned for 8-years in new developer adoption counts. But in 2024, that changed. Solana, using Rust-contracts, surpassed Ethereum and its L2s by over 1,000 new developers. We see Ethereum (and its L2s) had a steep decline. Aptos, powered by Rust, was also able to bring in more new developers than Ethereum.

If we go deeper and look at the specific numbers, we see Solana surpassed Ethereum and its L2s by over 1,000 new developers. By following the chart, we see that the ecosystems bringing in the most new developers are mostly Rust ecosystems. Sui and Aptos use Move, but that is built on Rust and inspired by Rust. Arbitrum is EVM, but they also support a Rust smart contract language (Stylus).

By adding up the total amount of new developers that Ethereum and its L2s brought in, we get about 10,000. While Rust ecosystems (EXCLUDING Sui and Aptos) brought in close to 14,000 new developers. So, Rust-ecosystems saw 30% more new developers than the EVM / Solidity ecosystems.

Multi-Chain Developers (do developers deploy elsewhere)

The assumption is that because Solidity has existing developers, then Polkadot Hub will be able to access that existing developer pool. However, for this to happen we need to know if Solidity developers have a tendency to deploy on other chains.

This table says: “of the developers that deployed on [for example] Avalanche, this percentage also deployed on Eth Mainnet, Optimism, etc.”

What it shows is that most Ethereum L2 developers deploy only on Ethereum Mainnet and their original L2.

Ethereum Mainnet developers have the lowest exploration, and mostly deploy only on Ethereum Mainnet.

Ethereum Mainnet is where most of the Solidity developers are. According to Electric Capital, Base is the second most popular, but also say that most “Base deployers tend to stay on Base” (src).

The data also shows that “74% of Multi-chain developers work on EVM”. (src) Showcasing that EVM does have strong network effects, relatively speaking. However, we see that a small percentage of “multi-chain developers” deploy anywhere beyond Ethereum Mainnet and their original L2. Additionally, Base and Ethereum Mainnet have the most Solidity developers, but they also are the ecosystems that tend to deploy only in their ecosystem.

To wrap-up this point, a majority of Solidity developers only deploy on Ethereum Mainnet, and their original L2.

Why Do We Care?

Polkadot Hub is supposed to launch in December, and getting new developers to build products is of utmost importance. Currently, Polkadot’s native Rust-smart contract language and only PVM-compatible language (ink!) is fighting for continued development. Not for the sake of ink!, but for the sake of being able to bring in as many developers as possible to build products and more usage of DOT.

The assumption was that because “Solidity clearly dominated” we don’t need Rust smart contracts (ink!). But, as we’ve seen those assumptions were not correct. Rust-based ecosystems have comparable amounts of developers, and brought in significantly more new developers than EVM-ecosystems. Additionally, the majority of Solidity developers don’t like to explore other ecosystems, meaning Polkadot Hub’s chances of bringing in existing Solidity developers is low.

Arguments Against ink!

There are some recurring arguments against ink!, including that it doesn’t have enough adoption, it’s not worth the price, and that ink! causes fragmentation in our ecosystem.

First, yes, ink! does not have tremendous amounts of adoption. But that’s directly correlated to Polkadot’s struggles and the lack of a Polkadot Hub. ink! is Polkadot’s native smart contract language, but there has never been a Polkadot-native solution to deploy ink!. Additionally, ink! is Rust that is expanded to work on Polkadot. Which, as we’ve seen, Rust is better at bringing in new developers than Solidity is. In other words, Rust’s brings better adoption pathways to the Polkadot Hub.

Leading to the next point, if Polkadot Hub needs more new developers to create products, and Rust is better at bringing in new developers, then why is ink! not worth it? ink! gives Polkadot Hub access to a much larger pool of developers (5.1 million) and enterprises than Solidity does. Additionally, ink! is the only language currently capable of supporting PVM at Hub’s launch — a selling proposition for someone to build on the Hub, but also a way to start battle-testing PVM in production.

We’ve also heard that ink! causes fragmentation. But, multiple deployment pathways doesn’t mean fragmentation. Ultimately, Solidity and ink! converge on one point: “deploy smart contracts to Polkadot Hub”. By supporting both Solidity and ink!, we expand the top of our funnel leading to one point — products on the Hub. Additionally, thanks to the awesome work by the ink! Alliance, ink! has Solidity-ABI compatibility allowing Solidity and ink! to interoperate, and even allows ink! to use tools like Metamask. Lastly, ink! helps reduce overall ecosystem fragmentation by natively supporting XCM — the only language to do it in a practical way.

So, does ink! guarantee that it will bring in new developers to Polkadot Hub? Definitely not. There has to be more fundamental selling points in Polkadot itself. However, by having Rust we can significantly reduce friction for bringing in new developers. This is because it’s easier for developers and enterprises to explore Web3 if they can do it in a technology they already know. Solidity is also very niche and only useful to Web3, while Rust is useful to every technical industry. So, a developer would be more willing to learn Rust (the worlds most admired language) to explore Web3 as it is useful everywhere — while Solidity is only useful in Web3.

Polkadot has always been Rust-first, it’s the reason so many of us developers are here.

Conclusion

Does ink! guarantee Polkadot Hub’s success? No. But Solidity doesn’t either. The data shows that Rust is comparable in Web3 developer count, and is much better at bringing in new developers to Web3 — a crucial piece to the Hub’s success. Only having the ability to build in Solidity or ink! isn’t enough to bring in developers. However, having the ability to build in Rust means less-friction for the 5.1 million Rust developers, and the large amounts of industries and enterprises that already use and trust Rust. Solidity brings in foundational Web3 infrastructure, but ink! helps bring in more new developers to access that infrastructure — they both are important.

Data doesn’t lie. Rust smart contracts on the Hub will do a better job at bringing in new developers. As Electric Capital says “Developers are a leading indicator of value creation.” So shouldn’t we do everything we can to bring in new developers to build on Polkadot Hub?

Go R0GUE

Appendix

• All data can be found at: developerreport.com
• ink! treasury proposal: https://polkadot.subsquare.io/referenda/1773
• The Polkadot Forum Post found here: https://forum.polkadot.network/t/rust-solidity-data-doesn-t-lie/15683

On Wednesday, 15th October, the UK House of Lords opened its doors to a landmark event “Web3 Education, Innovation & Opportunity”, bringing together esteemed guests, lawmakers, academics, and industry pioneers to explore how blockchain in addition to its use with AI can shape the next era of digital trust and innovation.

“Much of the Agentic Web’s infrastructure is still to be built — and that’s where blockchain’s greatest opportunity lies.”

— Ingo Rübe

Co-organized by the Polkadot Blockchain Academy and supported by the Polkadot Event Bounty team, the event marked the first high-level policy dialogue on Web3 education and innovation ever held in the UK Parliament.

Following the day’s roundtable discussions, R0GUE was delighted to be invited by Richard Houldsworth, CEO of Xcavate, to an evening Gala Dinner, drinks, talks, and networking, set against the backdrop of one of the most historic venues in British politics. With, among others, highly inspiring talks from Baroness Uddin, Lord Ranger, Gavin Wood, and Marta Carslake.

The conversations that began in the afternoon carried naturally into the evening, as speakers expanded on the central theme of the day: how blockchain can and should be part of the national UK agenda across education, innovation, and governance.

We were truly honoured to have been invited to such a significant occasion and to take part in an evening that brought together so many visionary minds shaping the future of technology and policy. Our sincere thanks go to Baroness Manzila Uddin, Lord Kulveer Ranger, Richard Houldsworth and Lucy Coulden for their exceptional work in coordinating this event and for their dedication to fostering meaningful dialogue between innovators, educators, and policymakers. It was a privilege to witness Polkadot’s growing role in these national conversations, and an inspiring reminder of how collaboration and education can drive real change.

The Messaging feature, built by R0GUE, is designed to change that. Its vision is to make interoperability a first-class primitive for contracts. Developers get APIs that bring XCM and Polytope’s ISMP into the contract layer, complete with response handling and automatic callbacks. This means a contract doesn’t just fire off a cross-chain request, it can also receive and react to the result as soon as it arrives, as naturally as calling a local function.

Messaging is a building block of the Polkadot Cloud vision: Polkadot evolves into a Web3 cloud where execution, storage, and data availability become services that can be combined like APIs. In this model, Messaging is the connective tissue: the developer-facing way to orchestrate workflows across rollups and tap into the Cloud as if it were one coherent system.

XCM and ISMP

In Polkadot, XCM (Cross-Consensus Messaging) and ISMP (Interoperable State Machine Protocol) both enable cross-chain communication but differ in philosophy and mechanics.

XCM is a language and instruction set for rollups to send programs to each other, with the Relay Chain guaranteeing delivery. It excels at executing actions on remote chains, with only needing an HRMP channel open between the chains.

ISMP is a transport protocol based on state proofs. It excels at querying state from other chains because only the origin chain needs ISMP implemented. When an ISMP GET request is made, an event is omitted and a relayer retrieves the requested value from the destination chain along with a state proof, and submits it back. The origin chain then verifies the proof against the destination’s finalised state before accepting the data.

In summary, XCM provides a secure pathway for cross-chain execution, while ISMP enables verifiable cross-chain queries. Used together, they give developers the full toolkit for both action and data across the Polkadot ecosystem.

How Messaging Works

Today, Messaging exposes ISMP GET (state queries) and XCM execution. The interface lets contracts send a request, track it, and handle the response. Either by polling or via automatic callbacks, with deposits and gas/weight accounted for. Messaging is protocol‑agnostic by design. New features of the existing protocols (e.g. ISMP POST), or new cross chain protocols can easily be added and benefit from the same response‑handling flow.

Querying State Cross Chain

For a contract to query state it has to provide the destination rollup ID, storage keys to query, and optional callback parameters. The system holds the required deposit (D1) that covers the cost of storing your ISMP message data on-chain until the message is processed (or timed out) and cleaned up. In addition, if a callback is requested, funds are held (D2) to cover the gas costs of executing the callback function when the ISMP response arrives (the max. gas is specified by the contract). Then the request is dispatched through ISMP’s offchain infrastructure.

// Create ISMP GET request
let request = Get::new(
    POLKADOT_HUB,                 // Destination chain
    height,                       // Block height
    timeout,                      // Timeout
    b"context".to_vec().into(),   // Context
    vec![storage_key].into()      // Storage keys
);

// With Callback
let callback = Callback::new(
    contract_address, Encoding::SolidityAbi, 0x9bf78ffb, gas_limit, storage_deposit_limit
);

// Submit a GET request
let message_id = ismp::get(request, fee, Some(callback))?;

The response arrives when the relayer submits a transaction to the ISMP pallet with the retrieved data. The relayer pays the fees for response handling and the call to the contract (not the gas consumed by the contract). If requested, the system checks for enough blockspace, executes the callback and registers the gas consumed to ensure proper block weight accounting. Its respective funds are released (D2) and the actual gas consumed is withdrawn from the contract’s account. The callback function receives the storage values, the state is cleaned up and the remaining funds are released (D1). Without callback, the response is stored. By manual polling the message status can be checked, the response data can be retrieved, and ultimately state is cleaned up and the deposit is released (D1).

Executing Cross Chain

In order for a contract to get the result back from executing an XCM program cross chain, it has to create an XCM query to register a response handler. The system will hold the required deposit from the contract’s account (D1) to cover the storage costs of maintaining the query message until it’s processed (or timed out) and cleaned up. If a callback is requested, additional funds will be held (D2) from the contract (like querying state with ISMP). With current XCM (2506) responses are dispatched without fee charging or weight tracking, requiring the Messaging pallet to manually handle fees and weight accounting. Therefore, on creating an XCM query the contract pays for the XCM response handling and calling a contract, in advance. After the XCM query is made the contract constructs the message with the response reporting instructions (example). Then the system dispatches the XCM message to the destination chain.

// Register query for response (with callback)
let (message_id, query_id) = xcm::new_query(HUB, timeout, Some(callback))?;

// Create the response
let response = QueryResponseInfo {
   // Route back to this parachain.
   destination: Location::new(1, Parachain(api::id())),
   query_id,
   max_weight: Weight::from_parts(1_000_000, 5_000),
  };
   
// Build XCM with response reporting
let message = Xcm::builder_unsafe()
    .withdraw_asset(fees.clone())
    .buy_execution(fees, WeightLimit::Unlimited)
    .transact(OriginKind::SovereignAccount, weight, call)
    .report_transact_status(response_info)  // ← Reports result back!
    .build();

xcm::send(dest, message)?;

When the XCM Message executes on the destination chain, it reports the result back through the registered query. When the response arrives, the system checks for sufficient blockspace to then process the response and manually register the weight consumed by the response handling and contract call (for ISMP the relayer pays for this, here it is paid for in advance). As follows, the system either executes the callback or stores the response for manual retrieval. This is handled the same as for ISMP: when a callback is executed both deposits (D1 and D2) are released, with the actual callback gas withdrawn from the contract’s account; if no callback is used, the response is stored until manually retrieved and the deposit (D1) is then released.

Timeouts, Polling and Removing

Timeouts ensure system reliability by preventing resource exhaustion from abandoned cross-chain requests while providing users with a clear mechanism to reclaim their funds. ISMP timeouts are handled by the ISMP protocol itself, when the specified timeout duration expires ISMP triggers Messaging’s timeout processing. XCM timeouts are block-based and are processed during block initialisation. Timeout processing works similar, the message state is changed to Timeout and deposits are maintained for potential refund. The contract can then remove messages to clean up timed-out (or finished) messages and recover their deposits.

// Check message status
match api::poll_status(message_id) {
    MessageStatus::Pending => {
        // Still waiting for response
    },
    MessageStatus::Complete => {
        // Response received, get data
        let response = api::get_response(message_id)?;
    },
    MessageStatus::Timeout => {
        // Request timed out
    },
    MessageStatus::NotFound => {
        // Message doesn't exist
    }
}

// Remove from runtime storage (releases deposits)
api::remove(message_id)?;

The Road Ahead

Messaging lays the low-level foundations for cross-chain smart contracts, giving developers the building blocks to compose logic and state across the Polkadot ecosystem. By providing simple, versioned, developer-friendly APIs that abstract over XCM and ISMP, it aims to make building cross-chain contracts feel as natural as writing a local one.

But there are still challenges that must be overcome:

• Latency & Suitability: Cross-chain calls take time. Not every dApp can tolerate that. Part of the journey will be discovering which use cases thrive with asynchronous cross-chain logic (e.g., DeFi automation, governance, asset orchestration) and which do not.
• Tooling & Testing: Developers need confidence to build cross chain contracts. Pop CLI already offers multichain network bootstrapping with one command, but on top of that a new testing framework is needed. Blending the best of DRink! and the XCM emulator, so contracts can assert against local state, remote chain state, and cross-chain interactions in one unified test.
• Complexity of Abstractions: Stable higher-level abstractions for cross-chain interactions need to be carefully designed and assessed before they can be relied upon. Until then, developers are required to construct their own messages (e.g., ISMP storage keys or XCM programs), which can be difficult. To ease this, the creation of a shared hub of cross-chain contracts should be created, a growing collection of proven cross chain contract that the community can contribute to and use.
  Some example use cases have already been started here!
• Ecosystem Stability: While Messaging can guarantee stable APIs, external chains may introduce breaking changes. Building strategies to insulate developers from upstream changes, ecosystem wide, will be critical for long-term resilience.
• Relayer Economics: ISMP introduces questions around relayer incentivisation. Sustainable models will need to be explored and tested in practice to ensure good developer experience.

The immediate focus should be on creating a thriving testnet playground. By giving developers all the resources and tooling to experiment fearlessly, it can be discovered what works, refine the developer experience, and seed the first generation of cross-chain contracts. From there, a shared library of primitives will emerge, making interoperability a natural part of building on Polkadot.

The long-term vision is bold: turn Polkadot into the place where cross-chain dApps are not just possible, but effortless. This is where Polkadot can shine compared to ecosystems like Ethereum rollups or Solana, which still struggle with interoperability. If successful, the Messaging feature could be a turning point, the moment Polkadot demonstrates its true power and composability to the wider Web3 world.

This is only the beginning. But the path forward is clear: provide a testnet and tooling, experiment, gather feedback, and improve. The future of cross-chain smart contracts is unwritten, and R0GUE is here to help write it.

Messaging: the Future of Cross-Chain Smart Contracts on Polkadot was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.