White-paper of POCA, by NUTS Research

Abstract

POCA (Protocol Oriented Chain Abstraction) introduces a pioneering approach to enhancing blockchain interoperability and scalability. By unifying asset management and protocol interactions under a cohesive abstraction layer, POCA empowers developers and users to seamlessly interact with multiple blockchain ecosystems. This white paper outlines the technical architecture, security frameworks, and decentralized governance mechanisms underpinning POCA. Our solution streamlines user experiences while fostering robust security and performance.

Introduction

Background

We are living in a world where the success of interoperability and modular architectures has led to the emergence of a myriad of connected chains. Each day brings new chains and ecosystems, all seem interconnected — but yet requiring manual intervention to transfer assets across them.

For instance, if a user wants to move a popular asset like native USDC from one chain to another — they must (1) burn it using CCTP protocol on, say, Solana, (2) get the Circle attestation from off-chain API, (3) switch to Ethereum and then (4) manually pick it up to mint USDC.

While not possible for USDC just 2 years ago, this is still very far from user expectations.

Motivation

Users want to be able to use assets and services independent of the underlying infrastructure. They don't want these discrete separate experiences. They don't want to think about intricacies of each of these chains. Instead, they desire seamless interactions that abstract away the complexities of cross-chain operations.

Imagine booking a travel through a website. From the end user’s perspective, they search for a destination like Bangkok and receive a ton of options. Some may care about Boeing vs Airbus, others about economy vs first-class, or avoiding specific layovers. However, once they decide on options they want, they push a button and get a ticket. The highly sophisticated orchestration required to coordinate between multiple airlines and airports in different countries, service and payment providers, possibly in completely different jurisdictions, is hidden from end users, providing a simple, intuitive and streamlined experience.

Similarly, in Web3 space, we need to deliver the kind of experience that users are used to in Web2 by orchestrating activities across multiple chains. This will allow end users to engage with dApps without worrying or even knowing about technical details of each blockchain.

Problem statement

The current state of Chain Abstraction requires users to deal with complicated processes that are not user-friendly. Developers face technical and even mindset challenges when building dApps that need to interact with multiple chains, leading to high development overhead, suboptimal UX choices and increased security risks.

We have so many bridge types — but yet the user experience is far from seamless. Each chain represents a separate domain with its own native gas tokens, protocols and interfaces, requiring specialized knowledge to navigate. Each interoperability solution requires integrators to adopt to different practices that are significantly affecting possible options and thus end products. This fragmentation hinders the adoption of decentralized technologies and prevents users from fully leveraging benefits of connected crypto ecosystems.

There is a pressing need for an application-level development framework that abstracts these complexities, providing a unified programmable layer for building seamless (chain-invisible) user experiences.

Vision

The escalating competition among crypto ecosystems will eventually lead to simple, streamlined products with Web2-like user experiences tailored for the mass market. We foresee products that will not require users to understand all of the related fundamental questions on how chains or ecosystems work, which wallets to use, which assets to pay fees in, where to acquire it, etc.

To achieve this major shift, we must empower developers with frameworks that operate at higher levels of abstraction than current solutions. This includes providing the technical capabilities to implement agreements between dApps and their users through application-level transactions. Such application-level scenarios may be composed of multiple chain-level transactions (in this context — sub-transactions) and are targeted on multiple, often incompatible, chains.

Taken together, these factors create a market space for an entirely new generation of protocols that connect blockchains at higher levels of logical abstraction than any existing cross-chain communication solutions.

We believe POCA is one of the first such protocols, offering a programmable abstraction layer for building next-generation chain-invisible dApps that enable market players to work not only within different chains and ecosystems, but also between them, creating many promising use cases.

Conceptual overview

Beyond market demands, there are several fundamental reasons why we believe that control and business logic should be extracted into a programmable abstraction layer that sits on top of any existing interoperability solution and conceptually is decoupled from chain-level transactions where AMBs operate:

Fundamentals

Blockchains, and more broadly crypto ecosystems, are demonstrating same patterns in scaling and growth challenges as that of Internet, WAN and LAN networks in 1980s. Although, the so-called Cambrian explosion of different blockchain types may seen as a new phenomenon — but in fact it’s just a natural development cycle of emerging technologies.

One of core debates around Internet architecture in 1980s was focused on where to implement functions ensuring message delivery (e.g. duplicate message detection, message sequencing, payload encryption, message retry, etc.) — whether this logic should be implemented at the core infrastructure level or at applications level.

This has led to the formulation of end-to-end argument which tells that low-level implementation of these functions can be redundant and inefficient, since applications must handle them anyway. E.g. the application is better equipped to detect duplicates since it has the most complete knowledge about its own messages.

Speaking more generally, the contextual information should be placed at the communicating endpoints that have an agreement — and not on infrastructure, since communication context can span across multiple networks, all with its own infrastructure resources.

We consider this as a fundamental design principle for POCA, especially given the profound impact it has had on the Internet as we know it. For example, the entire VPN industry was made possible by this end-to-end principle, as well as TLS for securing HTTP web traffic on browsers.

Need for development paradigm shift

All modern blockchains were originally designed to support powerful yet straightforward ideas (e.g. cryptocurrencies, tokenization of assets) with primary actions like value transfers being predominant among all types of transactions. This design naturally focuses developers attention on chain-level transactions — atomic actions that, as we’ve seen, are too small, cannot hold cross-chain logic and contextually meaningless multi-chain scenarios.

Compare this to our travel booking example — here atomic actions include the system placing a hold on user’s credit card during the booking process, verifying window seat availability, etc. However, from users perspective, booking a flight is a single, seamless operation. Users are not concerned with complexity of underlying processes, they simply confirm the booking.

Among other reasons are security considerations — as many AMBs have been exploited in the past, they naturally tend to de-risk themselves — e.g. Circle has decided to delegate minting USDC to integrators by providing just off-chain attestations. Also, technical properties of modern blockchains, e.g. max block size, gas limit per block, etc. impose real constraints on possibility of executing multi-step scenarios similar to Web2-like travel booking UX but in crypto.

POCA — Protocol Oriented Chain Abstraction

• Programmable abstraction layer — execute multi-chain scenarios of any complexity
• Stacked-based virtual machine — execution model for dynamic decision making
• Defragmenting interoperability labyrinth — abstracting AMB to focus on business logic
• Seamless unbounded DX — execute arbitrary commands on arbitrary protocols
• Composite actions bundling — enabling pre/post-effects via hooks
• Conditional execution — workflow precise control and graceful error handling
• Single-click UX — on chains users love, without leaving their favorite ecosystems
• Accelerated innovation — allowing dev teams to concentrate on their business products
• Greater business autonomy — no limitations imposed by any specific AMB or even chain

State of standardization

First interoperability solutions like cross-chain bridges were built to facilitate simple token transfers operations. Modern solutions are supporting more diverse interactions, including data passing and target contract calls.

However, the situation closely mirrors the early days of email systems in the 1980s. Back then, different email providers (ARPANET, CSNET, BITNET) operated in isolation, each with their own message formats and protocols. Users needed different email clients, and sending messages across networks was technically complex or even impossible to build for developers. The introduction of SMTP (Simple Mail Transfer Protocol) in 1982 completely transformed this landscape and led to explosive growth in email adoption, as we know it now.

Similarly, the cross-chain messaging space today lacks any standardization, with various solutions implementing different approaches to developer interfaces and practices, message passing, verification, and execution. This fragmentation creates unnecessary complexity for developers and end users, holding back the emergence of new cross-chain applications.

Classification of AMBs

In this section we provide several important classifications of AMBs, in attempt to systematize the current landscape. We identify four main dimensions that characterize different AMB types:

Execution determination

How and when the execution details of cross-chain messages are defined.

• Deterministic AMBs — execution details are pre-defined before sending a message. Solutions like LayerZero, Wormhole, and Axelar follow predetermined execution paths, where the exact sequence of operations is known at message dispatch time.
• Intent-based AMBs — execution details are determined after message dispatch through competitive solving. Systems like Socket and CoW allow messages to be executed through paths discovered and optimized by solvers at runtime, enabling more flexible and potentially more efficient execution.

This distinction mirrors fundamental computer science concept — deterministic AMBs are analogous to build-time constants, e.g. constant variables fixed during compilation in Solidity, and more dynamic runtime variables for intent-based AMBs.

Message Processing Models

Categorized by how AMBs handle cross-chain messages:

• Comprehensive processing — solutions like LayerZero and Wormhole process every cross-chain message without discrimination, ensuring complete coverage of arbitrary message passing between chains. While this approach provides maximum flexibility, it comes with higher resource usage and operational costs.
• Priority-based processing — this model is currently implemented only in intent-based AMBs where relayers selectively process intents (expressed as simple text strings) based on economic incentives and other factors (e.g. Socket Protocol). This market-driven prioritization naturally optimizes network resources by processing messages according to their value and urgency.
• Hybrid systems — Axelar combines different processing approaches by utilizing specialized paths for different message types. For instance, their General Message Passing (GMP) handles arbitrary cross-chain messages, while maintaining separate intent-based paths through Express interface (e.g. implemented in Squid).

Verification Mechanisms

Categorized by how AMBs handle message integrity and security:

• External validator networks (most widespread) — solutions like Wormhole rely on a network of independent validators to verify cross-chain messages. These validators observe and sign messages, requiring a threshold of signatures before a message is considered valid.
• Light client proofs — IBC protocol in Cosmos ecosystem uses cryptographic proofs from the source chain. It maintains light clients of connected chains, allowing direct verification of block headers and state transitions without trusting external validators, but requires more computational resources.
• Optimistic verification — Nomad implemented a fraud-proof system where messages were considered valid after a challenge period. During this period, watchers can challenge invalid messages. This approach reduced immediate validation overhead while trying to maintain security through economic incentives.
• Modular verification — Hyperlane separates message verification from delivery through their Interchain Security Module, allowing different security models to be plugged in. This enables customizable security vs. speed trade-offs based on specific use case requirements.

State Management

Categorized by how AMBs handle state transitions:

• Validator-driven state updates: — different AMBs implement various approaches to validator-based state management, e.g. Axelar uses a proof-of-stake consensus, Wormhole employs multi-sig consensus, etc.
• Message queue systems — LayerZero's ULNs implement strict message ordering through a combination of source and destination nonces. Each message is assigned a unique ID tuple, where chain-specific nonces are strictly incremented.
• Batching: — some AMBs optimize state transitions by processing multiple messages in a single consensus round. For example, Wormhole's Guardian network can batch-sign multiple VAAs together, reducing the overhead of individual message processing while maintaining the same security guarantees.

As the attentive reader may notice, the current AMB landscape reflects a diverse ecosystem of solutions, each implementing different combinations of approaches, while trying to find the best approach to solve specific use cases.

However, they all lack in providing a unified, developer-friendly abstraction layer that works on clear rules and could simplify cross-chain development while maintaining security and efficiency. Or in other words, waiting for the SMTP moment in cross-chain communications.

Heterogeneous AMB abstraction

While AMBs excel at reliable cross-chain message delivery, certain use cases require more complex execution patterns. Intent-based AMBs offer complementary capabilities that POCA leverages to extend POCA integrators’ opportunities beyond capabilities of any given AMB.

Understanding intent-based AMBs

Intent-based AMBs operate on fundamentally different principles than deterministic AMBs:

• Users express desired outcomes (as a string of text) rather than specific message paths
• Multiple independent solvers compete to fulfill these intents optimally
• On-chain auctions determine the best execution path
• Economic incentives and security (through staking) drive solver efficiency

Determinism vs Intent

POCA intermediate play

Our objective here is to enable seamless, optionally invisible, integration of any AMB type:

1. Same unified interface
• Applications use a single interface with a standardized format
• POCA handles translation to appropriate system formats
2. Smart routing
• Routes simple messages through AMBs for reliability
• Forwards complex operations to intent-based AMBs
• Allows explicit routing preferences from integrators
3. Fallback mechanisms
• Can fall back to deterministic AMBs if intent-based execution fails
• Ensures reliable message delivery while attempting optimization

This combination allows POCA to offer both reliable message delivery and optimized execution, all served to POCA integrators through a single, standardized interface.

Architecture overview

POCA introduces a modular architecture comprising:

• Processors — core components responsible for executing transactions on each chain,
• Adapters — modules that interface with different chains and interoperability solutions.

The detailed architecture diagram below provides a comprehensive view on how POCA is designed, illustrating interactions between key components such as processors and adapters.

Design principles

• Survivability
• Protocol operates even if certain chains within POCA network are experiencing downtime
• Protocol operates even if certain AMBs become inaccessible, no data lost
• Protocol can recover the full state and resume operations without manual intervention
• Variety of service-level protocols — flexible integration with multiple AMBs
• Variety of networks with heterogeneous technologies — cross-ecosystem interoperability
• Modularity — ease of attaching new chains without disrupting existing operations

Processors

Processor contracts are the core of POCA, handling the execution of encoded instructions that may involve multiple commands across multiple distinct and often incompatible chains. It manages the execution flow, enabling streamlined end-to-end interactions, whether within a single dApp or across multiple dApps on multiple chains.

Stack-based virtual machine

Each Processor implements a primitive virtual machine that interprets and executes bytecode instructions encoded within message payloads. This is achieved using a stack-based execution model which manipulates a virtual stack through opcodes such as PUSH, CALL, IF, ELSE, ENDIF. The stack dictates the flow based on conditions evaluated at runtime.

Programmable abstraction

POCA VM offers programmable capabilities that empowers developers to encode complex logic within a single payload:

• Complex execution flows — multiple nested conditional branches and function calls
• Conditional logic via opcodes — advanced execution paths and flow mechanisms
• Reduced complexity — abstracted low-level execution details
• Extensibility — by introducing new opcodes without altering the fundamental architecture

Adapters

Adapter contracts are modular components that interface with different chains and cross-chain messaging protocols, highly specialized and implement different interaction schemes. They allow POCA to support a wide range of blockchains and interoperability standards by adding new adapters (e.g. messaging protocols) without altering the core system.

Features

POCA offers developers several unique features ensuring seamless DX:

• Extremely simple interface
• Single entry point function for all interactions
• Single argument in the function signature
• Stack-based execution model
• Stateless, zero liquidity protocol
• No vendor lock-ins
• Queries for reading state on remote chains
• Hooks (pre/post-effects, callbacks)
• Conditionals and flow control

Single entry point

/// @inheritdoc IProcessor
function execute(bytes memory instruction)
		external
		payable
{
    _execute(instruction);
}

Instruction example

Command({
    operation: abi.encode(
        uint8(1),
        uint8(2),
        uint64(fee),
        USDC_ETH,
        bytes8(keccak256("transfer(address,uint256)")),
        uint112(0)
    ),
    input: abi.encode(UNIROUTER_ETH, 500_000)
});

Instruction structure

POCA utilizes a standardized instruction encoding structure, enabling the specification of complex operations spanning across multiple chains in a unified format.

Header

SID (uint256): 32 bytes, message identificator
ACK (uint256): 32 bytes, acknowledge number to check the order
LEN (uint256): 32 bytes, length of the payload
HSH (bytes32): 32 bytes, hash of the payload to check integrity

Payload

OPERATIONS (bytes[]): of arbitrary length
INPUTS (bytes[]): of arbitrary length

Security considerations

POCA follows several principles that directly contribute to security:

• Stateless — POCA doesn’t store any client data
• Zero-liquidity — POCA architecture doesn’t imply any pools or user funds custody
• Message integrity verification — ensuring messages have not been tampered
• Authorization — POCA has built-in mechanisms to unequivocally identify senders/receivers
• Data validation — strict decoding and error handling

POCA Scan

Essential component of POCA ecosystem, acting as a comprehensive browser and explorer for cross-chain workflows. It provides deep insights and control over cross-chain scenarios, ensuring transparency, efficiency, and seamless interaction:

• Workflow explorer — end-to-end tracking by displaying decoded function calls at each step allowing to understand the exact sequence of commands and their execution results
• Detailed operation data — access to extensive information about each operation, including chains, AMBs, applied settings and operations specifics
• Realtime flow status — check if workflows are pending or successfully executed, understand the state of each operation within the workflow for quick diagnosis of any issues
• Manual control and intervention — in cases where execution is delayed or stuck, users can manually intervene to resolve issues, ensuring timely completion
• Ecosystem interface — acts as a human interface for POCA ecosystem, showcasing trending POCA workflows with speed and performance statistics — encouraging user engagement and exploration of ecosystem capabilities with seamless navigation to 3rd-party dApps and widgets of ecosystem partners and integrators

POCA SDK

POCA offers the Software Development Kit that allows to quickly compose, encode, decode and verify inputs and data for complex multi-chain scenarios — all done in a language of their choice (Typescript/Javascript or Rust).

For example, if user wants to long BTC on Solana if its LP APY on Ethereum is less than expected, then POCA instruction builder can execute it with combination of Query and flow conditionals.

Rust

use poca_sdk::PocaSDK;
use poca_sdk::types::{Chain, Condition, Operator};
use poca_sdk::utils::parse_units;
use user::User;
use kamino::Kamino;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let provider = Provider::new();
    let signer = Signer::new();
    let user = User::new();
    let mut poca = PocaSDK::new(provider, signer);

    let instruction = poca
        .create_instruction(Chain::Ethereum)
        .transfer_usdc(TransferParams {
            destination_chain: Chain::Solana,
            address: user.address.solana.clone(),
            amount: 100_000_000, // 100 USDC (6 decimals)
        })
        // Indicates we're making a view call from Solana to Ethereum
        .if_condition(Condition::Query {
            chain: Chain::Ethereum,
            query: "WBTC.APY".to_string(),
            operator: Operator::LessThan,
            value: parse_units("75000", 8), // $75,000 with 8 decimals
        })
        .call_contract(CallContractParams {
            address: Kamino::ALV_USDC_WBTC.to_string(),
            function_name: "deposit".to_string(),
            on_behalf: Some(user.address.solana.clone()),
            amount: user.balance_of(),
        })
        .else_do()
        .transfer_usdc(TransferParams {
            destination_chain: Chain::Solana,
            address: user.address.solana.clone(),
            amount: user.balance_of(),
        })
        .end_if()
        .execute()?;

    Ok(())
}

Typescript

import { PocaSDK } from "poca-sdk";

// Initialize the SDK with provider and signer
const poca = new PocaSDK(provider, signer);

// Create and execute an instruction
const instruction = poca
  .createInstruction(ETHEREUM)
  .transferUSDC({
    destinationChain: "Solana",
    address: user.address.solana,
    amount: 100e6, // 100 USDC
  })
  .if({
    type: "query", // Indicates we're making a view call from Solana to Ethereum
    chain: "Ethereum",
    query: "WBTC.APY",
    operator: "<",
    value: parseUnits("75000", 8), // $75,000
  })
  .callContract({
    address: Kamino.ALV.USDC.WBTC,
    functionName: "deposit",
    onBehalf: user.address.solana,
    amount: user.balanceOf(),
  })
  .else()
  .transferUSDC({
    address: user.address.solana,
    amount: user.balanceOf(),
  })
  .endIf()
  .execute();

Use-case PoCs

Pike Universal Vault

Pike Universal Vault

AI Agents cross-chain Interaction SDK

AI Agents cross-chain Interaction SDK

Future work

Coprocessors

The current iteration of POCA works on inputs encoded within the instruction’s bytecode and stored on-chain. To enable advanced and computation-heavy processing of inputs without being limited to performance of specific chains, we are working on architecture of a new entity, called Coprocessor, which can be used for a highly specialized logic.

First promising use case application of Coprocessor will be aimed at fetching and verifying off-chain inputs within a single transaction.

This also will

POCA VM

We consider the capability to operate independently of off-chain infrastructure as a defining feature of the new generation of cross-chain protocols with self-sustainable designs, contributing to the core principle of survivability.

Self-contained

This is achieved by encapsulating a minimalistic stack-based machine within each protocol instance on every chain, where the execution logic is derived solely from messages. Stack-based execution approach enables each POCA instance to operate as a separate, isolated and self-sustained unit capable of executing an advanced business logic:

• Verification of integrity — for validation at any execution step, on any chain
• Logic recreation — for consistency (e.g. invariants checking) without off-chain infrastructure
• Logic restoration — for traceability/audits in case of chain isolation or global AMB failures

Interpreter implementation

POCA stack-based virtual machine is built on LIFO basis (similar to EVM, SVM, TONVM, etc.) and allows for highly efficient execution. Although the VM is in nascent stages, the POCA interpreter supports a limited subset of opcodes only required for efficient flow control. Concept of stack-based machines make it straightforward for developers to leverage POCA programmability when building complex workflows.

Copy

/* Nested conditionals */
PUSH true
IF (conditionA)
    CALL function1
    
    IF (conditionB)
        CALL function2
    ELSE
        PUSH false
        CALL function3
    ENDIF
ENDIF

Stack depth

The initial implementation of POCA leverages bit manipulation to achieve a maximum stack depth of 256. We consider this as sufficient for most scenarios, as it supports up to 256 execution conditions, which can, in turn, control even more commands (chain-level transactions) within the instruction. This design ensures POCA efficiency and performance while maintaining the unprecedented flexibility for complex cross-chain conditional logic.

Self-sustained

Each Processor is designed to be self-sustaining. Even in scenarios where POCA instance on some chain becomes isolated due to AMB outage or failure, POCA retains the capability to react conditionally by making local control flow decisions on embedded logic and known state.

Fully on-chain and deterministic execution

Through the VM interpreter and logic encapsulation, Processors can interpret and execute logic deterministically, without relying on external data from remote chains or off-chain supporting systems. With message payloads encoded in raw bytes format, POCA VM is effectively platform-agnostic and can be hosted and run on any existing and future blockchain types.

dApps innovations

POCA is expected to catalyze a wave of innovations in dApps across various sectors by allowing developer teams to focus on core business logic of their products. This means new services, use cases and applications emphasizing end user convenience.

Conclusion

By simplifying cross-chain interactions and reducing the technical barrier to entry, POCA paves the way for proper Chain Abstraction and novel dApps with Web2-like user experiences.

Open questions

Chain forking is always a possibility for complex multi-staged scenarios involving many chains where state changes must be orchestrated in a specific ordered way. The recovery from such an exceptional condition was not fully explored and is out of this document scope.

References

• A Survey on Blockchain Interoperability: Past, Present, and Future Trends. ResearchGate.
• Interoperability Among Heterogeneous Blockchains: A Systematic Review. Springer.
• Inter-Blockchain Communication in Cosmos Blockchain Network. MDPI.
• A Next Generation Smart Contract & Decentralized Application Platform, Ethereum.
• Towards Blockchain Interoperability, Semantic Scholar.
• End-to-End Arguments in System Design, MIT.
• Security Architecture for the Internet Protocol, IEFT.
• Management Information Base for network management of TCP/IP-based internets, IEFT.
• Travel Rule Information Sharing Architecture for Virtual Asset Service Providers, TRISA.
• Development of Trust Infrastructures for Virtual Asset Service Providers, ARXIV.
• An Attestation Architecture for Blockchain Networks, ARXIV.
• Principles of Distributed Database Systems, Springer.
• Transactions and Consistency in Distributed Database Systems, IBM.
• A Deep Dive into ERC-7683 for Cross-Chain Intent, Medium.

@copyright NUTS Research Version:12122024