ARC
Overview
The ARC class in the BSV TypeScript SDK provides a production-ready interface for broadcasting Bitcoin transactions through the ARC (Arc) API. ARC is a modern transaction processor that offers advanced features like transaction status tracking, fee policy queries, double-spend notifications, and callback-based event handling. It implements the Broadcaster interface, making it a drop-in replacement for other broadcast methods.
Purpose
Broadcast transactions to the BSV network through the ARC API
Query transaction status and confirmation details
Calculate and verify transaction fees based on network policies
Monitor double-spend attempts with callback notifications
Handle transaction errors and rejection reasons
Support deployment tracking and application identification
Enable webhook callbacks for asynchronous transaction updates
When to Use
The ARC class provides two main broadcasting approaches:
1. Simple Transaction Broadcasting: tx.broadcast(arc)
tx.broadcast(arc)Use when:
Broadcasting a single, independent transaction
Transaction doesn't depend on unconfirmed parents
You want simple, straightforward broadcasting
Example:
2. BEEF Bundle Broadcasting: arc.broadcastBEEF(beefHex)
arc.broadcastBEEF(beefHex)Use when:
Broadcasting transaction chains with dependencies
Child transactions spend from unconfirmed parent transactions
You need atomic broadcasting of multiple related transactions
You want to include merkle proofs for SPV validation
Example:
Important: tx.broadcast() does NOT automatically handle transaction chains. For chains, you MUST use arc.broadcastBEEF() with a properly constructed BEEF bundle.
Basic Usage
Broadcasting a Transaction
Querying Transaction Status
Key Features
1. Transaction Broadcasting with Enhanced Features
ARC provides production-grade transaction broadcasting with deployment tracking:
2. Fee Policy Queries and Calculation
ARC provides fee policy information for accurate fee calculation:
3. Transaction Status Tracking
Monitor transaction lifecycle from broadcast to confirmation:
4. Double-Spend Detection and Notification
ARC provides double-spend detection with callback notifications:
API Reference
Constructor
Creates a new ARC broadcaster instance.
Parameters:
url: string- The ARC API endpoint URLoptions?: ARCOptions- Configuration optionsapiKey?: string- API key for authenticationdeploymentId?: string- Application deployment identifiercallbackUrl?: string- Webhook URL for transaction callbackscallbackToken?: string- Bearer token for callback authentication
Example:
Instance Methods
broadcast(tx: Transaction): Promise<BroadcastResponse>
broadcast(tx: Transaction): Promise<BroadcastResponse>Broadcasts a transaction to the network.
Parameters:
tx: Transaction- The transaction to broadcast
Returns: Promise<BroadcastResponse>
txid: string- Transaction IDstatus: string- Transaction status ('SEEN', 'QUEUED', 'MINED')timestamp: number- Submission timestampcompetingTxs?: string[]- Array of competing transaction IDs
Example:
getTransactionStatus(txid: string): Promise<TransactionStatus>
getTransactionStatus(txid: string): Promise<TransactionStatus>Queries the status of a transaction.
Parameters:
txid: string- The transaction ID to query
Returns: Promise<TransactionStatus>
txid: string- Transaction IDstatus: string- Current statusblockHeight?: number- Block height if minedblockHash?: string- Block hash if minedconfirmations?: number- Number of confirmationstimestamp?: number- Status timestamprejectReason?: string- Rejection reason if rejectedfee?: number- Transaction fee in satoshis
Example:
getFeePolicy(): Promise<FeePolicy>
getFeePolicy(): Promise<FeePolicy>Retrieves the current fee policy from ARC.
Returns: Promise<FeePolicy>
standard: number- Standard transaction fee (sats/KB)data: number- Data transaction fee (sats/KB)mining: number- Mining fee (sats/KB)
Example:
broadcastBEEF(beefHex: string): Promise<BroadcastResponse>
broadcastBEEF(beefHex: string): Promise<BroadcastResponse>Broadcasts a BEEF (Background Evaluation Extended Format) bundle containing transaction chains.
Parameters:
beefHex: string- The BEEF bundle in hexadecimal format
Returns: Promise<BroadcastResponse>
txid: string- Transaction ID of the final transactionstatus: string- Transaction statustimestamp: number- Submission timestamp
Use this method when:
Broadcasting transaction chains with dependencies
Child transactions spend from unconfirmed parents
You need atomic broadcasting of multiple transactions
Example:
Response Types
Common Patterns
Pattern 1: Production Payment Processor
Complete payment processor with ARC integration:
Pattern 2: Batch Transaction Broadcasting
Efficiently broadcast multiple transactions with error handling:
Pattern 3: Transaction Monitoring Dashboard
Real-time transaction monitoring with ARC:
Security Considerations
API Key Protection: Never expose API keys in client-side code. Store them securely in environment variables or secret management systems.
Callback Authentication: Always verify callback tokens to ensure webhooks are coming from ARC. Use HTTPS for callback URLs.
Double-Spend Monitoring: Implement immediate alerts for double-spend attempts. Consider transactions unsafe until they have sufficient confirmations.
Rate Limiting: Implement rate limiting for API calls to avoid service disruptions and additional costs.
Error Handling: Handle all possible error codes appropriately. Don't assume broadcasts always succeed.
Fee Validation: Always verify calculated fees meet current policy requirements before broadcasting.
Performance Considerations
Batch Status Queries: When monitoring multiple transactions, batch status queries where possible to reduce API calls.
Callback vs Polling: Use callbacks instead of polling for production systems to reduce latency and API usage.
Connection Pooling: Reuse ARC instances across requests to benefit from HTTP connection pooling.
Caching Fee Policies: Cache fee policies for reasonable periods (e.g., 5 minutes) to reduce unnecessary queries.
Async Operations: Use async/await properly to avoid blocking operations. Consider Promise.all for parallel broadcasts when transactions are independent.
Timeout Configuration: Set appropriate timeouts for API calls based on your application's requirements.
Related Components
Transaction - Create and manage transactions
BEEF - Transaction envelope format
- Broadcasting interface
- Fee calculation strategies
Code Examples
See complete working examples in:
Best Practices
Always use API keys for production environments to ensure authentication and rate limiting
Implement webhook callbacks instead of polling for better performance and lower latency
Verify callback tokens to ensure webhooks are authentic
Monitor for double-spends actively and implement alerts for suspicious activity
Query fee policies before broadcasting to ensure transactions meet requirements
Handle all error codes appropriately with user-friendly messages
Use deployment IDs to track which version of your application broadcast transactions
Implement retry logic for transient network failures
Log all broadcast attempts for audit trails and debugging
Set reasonable timeouts to prevent hanging operations
Troubleshooting
Issue: Broadcast fails with "INSUFFICIENT_FEE" error
Solution: Query current fee policy and recalculate fees.
Issue: Callback webhook not receiving events
Solution: Verify callback URL is publicly accessible and token is correct.
Issue: Transaction status shows "UNKNOWN"
Solution: Transaction may not have reached ARC yet. Wait and retry.
Issue: API rate limit exceeded
Solution: Implement exponential backoff and request throttling.
Further Reading
ARC API Documentation - Official ARC API documentation
Transaction Broadcasting - BSV Wiki on broadcasting
Double-Spend Prevention - Understanding double-spends
Fee Calculation - Bitcoin fee mechanisms
Webhook Security - Webhook security best practices
BSV SDK Documentation - Official SDK documentation
Status
✅ Complete
Last updated
