Docs
Powered by

Transactions

Structure

Warthog nodes return two types of transactions:

Signed Transactions

Such transactions are signed. Their API structure is as follows:

  "transaction": {
    "data": { ... },
    "hash": "...",
    "signedCommon": { ... }
    "processed": { ... }
  }

Currently Warthog supports the following signed transactions:

  1. WartTransfer Transfer WART to another account.
  2. TokenTransfers Transfers a non-WART token to another account.
  3. AssetCreation Creates a new asset.
  4. Cancelations Cancels a transaction if mined first and also cancels a pending order from the order book.
  5. LiquidityDeposits Deposits liquidity into a liquidity pool.
  6. LiquidityWithdrawals Withdraws liquidity from a liquidity pool.
  7. NewOrders Creates a new order for a specific WART trading pair (Warthog only supports pairs with WART as quote currency).

Transaction type labels returned by the API:

Type Explanation processed? signedCommon?
wartTransfer Transfer WART to another account    
tokenTransfer Transfer a non-WART token to another account    
assetCreation Create a new asset    
cancelation Cancel a transaction / pending order    
liquidityDeposit Deposit liquidity into a liquidity pool    
liquidityWithdrawal Withdraw liquidity from a liquidity pool    
limitSwap Create a limit order on the DEX    
reward Block reward paid to miner    
match Batch-matched orders from a block    

Induced Transactions

These are transactions that are induced by the logic of how Warthog processes a block. Currently we have the following induced transactions

  1. Reward This transaction represents the block reward.

  2. Match This transaction represents a match of three DeFi liquidity sources: buy swap orders, sell swap orders and the liquidity pool. The swaps are executed using Warthog's custom matching engine

    Sinc induced transactions were not signed by any user but are rather a side effect of block processing, compared to signed transactions we do not have the signedCommon fields but apart from that, the structure is similar:

  "transaction": {
    "data": { ... },
    "hash": "...",
    "processed": { ... }
  }

Transaction properties

We now explain the four properties data, hash, signedCommon and processed.

Property signedCommon

The signedCommon property only exists in signed transactions. It always has the structure

"signedCommon": {
  "fee": {                          // fee used for the transaction
    "E8": 9992,                     // integer representation of the fee (multiplied by 10^8)
    "str": "0.00009992"             // string representation  of the fee
  },
  "nonceId": 1,                     // nonce id used to sign the transaction
  "originAddress": "3661...e8f5a",  // signer/origin address
  "originId": 12344,                // signer/origin account id
  "pinHeight": 0                    // pin height used to sign the transaction
}

Property hash

Every transaction has a transaction hash. For signed transactions this is the hash that is used to generate the signature. For induced transactions this hash is generated when the block is included in the chain.

Properties data and processed

data contains the user-supplied transaction parameters (what is signed). processed contains the chain-computed result — present only for transactions that go through block processing (NewOrder, LiquidityDeposit, LiquidityWithdrawal, AssetCreation, Cancelation). Reward and Match are unsigned (no signedCommon) and have no processed.

1. Reward (data only — unsigned, no processed)

Block reward paid to the miner who produced the block. Unsigned — it is a side effect of block production, not submitted by a user. No signedCommon, no processed.

"data": {
  "amount": {                  // block reward paid to the miner
    "E8": 300000000,           // integer representation (1 WART = 10^8 E8)
    "str": "3.00000000"        // human-readable decimal string
  },
  "toAddress": "3661...e8f5a"  // miner receiving the reward
}

2. WartTransfer (data only — signed, no processed)

WART coin transfer from one account to another. Signed — the sender signs the transaction. No processed since a simple transfer has no chain-computed result beyond the balance change.

"data": {
  "amount": {                  // WART amount transferred
    "E8": 100000000,           // integer representation (1 WART = 10^8 E8)
    "str": "1.00000000"        // human-readable decimal string
  },
  "toAddress": "0000000000000000000000000000000000000000000000000000000000000000" // recipient address
}

3. TokenTransfer (data only — signed, no processed)

Transfer of a non-WART token between accounts. isLiquidity is true if the transferred token is a liquidity pool share. Signed. No processed — the balance changes are the result.

"data": {
  "amount": {                       // token amount transferred
    "decimals": 4,                  // token decimal places
    "str": "99.9912",               // human-readable decimal string
    "u64": 999912                   // integer representation in smallest unit
  },
  "asset": {                        // asset being transferred
    "decimals": 4,                  // asset decimal places
    "hash": "f45b...5a6b",          // asset hash
    "id": 2,                        // assigned asset ID
    "name": "TOK2"                  // asset name
  },
  "isLiquidity": false,             // true if this is a liquidity pool share transfer
  "toAddress": "0000...0000",       // recipient address
  "tokenSpec": "asset:f45b1...5a6b" // token specification string
}

4. NewOrder (data + processed)

A limit order on the DEX for a trading pair where WART is always the quote currency. Signed. The processed.remaining field shows how much of the order was not matched in the same block — if fully matched, remaining is zero. A non-zero remaining means the order (or remainder) stays in the order book.

"data": {                      // what the user signed (mirrored in processed)
  "amount": {                  // order amount
    "decimals": 4,
    "str": "0.00010000",
    "u64": 10000
  },
  "baseAsset": {               // asset being traded (WART is always the quote)
    "decimals": 4,
    "hash": "0e4825ef123456789abcdef0123456789abcdef0123456789abcdef0123",
    "id": 7,
    "name": "TOK2"
  },
  "buy": true,                 // true = buy order (pays WART), false = sell order
  "limit": {                   // limit price (exact price for this order)
    "doubleAdjusted": 1.0,     // price as double (adjusted)
    "doubleRaw": 10000.0,      // price as double (raw)
    "exponent2": -2,           // power-of-2 exponent
    "hex": "9c404d",           // raw price bytes (hex)
    "mantissa": 40000,         // 16-bit mantissa
    "precExponent10": 4        // base-10 precision exponent
  }
},

Processed:

"processed": {
  "remaining": {                // amount of the order that was NOT matched in this block
    "decimals": 4,
    "str": "0.00000000",
    "u64": 0
  }
}

5. Match (data only — unsigned, no processed)

Batch-matched orders from a single block. Unsigned — this is a side effect of block processing. The poolBefore/poolAfter fields show the liquidity pool state before and after this match. Each entry in buySwaps and sellSwaps references the matched order via historyId. Matching uses Fair Batch Matching (see the matching engine) — no intrinsic ordering among matched orders, making the algorithm MEV-proof.

"data": {
  "baseAsset": {                // asset being traded against WART
    "decimals": 4,
    "hash": "0e4825ef123456789abcdef0123456789abcdef0123456789abcdef0123",
    "id": 7,
    "name": "TOK2"
  },
  "poolBefore": {               // liquidity pool state before this match
    "base": { "decimals": 4, "str": "1000.0000", "u64": 10000000 },
    "quote": { "E8": 100000000, "str": "1.00000000" }
  },
  "poolAfter": {                // liquidity pool state after this match
    "base": { "decimals": 4, "str": "1010.0000", "u64": 10100000 },
    "quote": { "E8": 110000000, "str": "1.10000000" }
  },
  "buySwaps": [                 // swaps resulting from buy orders being matched
    {
      "swapped": {              // amounts swapped in this individual trade
        "base": { "decimals": 4, "str": "10.0000", "u64": 100000 },
        "quote": { "E8": 100000000, "str": "1.00000000" }
      },
      "historyId": 26           // history ID of the matched buy order
    }
  ],
  "sellSwaps": [                // swaps resulting from sell orders being matched
    {
      "swapped": {
        "base": { "decimals": 4, "str": "20.0010", "u64": 200010 },
        "quote": { "E8": 200010000, "str": "2.00010000" }
      },
      "historyId": 25           // history ID of the matched sell order
    }
  ]
}

6. LiquidityDeposit (data + processed)

Deposit of a base asset and WART into a liquidity pool, receiving LP shares in return. Signed. processed.sharesReceived is the amount of liquidity pool shares minted to the depositor.

"data": {
  "baseAsset": {                // asset being deposited alongside WART
    "decimals": 4,
    "hash": "0e4825ef123456789abcdef0123456789abcdef0123456789abcdef0123",
    "id": 7,
    "name": "TOK2"
  },
  "deposited": {                // amounts deposited into the liquidity pool
    "base": { "decimals": 4, "str": "100.0000", "u64": 1000000 },
    "quote": { "E8": 100000000, "str": "1.00000000" }
  }
},

Processed:

"processed": {
  "sharesReceived": {           // liquidity pool shares minted to the depositor
    "decimals": 4,
    "str": "1000.0000",
    "u64": 10000000
  }
}

7. LiquidityWithdrawal (data + processed)

Redemption of liquidity pool shares to withdraw the underlying base asset and WART. Signed. processed.received shows the actual amounts withdrawn, which may differ slightly from the proportional share due to rounding or pool state changes.

"data": {
  "baseAsset": {                // asset being withdrawn alongside WART
    "decimals": 4,
    "hash": "0e4825ef123456789abcdef0123456789abcdef0123456789abcdef0123",
    "id": 7,
    "name": "TOK2"
  },
  "sharesRedeemed": {           // liquidity pool shares being burned
    "decimals": 4,
    "str": "100.0000",
    "u64": 1000000
  }
},

Processed:

"processed": {
  "received": {                 // amounts withdrawn from the liquidity pool
    "base": { "decimals": 4, "str": "100.0000", "u64": 1000000 },
    "quote": { "E8": 100000000, "str": "1.00000000" }
  }
}

8. AssetCreation (data + processed)

Creation of a new token with a given name and total supply. Signed. processed.assetId is the ID assigned to the newly created asset.

"data": {
  "name": "TOK2",               // token name
  "supply": {                   // total token supply
    "decimals": 4,
    "str": "100000000.0000",
    "u64": 1000000000000
  }
},

Processed:

"processed": {
  "assetId": 7                  // ID assigned to the newly created asset
}

9. Cancelation (data + processed)

Cancellation by referencing a target transaction via its TransactionId (accountId, nonceId, pinHeight). Signed. Once mined, no transaction with the referenced ID can be included in the same or any future block — effectively blocking it from ever being mined. processed.canceledTxHash confirms the hash of the cancelled transaction.

"data": {
  "cancelTxid": {                 // reference to the transaction being cancelled
    "accountId": 2,               // account ID of the transaction to cancel
    "nonceId": 3,                 // nonce ID of the transaction to cancel
    "pinHeight": 10               // pin height of the transaction to cancel
  }
},
 
"processed": {
  "canceledTxHash": "ed0a...2f3a" // hash of the cancelled transaction
}

© Warthog Network 2026.