Limits
The achievable subset: what pipes, what does not, and why.
PTBVM is the achievable subset of Sui-style PTBs on Solana, not a reimplementation of the whole thing. The limits come from Solana's execution model, not from missing effort.
What pipes
- A step's u64 return value, captured into a register.
- A returned pubkey, captured for a later step to use as an account.
- PDAs derived from seeds you already know before sending.
What does not
- An account a step creates or derives at runtime from data not known before the transaction is sent. Solana schedules work by requiring all accounts up front, so an unforeseeable account cannot be referenced by a later step.
Limits and constants
A plan runs inside one Solana transaction, so it inherits the runtime's hard limits. These are the numbers that bound how big and how deep a plan can be.
| Constant | Value | Where it comes from | What it bounds |
|---|---|---|---|
| Registers | 8 u64 slots | NUM_REGISTERS in the VM | How many distinct captured values a plan can pipe at once. |
| Return-data capture | 1024 B → low 8 B | Solana MAX_RETURN_DATA is 1024 B; the VM reads the low 8 as a u64 | A capture reads a u64; a pubkey capture reads 32 bytes for a later account reference. |
| Compute per tx | 1.4M CU | Solana MAX_COMPUTE_UNIT_LIMIT | The whole plan shares one budget, so heavy legs cap the practical step count (roughly 3 to 5 heavy CPIs). |
| CPI depth | 4 (→ 8) | Solana MAX_INVOKE_STACK_HEIGHT is 4; SIMD-0268 raises it to 8 | How deep a step's own inner CPIs can nest beneath the VM's invoke. |
| Instruction trace | 64 | Solana MAX_INSTRUCTION_TRACE_LENGTH | The total number of instructions, top-level plus CPI, the runtime will trace in one transaction. |
| Transaction size | 1232 B | Solana packet MTU | The serialized plan, all pubkeys, and signatures must fit; Address Lookup Tables extend the addressable account set. |