What “Polana builds on top of JAM” actually means 🧵
Polana doesn’t redefine how Solana programs work.
It ports Solana’s account-based execution model and runtime semantics onto JAM’s execution layer.
At the programming level, nothing fundamental changes.
Solana programs keep:
the same account-based state model
the same deterministic read/write declarations
the same execution semantics developers already rely on
What changes is where execution runs, not how programs are written.
Polana supports multiple execution paths to achieve this:
running Solana programs via an sBPF-compatible runtime
transpiling Solana bytecode into JAM’s execution format
or compiling programs natively to JAM’s PVM for tighter integration
These are execution strategies, not new programming models.
The goal is compatibility-first:
no required code changes for existing Solana programs
familiar tooling like Anchor and Solana CLI continue to work
application logic and assumptions remain intact
JAM provides the execution substrate: parallel compute, deterministic accumulation, and network-scale scheduling.
Polana maps Solana execution model onto that substrate.
So “building on top” doesn’t mean wrapping Solana in a new framework.
It means relocating Solana execution onto a different execution architecture while preserving semantics.
That’s the architectural idea behind Polana:
Solana programs, unchanged in behavior, executed on JAM’s parallel, coherent execution layer.
