Interoperability and Extensibility

11.1A Single Execution Layer, Not a Patchwork of Layer-2 Systems

Where many blockchains achieve broader programmability by adding a separate Layer-2 execution environment, Pim Protocol's approach, described fully in Section 5.3, is to make the single base-layer virtual machine itself adapt to whatever hardware it runs on. This avoids a common interoperability failure mode: a Layer-2 system that drifts out of sync with base-layer guarantees, or that requires a separate bridge with its own trust assumptions. The trade-off, stated plainly, is that this places more design weight on the Shared Host API described in Section 5.3.3 — it is the single point that must remain correct, since it is what guarantees Lite Mode and Full Mode produce identical ledger effects.

11.2Extensibility Through Native Ledger Object Types

The Pim Cell Type Standard described in Section 7.4 is the protocol's primary extensibility mechanism. New financial and civic primitives are added as new native object types — sixteen are specified at the time of this document, spanning payments, identity, escrow, real-world assets, cooperative finance, delegated AI agents, and personal security — rather than as externally deployed smart contracts. This has a specific consequence for compatibility: every object type is validated by consensus nodes directly, using the same lock-script and type-script verification logic described in Section 7.4, so there is no risk of a popular "standard" smart contract pattern fragmenting into incompatible implementations across different applications, the way token standards have occasionally done on account-based chains.

Developer-issued tokens (object type 3 in the registry) are automatically listed on the protocol-level exchange described in Section 7.5 upon creation, removing a common friction point where a new token requires a separate, manually arranged listing process before it has any liquidity.

11.3Cross-Chain Considerations

This specification's primary focus is the base-layer protocol; a dedicated cross-chain bridge is a planned but separate undertaking, intentionally treated as distinct from the core consensus and monetary design described in this document rather than bundled into it. The protocol's quantum-resistant cryptography (Section 8.1) and the full WebAssembly compatibility of its Full Mode execution environment (Section 5.3) are both factors that any future bridge design must account for, since a bridge connecting to a system using legacy cryptography would need to carefully manage the security mismatch.

11.4Compatibility With Existing Developer Tooling

Because Full Mode is built on wasmtime, a widely used, standards-compliant WebAssembly runtime, contracts written against standard WebAssembly tooling are compatible with Full Mode execution without protocol-specific rewrites, while a dedicated compiler path produces equivalent lightweight bytecode for Lite Mode and edge-tier execution from the same underlying contract logic — letting a developer write one contract and target both execution environments without maintaining two separate codebases.