In a special program registry maintained by validators

In an account on chain, with the BPF loader as the account's owner

Distributed across validators' memory only, fetched from a network index

Hashed and stored off-chain, with only the hash on chain

As a global variable inside the program's code

Embedded in the program's account data, alongside the bytecode

In a separate account that the program creates and owns

In a per-validator local cache, synchronized across nodes

To estimate compute fees before execution begins

To prevent unauthorized account access by enforcing a whitelist

Because the validator needs to verify the caller has access for each one

So the runtime can schedule non-conflicting transactions in parallel

No, because they share the global config account

Yes, because the global config is read-only for both

No, Solana transactions are processed strictly sequentially within a slot

No, because they invoke the same program

The account is created in "rent-paying" mode and slowly drains until empty

The transaction fails because modern Solana requires accounts to be rent-exempt at creation

The account is created, but then immediately deleted due to insufficient balance for rent

The account is created, but to perform transaction that interacts with that account you have to fund it to 2.2 million lamports

5,000

0 because only priority fees are charged in modern Solana

15,000

30,000

Different validators would observe different responses, breaking consensus

The BPF runtime doesn't include networking syscalls

Network calls would be too slow to fit in a 400ms slot

A consensus algorithm that selects leaders for each slot

A verifiable delay function that produces a clock all validators can independently check

A signature scheme proving transactions were received in a specific order

An optimization that lets a validator skip keeping full blockchain history