Overview
ASigner is a high-level abstraction that combines a Client, KeyService, and account context to provide a seamless transaction execution experience. It handles the complexity of transaction construction, signing, and submission to the network.
MemorySigner
TheMemorySigner is the default implementation that manages transaction signing with automatic nonce management, access key selection, and concurrent transaction handling.
Type Definition
Internal Architecture
The MemorySigner uses several internal components:The internal components handle complex scenarios like:
- Automatic nonce increment for sequential transactions
- Access key selection from multiple available keys
- Concurrent transaction queuing to prevent nonce conflicts
Creating a MemorySigner
Basic Creation
With Configuration
Safe Creation
Signer Methods
executeTransaction
The primary method for executing transactions. It handles the full lifecycle:- Fetches account access keys
- Selects an appropriate key from the key pool
- Gets the current nonce and recent block hash
- Constructs the transaction
- Signs it using the KeyService
- Submits it to the network via Client
- Returns the transaction result
Multiple Actions
- Throwable
- Safe
signTransaction
Sign a transaction without submitting it to the network:- You want to inspect the signed transaction before sending
- You’re implementing a transaction approval flow
- You need to submit the transaction through a different channel
Key Pool Management
TheKeyPool automatically manages access keys for the signer account:
Allowed Access Keys
Restrict which access keys the signer can use:- Exists on the account (fetched via RPC)
- Has a corresponding private key in the KeyService
Access Key Selection
The KeyPool selects keys based on:- Full Access Keys: Preferred for general transactions
- Function Call Keys: Used only if they match the transaction’s receiver and functions
- Nonce availability: Keys with available nonces are prioritized
Task Queue
TheTaskQueue ensures transaction ordering and prevents nonce conflicts:
Sequential Execution
When you callexecuteTransaction multiple times rapidly:
- Nonces are properly incremented
- Transactions don’t conflict
- Parallel execution when possible (using different keys)
Timeout Configuration
Signer Factory Pattern
For applications that need multiple signers, use the factory pattern:Error Handling
The MemorySigner has comprehensive error types for all failure scenarios:Error Registry
Error Registry
Common Error Scenarios
- No Valid Keys
- Receiver Not Found
- Insufficient Balance
- Queue Timeout
Complete Example
Here’s a complete example using all the concepts:Best Practices
Reuse Signer Instances
Create signer instances once and reuse them. The internal TaskQueue and KeyPool maintain state for optimal performance.
Use Safe Variants in Production
Always use safe variants (
safeExecuteTransaction, safeSignTransaction) in production to handle errors explicitly.Configure Task Queue Timeout
Set appropriate timeout values based on your use case:
- High-frequency transactions: 10-30 seconds
- User-initiated transactions: 60-120 seconds
- Batch operations: Consider sequential processing
Monitor Key Pool
Ensure your KeyService has private keys for all access keys on the signer account, or use
allowedAccessKeys to restrict usage.Related Concepts
- Clients - RPC client for network interaction
- Key Services - Key management and signing
- Transactions - Transaction structure and actions
- Error Handling - NatError system details