Skip to main content
Advanced Method: Get priority fee estimates using account keys for specialized use cases like pre-transaction analysis, batch operations, and account pattern research.

Overview

The account keys method provides a simpler alternative to transaction serialization when you need quick fee estimates or want to estimate fees before constructing the complete transaction.

Advanced Use Cases

  • Pre-transaction analysis
  • Batch account operations
  • Market research and patterns
  • Specialized architectures

Trade-offs

  • Less accurate than serialized transactions
  • No instruction-specific analysis
  • Best for account-level patterns
Recommendation: For most applications, use the serialized transaction method instead. This account keys method is for specialized use cases where you need account-level analysis or pre-transaction planning.

When to Use Account Keys

Pre-transaction Planning

Get fee estimates before constructing complete transactions

Simplified Integration

When your architecture makes transaction serialization difficult

Quick Market Analysis

Analyze fee patterns for specific accounts without building transactions

Multi-account Analysis

Understand fee patterns across multiple accounts independently

Quick Start

1

Identify Accounts

Determine which accounts will be involved in your transaction
2

Call the API

Make a request with the account keys and desired priority level
3

Apply the Fee

Use the estimate to set priority fee in your transaction

Basic Example

Implementation Guide

Core Function

Here’s a reusable function for getting priority fee estimates:

Complete Example with Multiple Priority Levels

Account Types & Strategies

High-volume program accounts typically show higher priority fees due to competition.
Expected behavior: Higher fees due to high transaction volume and competition.

Advanced Configuration Options

The evaluateEmptySlotAsZero option is particularly useful for account-based estimates:
When true (default), slots with no transactions are treated as zero fees rather than excluded. This provides more balanced estimates for accounts with sparse activity.
Request detailed information about each account’s fee patterns:
This returns additional information about how fees were calculated for each account.
Adjust the number of slots analyzed for fee estimation:
Smaller lookback: More recent, potentially volatile dataLarger lookback: More stable, historical context

Best Practices for Account Selection

Include Writable Accounts

Priority: Focus on accounts that will be modified

Add Key Programs

Context: Include relevant program accounts

Error Handling & Fallbacks

Limitations & Considerations

Account-based method limitations:
  1. Less accurate for read-only accounts - The algorithm focuses on writable accounts
  2. No instruction-specific analysis - Can’t consider specific operations
  3. Account activity dependency - Less accurate for inactive accounts
  4. No transaction size consideration - Doesn’t account for transaction complexity
When to upgrade to serialized transactions:
  • Production applications requiring highest accuracy
  • Complex transactions with multiple instructions
  • When instruction-specific fee patterns matter
  • Performance-critical applications

Serialized Transactions

More accurate method using full transaction serialization

API Reference

Complete API documentation and parameters