Skip to main content
The ArkService handles the core business logic of the Ark protocol’s batch processing system. Operations encompass onchain batch coordination and settlement, including the coordination of multi-party signing sessions using MuSig2, intent management, as well as offchain VTXO spending operations. It provides a comprehensive set of gRPC and REST endpoints to facilitate client-side coordination.
API references can be found here and a set of tools to handle protobuf specifications can be found here.

​
API Layer Logic

The ArkService abstracts much of the protocol logic, helping builders focus on client experiences.
Operation CategoryMethodsPurpose
System InformationGetInfoServer parameters and network information
Intent ManagementRegisterIntent, DeleteIntentClient intent registration
Batch ParticipationConfirmRegistration, GetEventStreamMulti-party batch processing coordination
Tree SigningSubmitTreeNonces, SubmitTreeSignaturesMuSig2 multi-signature coordination
Forfeit ManagementSubmitSignedForfeitTxForfeit tx submission and retrieval
Offchain ExecutionSubmitTx, FinalizeTxOffchain tx submission and finalization
Real-time UpdatesGetTransactionsStreamLive tx notifications
Building without the SDKs still requires a solid understanding of how to create, validate, and process batch events.

​
API Layer Logic Explained

GetInfo provides essential server configuration and network parameters. It returns (GetInfoResponse)
  • ..the signer public key, network type, and version information
  • ..timing parameters like round intervals and expiry delays
  • ..economic parameters such as dust limits and min/max amounts for UTXOs and VTXOs
  • ..the forfeit address where funds are sent as part of Arkade’s security mechanism
  • ..market hour information, signaling operational time windows when the Arkade server processes batches
Intent registration and removal is using BIP322 signatures for proof of ownership:
  • RegisterIntent allows clients to register new transaction intents
  • DeleteIntent enables clients to remove previously registered intents
  • ConfirmRegistration allows selected clients to confirm participation in the next batch
  • GetEventStream provides clients with real-time batch updates including batch start, finalization, and failure notifications
The server coordinates the MuSig2 multi‑signature process:
  • SubmitTreeNonces lets clients submit nonces for the MuSig2 session
  • SubmitTreeSignatures lets clients submit partial signatures for aggregation
Both functions require batch ID and the cosigner’s public key.
SubmitSignedForfeitTxs handles forfeit transaction submission. The Arkade server verifies and finalizes the transaction as part of the batch settlement process.
If a delegate is involved, the forfeit transaction is partially signed with SIGHASH_ALL | ANYONECANPAY allowing a connector output to be added once the delegate submits the intent.
Arkade’s virtual mempool tracks the two-phase lifecycle of offchain transactions that spend VTXOs:
  • SubmitTx initiates offchain spending with the user handing in signed Arkade transactions (signed_ark_tx) and unsigned checkpoint transactions (checkpoint_txs)
  • FinalizeTx completes the process by submitting fully signed checkpoint transactions
GetTransactionsStream is a server-side streaming RPC that allows clients to receive real-time notifications for both Commitment and Arkade transactions.Each notification uses TxNotification, and which includes:
  • the transaction ID (txid) and tx fields containing the transaction hash and the raw transaction data
  • VTXO state changes with spent_vtxos showing which VTXOs were consumed and spendable_vtxos showing newly created VTXOs
  • Checkpoint transactions keyed by outpoint
The stream does not support historical data, but only transactions from stream opening onwards.

​
Notes for Builders

The complete ArkService interface is defined in the Protocol Buffers specification and includes all these functions as part of the core gRPC service.
  • All endpoints follow RESTful conventions using HTTP annotations
  • Query GetInfo to verify server compatibility, network type, and version information before establishing connections
  • arkv1.GetEventStream and arkv1.GetTransactionsStream are server-side streaming RPCs for event-driven clients that should be run in background processes to react in real-time
  • All client-side operations involving intent submission should be signed using BIP322-compatible wallets
  • Intent registration and confirmation are critical steps before a client can participate in a settlement
The ArkService is complementary to the IndexerService. Use the ArkService for real-time updates and the IndexerService for historical transaction data and detailed analysis
⌘I