superstack

The intersection of AI and crypto provides solutions for several AI-related challenges. Key areas of convergence include:

• Provenance and IP Licensing: Using crypto to track the origin and ownership of AI-generated content.
• Payment Rails for Agents: Providing financial infrastructure for autonomous AI agents to operate.
• Decentralized Identity: Using systems like World (which has verified over 17 million people) to provide "proof of human" and differentiate real people from bots.
• Autonomous Agent Economies: Utilizing protocol standards like x402 to enable AI agents to perform micro-transactions, access APIs, and settle payments without intermediaries. This is projected to be a significant market by 2030.
• Counterbalancing Centralization: Blockchains serve as a decentralized alternative to the highly centralized AI compute and cloud infrastructure currently dominated by a few major tech companies.

On Solana, everything is an account (programs, token balances, metadata, etc.). Every account follows a standard structure containing lamports, data, owner, executable, and rent_epoch fields.

Account Types

• Wallet Account: Owned by the System Program, has 0 bytes of data, and is not executable.
• Data Account: Owned by a custom program, contains serialized state in its data field, and is not executable.
• Program Account: Owned by the BPF Loader, contains compiled SBF bytecode in its data field, and is executable.

Key Ownership Rules

1. Data Modification: Only the account's owner can modify its data field.
2. Lamport Credits: Anyone can send SOL (lamports) to an account.
3. Lamport Debits: Only the account's owner can deduct lamports from it.
4. System Program: The System Program owns all new accounts by default until ownership is transferred during initialization.

|
Field | Type | Description |
|-------|------|-------------|
| `lamports` | u64 | Balance in lamports (1 SOL = 1,000,000,000 lamports) |
| `data` | byte array | Arbitrary data (empty for wallet accounts, program state for data accounts) |
| `owner` | Pubkey | The program that owns this account (controls who can modify `data`) |
| `executable` | bool | Whether this account contains executable program code |
| `rent_epoch` | u64 | The epoch at which rent is next due |

CPIs allow one program to call another program within a single transaction, enabling composability.

invoke vs invoke_signed

• invoke: Used to call another program while passing through the existing signers from the original transaction.
• invoke_signed: Used when the calling program needs to sign on behalf of a PDA. You must provide the seeds and the bump.

Key Constraints

• Depth Limit: CPI depth is limited to 4 levels.
• Compute Budget: CPIs share the same compute budget as the parent transaction.
• Propagation: Signer and write privileges propagate from the outer instruction to the CPI.

use solana_program::program::invoke;
use solana_program::program::invoke_signed;

// invoke: call another program, passing through existing signers
invoke(
    &instruction,           // the instruction to execute
    &[account1, account2],  // accounts required by the instruction
)?;

// invoke_signed: call another program, signing with a PDA
invoke_signed(
    &instruction,
    &[pda_account, account2],
    &[&[b"seed", &[bump]]],  // PDA signer seeds
)?;

Tower BFT is Solana's consensus mechanism, which is a PoH-optimized version of Practical Byzantine Fault Tolerance (PBFT). It uses the PoH hash chain as a shared clock to reduce the communication overhead typically required for consensus.

How it works:

• Voting on PoH: Validators vote on the PoH hash chain rather than exchanging messages about ordering.
• Exponential Lockouts: Each vote includes an exponential lockout. The longer a validator votes on a specific fork, the harder it becomes to switch. Lockouts double with each consecutive vote (1, 2, 4, 8, 16... slots).
• Deterministic Fork Selection: Fork selection is based on vote weight and lockout duration.

Key Benefits:

• Efficiency: Reduces consensus communication complexity from $O(n^2)$ to $O(n)$.
• Local Timeouts: Validators can compute timeouts locally using PoH instead of waiting for network messages.

When validating crypto ideas, look for specific signals across different platforms:

X (Twitter)

• User Complaints: "why is there no..."
• Community Activity: Founder launch threads and evidence of active communities.
• High-Signal Indicators: Repeated frustration from credible operators or real buyers using "ugly workarounds."

GitHub

• Activity: Active repos with recent commits vs. abandoned repos in the same space.
• Infrastructure: OSS substitutes, SDKs, or infra layers that reduce MVP development time.
• Data to Capture: Repo name, star count, last meaningful activity, and what the repo proves/fails to prove.

Official Sources & Helius Blog

• Protocol/Company Docs: Determine if incumbents already cover your intended wedge and if your technical thesis is plausible.
• Helius Blog (https://www.helius.dev/blog): Use for Solana-specific intelligence, including infrastructure trends (compression, priority fees, token extensions, DAS API) and builder pain points.