Aptos and the Vertalo Securities Protocol: A Technical Case for the Next Generation Chain

Why Move Language and the Aptos Architecture Represent a Meaningful Advance for Institutional Digital Asset Infrastructure

May 28, 2026

Abstract

The Vertalo Securities Protocol (VSP) is Vertalo’s standard for the issuance, management, and transfer of tokenized real-world assets. Like ERC-3643 and DS Protocol, VSP is an RWA tokenization standard. Unlike those approaches, VSP was designed from the beginning around a different premise: the token should delegate control to the appropriate party, not seize it.

VSP is chain-agnostic by design. We built it to be independent of any single blockchain’s assumptions about execution model, finality semantics, or token standards. Chain selection involves real tradeoffs, and those tradeoffs evolve as the technology matures. Supporting multiple chains isn’t hedging; it’s the architecturally correct position for a platform that serves regulated issuers and their investors across a multi-year lifecycle.

Vertalo has supported Ethereum (public and private), Tezos (public), and now adds Aptos (public) to the VSP chain registry. This post explains why Aptos earned that integration slot, grounded in the specific technical properties that matter for securities issuance, cap table management, and transfer agent operations. This isn’t a marketing announcement. It’s a technical accounting of what Aptos offers and what that offering means in the context of regulated asset infrastructure.

For background on how VSP is architected and how it connects to Vertalo’s API layer, see the VSP Overview in the Vertalo API Primer and my earlier post on The Vertalo API Standard.^[1]

Introduction

When evaluating a new chain for integration into VSP, we don’t begin with ecosystem buzz or token price. We begin with protocol fundamentals: the execution model, the type system, the consensus mechanism, and the developer surface. For a transfer agent, the correctness and auditability of on-chain state transitions aren’t nice-to-have properties. They’re the product. An error in token accounting isn’t a UX degradation; it’s a regulatory event.

Aptos was designed by engineers from the Diem project at Meta, and it carries that lineage in a specific and consequential way. The Move programming language, originally developed for Diem, is the execution layer for Aptos. Understanding Move is the starting point for understanding why Aptos is technically differentiated from first-generation smart contract platforms (e.g., Ethereum), and why that differentiation is directly relevant to what Vertalo does.

The Aptos team has published a formal white paper ^[2] covering the full system design. What follows focuses on the properties most relevant to regulated asset infrastructure.

VSP: The Vertalo Securities Protocol

VSP, the Vertalo Securities Protocol, is an RWA tokenization standard. It belongs to the same category of institutional tokenization infrastructure as ERC-3643 (the Tokeny standard, now part of Apex Group) and DS Protocol (the Securitize standard). All three define how ownership of a regulated security is represented on-chain, how compliance logic is enforced, and how transfers are governed. VSP is Vertalo’s answer to those same questions, and its answer is architecturally distinct.

Vertalo began work on VSP in early 2019, in direct response to what we were learning from our engagement with the SEC and FINRA during the early wave of security token activity. Those conversations shaped the protocol design from the ground up. The central issue was control.

Most compliance-aware token standards, including ERC-3643 and DS Protocol, treat the token contract itself as the compliance intermediary. The contract controls who can hold the token, who can transfer it, and under what conditions. The transfer agent, the issuer, and the relevant regulatory counterparty interact with the token on terms the contract defines. Compliance logic is centralized in the contract; the traditional principals of a securities transaction become privileged callers on someone else’s system.

Vertalo doesn’t subscribe to first-generation compliance-aware tokenization approaches.

VSP was designed around a different premise. A VSP-issued security token represents ownership natively in the token, but the authority over transfers, restrictions, and corporate actions stays with the appropriate party, whether that’s the transfer agent, the issuer, or the custodian, not with the token contract. VSP doesn’t position itself as an intermediary that other parties route through. It’s a delegation system: the protocol delegates authority to the parties that should hold it under securities law, rather than centralizing it in a smart contract layer that the protocol author controls.

This distinction isn’t academic. It’s practical, mechanical, and ultimately compliant in a way that reflects how securities transactions are executed in the real world. A transfer agent using VSP is in control of the securities records in the way a transfer agent should be. They’re not operating as a privileged caller on someone else’s protocol.

VSP’s chain-agnostic architecture reflects the same logic. Vertalo isn’t betting on a single chain because our clients, regulated issuers and their investors, operate across multi-year asset lifecycles. Chain selection involves real tradeoffs, and those tradeoffs evolve. Supporting multiple chains is the architecturally correct position, not a hedge.

That brings us to Aptos, and why its properties make it a particularly good fit for VSP, not just for the liquidity and distribution use cases that dominate the tokenization conversation, but for the record-keeping functions that are the operational core of transfer agency.

Beyond the Token: DLT’s Real Value in Transfer Agency and Asset Management

Aptos offers transfer agencies and securities issuers four properties that the operational context actually demands:

● Low and predictable transaction costs. Aptos’s fee structure is stable and substantially lower than mainnet Ethereum. For high-frequency operations like active cap table management and distribution events, fee predictability isn’t just nice to have; it’s an input to product design.

● Low latency, high throughput. Most transactions execute in the sub-second range (~100ms), and the network is capable of processing theoretically hundreds of thousands of transactions per second.

● Fast and deterministic finality. Aptos’s AptosBFT consensus mechanism provides deterministic finality in sub-second windows under normal network conditions. When a transfer settles on Aptos, it has settled. There’s no confirmation window management, no reorg handling in application code, no ambiguity in the state of the ledger.

● Long-term protocol stability. Aptos’s modular architecture supports protocol upgrades through on-chain governance rather than coordinated hard forks. For a platform like Vertalo that maintains long-term relationships with issuers across multi-year lifecycles, a predictable upgrade path isn’t optional.

● Compile-time correctness guarantees on asset logic. Move’s resource-oriented type system provides guarantees that aren’t available on Solidity-based chains. A resource can’t be copied unless explicitly declared copyable and can’t be destroyed unless explicitly declared droppable. For a cap table that has to reconcile to the cent, this class of error prevention is material.

Together, these five properties constitute a technical case for Aptos as the right substrate for regulated asset infrastructure, not for token trading, but for the work that happens before and after a trade: recordkeeping, corporate actions, distributions, and the ongoing maintenance of a master register of securities holders.

The cost picture is the most immediate illustration. Dave Hendricks, in Is Asset Management the Killer App for Distributed Ledger Technology?^[3] (ChainEnabled, November 2024), cites the benchmark from Franklin-Templeton: the legacy cost of clearing 50,000 transactions is approximately $50,000; with DLT, the equivalent operation costs approximately $1.52. That’s roughly a 30,000x reduction. This isn’t marginal efficiency gain; it’s a structural shift in the cost basis of asset administration that changes what kinds of products are economically viable to build and distribute. Aptos’s fee structure makes numbers like this attainable in production, not as a whitepaper projection, but as an operational baseline.

These properties were the wrong question to ask when the only use case in view was secondary-market token trading. They become the right question as soon as the use case shifts to what DLT is actually well-suited for: transfer agency, master security holder files, shareholder recordkeeping, and the programmatic administration of asset management functions.

The public conversation about blockchain in real-world asset contexts tends to center on the trading of so-called “security tokens.” That’s a narrow framing. The more durable and operationally significant applications of distributed ledger technology begin at the foundational level, at the functions that have to work correctly every day, across multi-year lifecycles, under regulatory scrutiny. Blake Richman’s DLT Use Cases in Asset Management^[4] (ChainEnabled, November 2023) articulates why this foundation matters. DLT, as an append-only database, creates a golden source for trust and audit across asset classes. Ownership records and their associated events (eg. mint, burn, transfer) become immutable and auditable by design rather than by convention. Smart contracts add programmability to the functions that historically required manual coordination: payments, disbursements, trading, corporate actions, shareholder votes.

As Naomi Miner describes in Vertalo’s Digital Transfer Agent^[5] (ChainEnabled, October 2023), the legacy transfer agency infrastructure is defined by manual entry, data silos, incompatible systems, and reconciliation friction. Vertalo’s purpose-built digital transfer agent addresses these problems by treating the distributed ledger as the authoritative record of securities and asset ownership across both issuance and secondary trading.

Ethereum dominates the conversation about RWA tokenization largely because of EVM compatibility and its breadth of ecosystem tooling. Those properties are most relevant to applications centered on secondary-market tradability and DeFi composability. They’re less determinative when the application is the ongoing maintenance of a master register of securities holders under SEC regulation. The chain properties that matter for transfer agency work, specifically cost, finality, stability, and correctness, point toward Aptos.

This is why Vertalo integrates chains based on specific operational properties rather than defaulting to whichever chain is largest by TVL (total value locked) or developer count. The question we’re answering isn’t “which chain is biggest” but “which chain is right for transfer agency and asset management operations at the institutional level.” On that question, Aptos has a credible and technically grounded answer.

The VSP Architecture: Chain-Agnostic by Design

VSP Chain Architecture — showing the VSP abstraction layer sitting above Ethereum, Tezos, and Aptos chain implementations, with the Vertalo API and client layer above

VSP is designed as an abstraction layer that normalizes the differences between chain execution environments. The VSP Overview describes the contract and library constellation that makes up the protocol. Each chain integration adds a chain-specific implementation of VSP’s controller and token interfaces, while the API surface that issuers and integrators interact with remains constant.

The addition of Aptos to the VSP chain registry expands the options available to issuers and FIs building on the Vertalo platform without changing the integration model for those clients. An issuer integrating with Vertalo via the VSP API doesn’t need to reason about Move, Block-STM, or AptosBFT. They interact with the same GraphQL API surface regardless of the underlying chain.

The Move Execution Model and Why It Matters for Securities

Move vs. Solidity token representation — comparing Solidity’s mapping-based approach with Move’s typed resource model and compile-time safety guarantees

Most smart contract platforms in production today descend from Ethereum’s execution model, in which contracts are programs that operate on an account-based state database. Token balances are entries in a mapping, and the contract logic governs who may modify them. The correctness of that logic is the programmer’s responsibility; the platform itself doesn’t enforce invariants about asset existence or uniqueness at the type level.

Move takes a fundamentally different position. It’s a resource-oriented language, meaning tokens and other digital assets are typed resources, not entries in a mapping. The Move type system enforces linear and affine resource semantics at compile-time: a resource can’t be copied unless explicitly declared copyable, and it can’t be destroyed unless explicitly declared droppable. These compile-time guarantees equate to runtime guarantees, providing a peace of mind that potentially catastrophic coding errors will not find their way into the production environment.

The consequence is that the accidental duplication, loss, or mishandling of tokens isn’t merely unlikely; it’s a category of error that the language prevents. For Vertalo’s use case, where a security token represents an ownership interest in a regulated instrument and the cap table must reconcile to the cent, this is a meaningful property. It reduces the attack surface for a class of correctness errors that have caused material losses on other chains.

The Aptos documentation covers the Move language fundamentals at Move on Aptos ^[6], and The Move Book ^[7] provides a thorough treatment of the language’s type system, resource model, and module structure. Developers coming from Solidity will find the resource semantics require a conceptual shift, but the safety properties that shift enables are well worth the learning curve.

The Move Prover ^[8] extends this further, allowing developers to write formal specifications of contract behavior and verify them statically against the implementation. The Move Specification Language ^[9] documentation covers the specification syntax and verification workflow in detail. Native formal verification of smart contracts is unusual in the industry; most ecosystems rely on audits,test suites, and/or third-party tooling which are probabilistic rather than conclusive. The Move Prover doesn’t replace audits, but it enables a class of static assurance that is otherwise unavailable. For FIs integrating with Vertalo, this translates to a higher confidence floor in the correctness of the on-chain logic governing their clients’ assets.

This matters specifically for VSP’s delegation model, one of its key differentiators when compared with ERC-3643 or DS Protocol. The correctness of a system that delegates authority to transfer agents and issuers is only as reliable as the enforcement of that delegation. Move’s resource semantics and formal verification tooling mean that the delegation logic in VSP can be specified and verified, not merely tested, before deployment. That purpose-built verification regime is a materially higher standard than what’s achievable on Solidity-based chains.

Execution, Finality, and the Settlement Window: Criticality in High-Frequency Financial Services Transactions

Block-STM parallel execution — comparing sequential transaction processing with Block-STM’s optimistic parallelism and conflict-based re-execution

Beyond correctness, the operational characteristics of a chain determine what kinds of workflows are practical to build on top of it. Two properties matter most for transfer agent operations: throughput under load and the reliability of finality.

Aptos uses Block-STM ^[10], an optimistic parallel execution engine. Transactions are executed concurrently by default and re-executed only when a conflict is detected on a shared state. This parallel execution approach is materially different from sequential execution models, where throughput is bounded by the time to process each transaction in order. Block-STM doesn’t require manual state sharding or partitioning by the application developer; the parallel execution is a property of the runtime. The original Block-STM research paper (arXiv:2203.06871) details the algorithm and its performance characteristics under varying conflict rates. For Vertalo, this means that bulk operations, distributing dividends to a large cap table, or processing a redemption event, aren’t bottlenecked by serialization in the way they would be on a sequential chain.

AptosBFT finality — comparing probabilistic finality with AptosBFT’s deterministic sub-second finality and the implications for settlement certainty

Aptos uses the AptosBFT consensus mechanism ^[11], a variant of HotStuff, which provides deterministic finality in sub-second windows under normal network conditions. This is a meaningful distinction from probabilistic finality models, where the settlement certainty of a transaction increases over time but is never absolute. (This differs from a chain like Ethereum where a transaction is considered final only after a certain number of blocks have been added to the chain.) Deterministic finality simplifies the client-facing UX for Vertalo’s issuers and their investors: when a transfer settles, it has settled. There’s no confirmation window management, no reorg handling in application code, and no ambiguity in the state of the ledger at any point in time. For regulated transfer agency, where the settled position of a security has legal significance, deterministic finality is the correct semantic.

Account Model and Onchain Governance

The Aptos account model ^[12] includes several properties worth highlighting in the context of institutional asset management.

First, key rotation is supported natively: an account can rotate its signing key without changing its address. Full details are in the Account Key Rotation guide ^[13]. This key rotation capability matters for institutional clients where key management is an ongoing operational function. Custodians rotate keys; institutional treasury operations rotate keys. A model that requires address migration on key rotation introduces reconciliation complexity that is entirely avoidable.

Second, Aptos supports multi-agent transactions ^[14]: a single transaction can have multiple independent signatories, each authorizing their portion of the operation atomically. This primitive maps naturally to regulated workflows where both the issuer and the transfer agent, or the issuer and the investor, must co-authorize an action. Building equivalent logic on a chain without native multi-signer support requires off-chain coordination and additional on-chain contract logic. Native support reduces implementation surface and the corresponding audit scope. Additionally, traditional mult-sig and MPC transactions may be implemented for high-value use cases where latency is not a major concern (smart contract updates, emergency pauses, etc.).

Third, Aptos’s modular architecture decouples validators, execution, consensus, and storage. Protocol upgrades can be executed through on-chain governance without hard forks, a constant challenge when building on or maintaining certain other chains. For a platform like Vertalo, which maintains long-term relationships with issuers across multi-year asset lifecycles, protocol stability and a predictable upgrade path are operational requirements. A chain that requires coordinated hard forks for protocol changes introduces ecosystem risk that’s difficult to manage in a regulated context.

The Developer Surface and Standard Libraries: The Fungible Asset Standard

The Aptos Framework ships a set of audited standard modules for fungible assets, non-fungible assets (using the Token Objects standard), staking, and multisig. The Aptos Standards overview ^[15] and the Fungible Asset Standard ^[16] documentation are the primary references. The existence of audited standard libraries isn’t a convenience; it’s an architecture decision with meaningful implications. When token standards are provided by the protocol team and formally audited, developers building on top of them inherit a portion of that assurance. When developers implement their own token standards from scratch, as is common on chains without a rich standard library, each implementation is a fresh audit surface.

For Vertalo’s integration work (which is mostly via our GraphQL APIs), the Aptos Framework’s fungible asset standard provides a solid foundation for the on-chain representation of securities instruments. We don’t need to author our own token primitive; we extend a protocol-provided one. This materially reduces the scope of the security review required for each new issuance type and simplifies the reasoning about correctness across the platform.

The developer tooling is mature relative to the age of the network. The Aptos developer documentation ^[17] covers the full toolchain: the Aptos CLI, the Move analyzer for VS Code, and the TypeScript, Python, Rust, and Go SDKs all provide a developer surface comparable to what Ethereum has accumulated over a much longer period. The official indexer exposes a GraphQL API, which aligns with Vertalo’s existing API architecture (as described in The Vertalo API Standard). Gas costs on Aptos separate storage and execution, and both are low and stable relative to fee-volatile chains. For high-frequency operations, those involved in active cap table management, fee predictability is an operational input to workflow design.

Ecosystem Infrastructure and Forward Roadmap: A Foundation for Further Innovation

The Aptos ecosystem’s infrastructure support provides the connective tissue needed for more complex product development. Major oracle providers including Pyth and Chainlink support Aptos. Cross-chain messaging infrastructure through LayerZero and Wormhole is available. Node infrastructure providers Alchemy and QuickNode support Aptos, which means developers can use familiar tools and workflows. The Aptos Foundation also runs grant programs and ecosystem funding for developers building on the network.

As the VSP roadmap extends into areas such as cross-chain asset portability (via chain-swapping among other methods), on-chain distribution payments, and programmable compliance logic, Aptos’s ecosystem depth is an asset that compounds over time. The formal verification tooling in Move, combined with the deterministic finality of AptosBFT, provides a foundation that becomes more valuable as the complexity of on-chain compliance logic increases.

Vertalo has done careful technical work to earn confidence in the chains we support. Aptos has earned its place in the VSP registry. We’ll continue evaluating the protocol’s new features and benefits to our issuers and integrated parties as it develops, and expand our integration accordingly.

We encourage you to do the same.

Chain-Enabled by Vertalo

Discussion about this post

Ready for more?