Jax.Mining API

JAX Merged Mining API integration flow description

Provided API simplifies merged mining of the JAX Network with SHA256d-derived networks (like BTC, BCH, BSV, etc), and are expected to be easily integrated with already deployed mining facilities without impact on hash rate generated. Provided documentation describes all the details needed for successful integration.

Communication and support

As developers, we do understand how important it is to have a direct way of communication with third-party developers during an integration process. We prefer fast and efficient communication channels (like Telegram, Discord, etc) and would set up a communication channel for you ASAP. All you need to do is to notify us via [email protected]

Benefits of using API instead of direct mining

  • Lower complexity Using an API allows you to delegate maintenance of the JAX-nodes infrastructure directly to us. You do not need to have a deep knowledge of how to deploy it, control it, and how to maintain it.
  • Lower resources consumption (including human resources) You can do and support the integration with the help of the same team that supports your mining facilities. Since there are no additional deployments and components — you will most probably not need additional data center resources or human resources.
  • HashRate risk-free The proposed integration schema being implemented correctly does not affect the level of the hash rate generated for the original network.

Hash Sorting Filtering

Dealing with multiple shards, JAX Network has introduced a way how to control block propagation problems by distributing blocks generation in time. This affects the mining process, so it should be briefly explained in this doc.
The idea is that to be accepted by some shard, the PoW hash should begin with the required prefix. This prefix is unique for specific the shard (until the total amount of shards is less than Hash Sorting Number), and can repeat every Hash Sorting number in other case. For instance, if Hash Sorting Number is set to 16 (4 bits) then the PoW prefix is 4 bits long. If the network has only Beacon Chain (prefix == 0), and let's say 2 shards (prefixes are 1, and 2) then if the PoW hash of the submitted block begins with 0, 1, or 2 — the submission would be accepted into the Beacon Chain, or Shard 1, or Shard 2 correspondingly. Otherwise — the submission would be ignored.
Taking into account that Hash Sorting affects the difficulty of the shards and Beacon Chain — the idea is to just swap the required amount of bits used by the target to the beginning of the PoW hash and use them as a prefix, so the PoW would look like <target bits..><hash sorting bits>
  • Hash Sorting Number for the Test Net is set to 16.
  • Hash Sorting Number for the Main Net is set to 1024.

Pool integration of HS

It is strictly suggested for the pool to implement this HS filtering on its side. Otherwise, there would be a huge amount of unusable submissions to the API, which could use the redundant amount of traffic and make significant pressure on the RPC communication layer.

Principal integration schema

Fig. 1 — Principal schema of API integration with the Mining Pool
As shown on this schema, merged mining API hides the complexity of managing nodes and the infrastructure and proxies 2 RPC methods which allows the mining pool to do merged mining with present sha256d network.
The flow is as simple as follows:
  • The mining pool constantly (asynchronously, in a loop) fetches AUX data using the method getaux This method provides targets for the beacon and each shard of the JAX network as well as HEX-encoded AUX data.
  • Being fetched this data is then used to form the coinbase TX for BTC, BCH, or BSV (depends on which network is originally mined by the pool) according to requirements specified here. Following these specific requirements is strictly required to make it possible for JAX to be merge-mined with an external sha256d network.
  • Once mined up to one of the required targets (the least one is usually used), the pool must pass the newly generated block through the Hash Sorting Filter and then, in case if block passes validation — push it back to the API.
it is not required to mine a real-world BTC/BCH/BSW/etc block that would be valid for these networks. It is totally enough to have a block, that would correspond to one of the received targets, fetched by the getaux.

API Location & Access

As API providers we do understand that the physical location of the API determines its efficiency for the pool, so we provide several regions to choose: East/West Europe, Middle East, Asia/Pacific. Please contact us and we would consider providing the API in your region.

RPC Methods

This section describes provided RPC methods in detail.
Authentication and data format

Method — getaux

Provides AUX data for further inclusion into the coinbase TX according to rules required by the protocol.
Long polling support: present
Arguments: none
Successful result
Errors processing
"result" : {
"beacon_aux_data_hex" : "6a61786e65749cc87f00bb433a7cca295fa2545b49cd139b5c8a809e5519df828d071be583986a61786e6574",
"beacon_target" : "00001fff00000000000000000000000000000000000000000000000000000000",
"shards_targets" : {
"1" : "001ff00000000000000000000000000000000000000000000000000000000000",
"2" : "001ff00000000000000000000000000000000000000000000000000000000000",
"3" : "001ff00000000000000000000000000000000000000000000000000000000000"
  • beacon_aux_data_hex — HEX-encoded AUX data, that must be added to the mined block.
  • beacon_target and shard_targets define beacon and shards targets correspondingly. (the number i in shard_targets defines shard ID)
In case of any issue, corresponding error field would be populated by an error description.
Example (curl)

Method — submitbtcaux

Accepts mined BTC / BCH / BSV / etc block data, validates it and in case of success — creates corresponding JAX network block and submits it to the corresponding shard or beacon chain.
Succesfull result
Second Tab
In case of successful request processing, the result and error fields would be set to null
"error" : null,
"id" : "id",
"result" : null
In case of any issue, corresponding error field would be populated by an error description.
Please, be patient: The error field could be a JSON-structure, that would contain more than error if submission has affected more than one shard!
Example (curl)

Responses auditing

Each response returned from the API contains a signature, that proves it was processed by the API. Corresponding response headers are:
  • sig — HEX representation of the signature.
  • timestampRFC3339 representation of the timestamp of the response processing (UTC).
Public Key

Signature schema

  • Elliptic Curve used — ed25519
  • sig = ed25519(H)
  • H — hash of the response, built by chaining another hash (response hash, 32 bytes, see below) and current timestamp in binary form (big endian encoded uint64 — Unix Nanosecond Timestamp format); H = sha256(ResponseH + T)
  • T — timestamp of the response processing (on the API side) in the UNIX nano format (int64)
  • ResponseHsha256(jsonResponse)
  • jsonResponse — json marshalled response.
Reference code of response signing (golang)

Coinbase TX requirements

This section defines requirements for a BTC / BCH / BSV coinbase transaction, that can be a valid Coinbase AUX in beacon chain and shard chain blocks in Jax.Network.

Requirements for Inputs

The protocol requires special markers and proof of inclusion to be present in the signature script of the first tx input.
  • The signature script marker is 6a61786e6574 ("jaxnet" in ASCII hex format).
  • Proof of inclusion is an exclusive hash of the Jax.Net beacon block (could be fetched via API).
They can be at any position of the signature script, but they must follow each other in a row, like this: <marker> <beacon_hash> <marker>
According to the rules of Bitcoin script serialization, in the raw format, the length must be present prior to each part.
<marker> <beacon_hash> <marker>
marker: 6a61786e6574
hash: 03e818e664515a158c4eb0b99711cae6cee330724fcc76b64f59a1789eabf414
// part of script
06 // 0x06 = 6 -- 6 bytes
6a 61 78 6e 65 74 // marker
20 // 0x20 = 32 -- 32 bytes
03 e8 18 e6 64 51 5a 15 8c 4e b0 b9 97 11 ca e6 ce e3 30 72 4f cc 76 b6 4f 59 a1 78 9e ab f4 14 // hash
06 // 0x06 = 6 -- 6 bytes
6a 61 78 6e 65 74 // marker

Requirements for Outputs

There are 3 ways to craft a Bitcoin coinbase transaction as valid BTC Coinbase AUX for Jax.Network. The only difference between them is in the set of outputs.
Outputs count
Allows Proof Of Burn
1, 2, 5, 6 or 7
3 or 4
ONLY a transaction matching one of these requirements can be used as a BTC Coinbase AUX to create a valid BTC AUX and to mine the Jax.Network block. Valid blocks for the beacon chain and shard chains can be made using these kinds.
  • If TYPE_A and TYPE_B are used as BTC Coinbase AUX, only BTC and JAXNET block rewards will be issued, while JAX reward will be burnt.
  • If TYPE_C is used as BTC Coinbase AUX, BTC, and JAXNET block rewards will be burnt.


A BTC/BCH/BSV coinbase transaction without jaxnet marker out . This type of coinbase can't cause Proof of Burn and issuance of JAX coins (in shards). It can have 1, 2, 5, 6, or 7 outputs.
There is only one requirement:
  • the address of the first out must have a vanity prefix 1JAX. Example: 1JAXmGDsiE2CyK31dYZsMamM18pPebRDAk
Example of TYPE_A transaction


This type of coinbase contains Proof of Burn and causes the issuance of JAX coins (in shards). It can have only 3 or 4 outputs.
These are the requirements for outputs:
Out N
This must be Jaxnet Marker Out
block_reward <= 6.25 BTC
This output "burns" all block rewards
block_fee <= 0.5 BTC; if block_reward < 6.25 BTC
Any valid btc address
This output handles fees of all transactions
Witness commitment
Optional output with witness commitment
NOTE: if the value of the second output is LESS than 6.25 BTC (current BTC Block reward), the protocol will check that a block fee is LESS THAN OR EQUAL TO 0.5 BTC
Example of TYPE_C transaction


JAXnet Marker Out

jaxnet marker out is a strict special predefined output that matches the following requirements:
  1. 1.
    This is the first Tx Out.
  2. 2.
    Value of this out equals 0.
  3. 3.
    This out is to the JaxNet Burn Address.
  4. 4.
    The address in mainnet is equal to 1JAXNETJAXNETJAXNETJAXNETJAXW3bkUN (testnet address mxgUfHYGyYoVEQe95oRfzSaZKHmEPHD7Kr).
  5. 5.
    PKScript of this out is equal to 76a914bc473af4c71c45d5aa3278adc99701ded3740a5488ac.
Here it is:
tx_out: [
0: {
value: 0
pk_script_hex: 76a914bc473af4c71c45d5aa3278adc99701ded3740a5488ac
pk_script_asm: OP_DUP OP_HASH160 bc473af4c71c45d5aa3278adc99701ded3740a54 OP_EQUALVERIFY OP_CHECKSIG
script_class: pubkeyhash

JAXnet Burn Address

JaxNet Burn Address is the predefined unspendable address.
mainnet address
testnet address
script asm
OP_DUP OP_HASH160 bc473af4c71c45d5aa3278adc99701ded3740a54 OP_EQUALVERIFY OP_CHECKSIG
script class

Vanity Address

Vanity address is a normal Bitcoin PublicKeyHash address that starts with the "JAX" string. For example: 1JAXmGDsiE2CyK31dYZsMamM18pPebRDAk.

Serialization format


  • Serialized transaction:
  • Explanation of serialization format:
01 00 00 00
00 01
witess marker bytes
number of inputs
ff ff ff ff
len of signature script
03e1c720080000000000000000066a61786e657420 03e818e664515a158c4eb0b99711cae6cee330724fcc76b64f59a1789eabf41406 6a61786e65740e2f503253482f6a61786e6574642f
signature script
ff ff ff ff
number of outputs
00 00 00 00 00 00 00 00
value == 0x00
len of pk_script == 0x19
pk script
7c 81 4a 00 00 00 00 00
value == 0x4a817c
len of pk_script == 0x19
pk script
38 44 01 00 00 00 00 00
value == 0x14438
len of pk_script == 0x19
pk script
00 00 00 00 00 00 00 00
value == 0x00
len of pk_script == 0x26
pk script
number of witness hashes
len of witness hash
witness hash

Signature script

  • Serialized signature script:
  • Explanation of serialization format:
size of varint
e1 c7 20
varint; next height
size of extranonce
00 00 00 00 00 00 00 00
size of marker
"jaxnet" marker
size of exclusive hash
exclusive hash
size of marker
"jaxnet" marker
size of some extra data
some extra data