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
Expand to see full implementation
Expand to see full implementation
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
Empty Slot Evaluation
Empty Slot Evaluation
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.Include Details
Include Details
Request detailed information about each account’s fee patterns:This returns additional information about how fees were calculated for each account.
Custom Lookback Period
Custom Lookback Period
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:
- Less accurate for read-only accounts - The algorithm focuses on writable accounts
- No instruction-specific analysis - Can’t consider specific operations
- Account activity dependency - Less accurate for inactive accounts
- 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