Smart Contracts

Documentation and architecture for on-chain programs. Understanding how smart contracts work on Solana: account models, authority patterns, and instruction lifecycle.

Program Overview

Portfolio Demo Program

A simple demonstration program showcasing Solana program architecture, account management, and instruction handling.

This program serves as a reference implementation for understanding how Solana programs work, including PDA derivation, account validation, and state management.

Rust + Anchor
PDA-based accounts

Account Model

Counter Account

PDA

A Program Derived Address that stores a counter value. The PDA is derived from a seed and the program ID.

Fields

count(u64)

The current counter value

authority(Pubkey)

The account authorized to increment the counter

bump(u8)

The bump seed used for PDA derivation

Authority Model

PDA-based

The program uses Program Derived Addresses (PDAs) for account ownership. The counter account is owned by the program itself, with an authority field specifying who can modify it.

  • ▸Counter account is a PDA derived from a seed
  • ▸Authority is specified during initialization
  • ▸Only the authority can increment the counter
  • ▸Program owns the account, ensuring data integrity

Instruction Lifecycle

initialize

Creates a new counter account as a PDA and sets the initial authority.

Accounts

counter
writableThe counter PDA account to initialize
authority
signerThe account that will have authority over the counter
system_program
System program for account creation

Execution Flow

1

Derive the counter PDA from seed and program ID

2

Create the account with required space

3

Set initial count to 0

4

Set authority to the provided pubkey

5

Store the bump seed

increment

Increments the counter value. Can only be called by the authority.

Accounts

counter
writableThe counter account to increment
authority
signerThe authority that must sign this transaction

Execution Flow

1

Verify the authority matches the counter account authority

2

Verify the authority signed the transaction

3

Increment the counter value

4

Update the account data

update_authority

Updates the authority of the counter account. Can only be called by the current authority.

Accounts

counter
writableThe counter account to update
current_authority
signerThe current authority (must sign)
new_authority
The new authority to set

Execution Flow

1

Verify the current authority matches

2

Verify the current authority signed

3

Update the authority field

4

Save the account data

Design Principles

Stateless Programs

Programs are pure functions. All state lives in accounts, not in the program itself.

Example: The counter value is stored in an account, not in program memory.

Account-Based State

All persistent data is stored in on-chain accounts with explicit ownership.

Example: The Counter account is owned by the program, ensuring only the program can modify it.

Deterministic Execution

Programs execute identically across all validators, ensuring consensus.

Example: The increment instruction always adds 1, regardless of which validator processes it.

Explicit Locks

Read/write permissions are enforced at the program level through account validation.

Example: Only the authority can increment; this is checked explicitly in the instruction handler.

Source Code

View the complete Anchor program implementation in the contracts directory.

View Code