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)

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)

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 URL

  • options?: ARCOptions - Configuration options

    • apiKey?: string - API key for authentication

    • deploymentId?: string - Application deployment identifier

    • callbackUrl?: string - Webhook URL for transaction callbacks

    • callbackToken?: string - Bearer token for callback authentication

Example:

Instance Methods

broadcast(tx: Transaction): Promise<BroadcastResponse>

Broadcasts a transaction to the network.

Parameters:

  • tx: Transaction - The transaction to broadcast

Returns: Promise<BroadcastResponse>

  • txid: string - Transaction ID

  • status: string - Transaction status ('SEEN', 'QUEUED', 'MINED')

  • timestamp: number - Submission timestamp

  • competingTxs?: string[] - Array of competing transaction IDs

Example:

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 ID

  • status: string - Current status

  • blockHeight?: number - Block height if mined

  • blockHash?: string - Block hash if mined

  • confirmations?: number - Number of confirmations

  • timestamp?: number - Status timestamp

  • rejectReason?: string - Rejection reason if rejected

  • fee?: number - Transaction fee in satoshis

Example:

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>

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 transaction

  • status: string - Transaction status

  • timestamp: 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

  1. API Key Protection: Never expose API keys in client-side code. Store them securely in environment variables or secret management systems.

  2. Callback Authentication: Always verify callback tokens to ensure webhooks are coming from ARC. Use HTTPS for callback URLs.

  3. Double-Spend Monitoring: Implement immediate alerts for double-spend attempts. Consider transactions unsafe until they have sufficient confirmations.

  4. Rate Limiting: Implement rate limiting for API calls to avoid service disruptions and additional costs.

  5. Error Handling: Handle all possible error codes appropriately. Don't assume broadcasts always succeed.

  6. Fee Validation: Always verify calculated fees meet current policy requirements before broadcasting.

Performance Considerations

  1. Batch Status Queries: When monitoring multiple transactions, batch status queries where possible to reduce API calls.

  2. Callback vs Polling: Use callbacks instead of polling for production systems to reduce latency and API usage.

  3. Connection Pooling: Reuse ARC instances across requests to benefit from HTTP connection pooling.

  4. Caching Fee Policies: Cache fee policies for reasonable periods (e.g., 5 minutes) to reduce unnecessary queries.

  5. Async Operations: Use async/await properly to avoid blocking operations. Consider Promise.all for parallel broadcasts when transactions are independent.

  6. Timeout Configuration: Set appropriate timeouts for API calls based on your application's requirements.

  • Transaction - Create and manage transactions

  • BEEF - Transaction envelope format

  • - Broadcasting interface

  • - Fee calculation strategies

Code Examples

See complete working examples in:

Best Practices

  1. Always use API keys for production environments to ensure authentication and rate limiting

  2. Implement webhook callbacks instead of polling for better performance and lower latency

  3. Verify callback tokens to ensure webhooks are authentic

  4. Monitor for double-spends actively and implement alerts for suspicious activity

  5. Query fee policies before broadcasting to ensure transactions meet requirements

  6. Handle all error codes appropriately with user-friendly messages

  7. Use deployment IDs to track which version of your application broadcast transactions

  8. Implement retry logic for transient network failures

  9. Log all broadcast attempts for audit trails and debugging

  10. 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

Status

✅ Complete

Last updated