PromptVault

PromptVault is the on-chain registry and lifecycle governance module of the PromptHub protocol. It serves as the canonical source of truth for all registered prompts and their associated versions, licensing terms, tokenization status, and invocation history. Deployed as an Anchor program on the Solana blockchain, PromptVault ensures that prompts are immutable, traceable, and economically enforceable.

1. Smart Contract Architecture

PromptVault is implemented as a modular Anchor program on Solana with the following core components:

// Main program structure (pseudo-code)
#[program]
pub mod prompt_vault {
    use super::*;
    
    // Initialize the global vault state
    pub fn initialize(ctx: Context<Initialize>, params: InitializeParams) -> Result<()> {
        // Set up global parameters for the vault
        // Initialize fee structure, registry capabilities, etc.
    }
    
    // Register a new prompt
    pub fn register_prompt(
        ctx: Context<RegisterPrompt>,
        id: String,
        metadata_uri: String,
        version: String,
        license_type: u8,
        fee_amount: Option<u64>,
        token_gate: Option<Pubkey>,
    ) -> Result<()> {
        // Verify caller is authorized
        // Create on-chain prompt entry
        // Store IPFS content hash
        // Set licensing parameters
        // Emit registration event
    }
    
    // Create a new version of an existing prompt
    pub fn create_version(
        ctx: Context<CreateVersion>,
        prompt_id: String,
        metadata_uri: String,
        version: String,
    ) -> Result<()> {
        // Verify caller owns the prompt
        // Add new version to version history
        // Update metadata pointers
        // Emit version update event
    }
    
    // Execute a prompt and record the execution
    pub fn record_execution(
        ctx: Context<RecordExecution>,
        prompt_id: String,
        input_hash: [u8; 32],
        output_hash: [u8; 32],
    ) -> Result<()> {
        // Verify execution permission
        // Handle any token gates
        // Process usage fees
        // Record execution signature
        // Distribute royalties
    }
    
    // Update license terms
    pub fn update_license(
        ctx: Context<UpdateLicense>,
        prompt_id: String,
        license_type: u8,
        fee_amount: Option<u64>,
        token_gate: Option<Pubkey>,
    ) -> Result<()> {
        // Verify caller owns the prompt
        // Update licensing terms
        // Emit license update event
    }
    
    // Toggle prompt visibility/status
    pub fn update_status(
        ctx: Context<UpdateStatus>,
        prompt_id: String,
        status: u8,
    ) -> Result<()> {
        // Verify caller is authorized
        // Update prompt status (active, deprecated, etc.)
        // Emit status change event
    }
    
    // ... other management functions ...
}

The Anchor contexts define the accounts required for each operation:

#[derive(Accounts)]
pub struct RegisterPrompt<'info> {
    #[account(mut)]
    pub author: Signer<'info>,
    
    // PDA for prompt data, using prompt_id as seed
    #[account(
        init,
        payer = author,
        space = PromptData::SPACE,
        seeds = [b"prompt", id.as_bytes()],
        bump
    )]
    pub prompt_data: Account<'info, PromptData>,
    
    // Global vault state
    #[account(mut)]
    pub vault_state: Account<'info, VaultState>,
    
    pub system_program: Program<'info, System>,
    pub rent: Sysvar<'info, Rent>,
}

The primary on-chain data structures include:

#[account]
pub struct PromptData {
    pub id: String,                // Unique prompt identifier
    pub author: Pubkey,            // Author's wallet address
    pub metadata_uri: String,      // IPFS URI containing full DSL
    pub current_version: String,   // Current semantic version
    pub license_type: u8,          // License code
    pub fee_amount: u64,           // Usage fee (in lamports)
    pub token_gate: Option<Pubkey>, // Optional SPL token for access
    pub execution_count: u64,      // Total execution count
    pub status: u8,                // Status code
    pub created_at: i64,           // Unix timestamp
    pub last_updated: i64,         // Last update timestamp
    
    // Version tracking (limited on-chain, expanded off-chain)
    pub version_count: u8,
    pub recent_versions: Vec<VersionEntry>,
}

#[derive(AnchorSerialize, AnchorDeserialize, Clone)]
pub struct VersionEntry {
    pub version: String,
    pub metadata_uri: String,
    pub timestamp: i64,
}

// Global vault configuration
#[account]
pub struct VaultState {
    pub admin: Pubkey,
    pub treasury: Pubkey,
    pub prompt_count: u64,
    pub protocol_fee_bps: u16,     // Basis points for protocol fee
    pub creator_share_bps: u16,    // Creator royalty percentage
    pub validator_share_bps: u16,  // Validator reward percentage
}

2. Prompt Registration and Versioning

Each time a new prompt is submitted to PromptHub, PromptVault:

• Generates a semantic hash of the PromptDSL structure

• Links metadata (title, author, tags, version notes) to IPFS

• Assigns a unique Prompt ID and version ID

• Stores semantic version lineage for future forking and inheritance

The registration flow follows these steps:

1. Client-side: Author creates PromptDSL document

2. Client-side: Document is hashed and pinned to IPFS

3. On-chain: Author calls register_prompt with IPFS URI and metadata

4. On-chain: Solana program creates a PromptData account

5. Off-chain: Indexer picks up the registration event

6. Off-chain: Indexer builds searchable metadata store

Prompt authors can update prompts by submitting new versions, which are cryptographically linked to the previous state. This forms an auditable version tree and enables governance-based deprecation or certification of specific versions.

3. Token and Licensing Binding

PromptVault supports:

• NFT Binding: linking a single prompt version to a PromptNFT (non-fungible)

• SPL Token Binding: linking prompt usage rights to a fungible token (PromptToken)

• License Terms Enforcement: rules for usage limits, expiration, royalty split, access restrictions

NFT binding works through a dedicated NFT minting extension:

pub fn mint_prompt_nft(
    ctx: Context<MintPromptNFT>,
    prompt_id: String,
    metadata: Option<PromptNFTMetadata>,
) -> Result<()> {
    // Verify caller owns the prompt
    // Create Metaplex NFT with prompt reference
    // Associate NFT mint with prompt data
    // Set up royalty parameters
}

Developers or DAOs can specify:

• Who can invoke the prompt (e.g., allowlist of agents or token holders)

• Monetization parameters (e.g., invoke fee, flat-rate licensing, tiered access)

• Public or private visibility in Prompt Asset Store

4. Invocation Logging and Auditability

Each time a prompt is executed, PromptVault records a PromptSig entry, which includes:

• Caller identity (wallet address or agent signature)

• Prompt ID and version

• Input and output content hash

• Timestamp and unique nonce

// On-chain execution record
#[derive(AnchorSerialize, AnchorDeserialize, Clone)]
pub struct ExecutionRecord {
    pub caller: Pubkey,
    pub prompt_id: String,
    pub version: String,
    pub input_hash: [u8; 32],
    pub output_hash: [u8; 32],
    pub timestamp: i64,
    pub signature: [u8; 64],
}

// PDA for storing execution logs
#[account]
pub struct ExecutionLogAccount {
    pub prompt_id: String,
    pub execution_count: u64,
    pub recent_executions: Vec<ExecutionRecord>,
}

This log is publicly queryable and can be used for:

• Execution validation (proof of interaction)

• Revenue disbursement to prompt authors

• Performance analysis and ranking heuristics

The execution flow works as follows:

1. Client-side: Agent prepares inputs for prompt execution

2. Client-side: Inputs and prompt ID are hashed

3. On-chain: Agent calls record_execution with hashes

4. On-chain: Contract validates permissions and processes fees

5. On-chain: Execution record is stored

6. On-chain: Royalties are distributed to prompt author

7. Off-chain: Indexer updates execution statistics

5. Governance and Access Control

PromptVault enforces role-based and token-based access logic:

• Authors can revoke, fork, or license their own prompts

• DAO votes can certify or delist prompts

• Vault admins can update system parameters or handle disputes (through governance)

DAO governance is implemented through a dedicated governance extension:

pub fn propose_certification(
    ctx: Context<ProposeCertification>,
    prompt_id: String,
    certification_type: u8,
    justification: String,
) -> Result<()> {
    // Create certification proposal
    // Set voting parameters
    // Emit proposal event
}

pub fn vote_on_certification(
    ctx: Context<VoteOnCertification>,
    proposal_id: Pubkey,
    vote: bool,
) -> Result<()> {
    // Record vote
    // Check if threshold is reached
    // If passed, update prompt certification status
}

6. Integration with External Systems

PromptVault integrates with several external systems:

IPFS Integration:

• All PromptDSL full definitions are stored on IPFS

• Content addressing ensures immutability and versioning

• IPFS CIDs are stored on-chain for reference

Metaplex Integration:

• PromptNFTs leverage Metaplex metadata standard

• Ensures compatibility with NFT marketplaces

• Supports on-chain royalty enforcement

Oracle Integration:

• Fee oracles can dynamically adjust prompt pricing

• Usage statistics inform prompt rankings

• External validators can attest to prompt quality

By combining metadata registration, licensing enforcement, and tamper-proof execution logs, PromptVault transforms prompt publishing into a sovereign, composable, and economic on-chain primitive.