Mapping Transaction Types

Why is it important to send correctly mapped transactions

Incorrectly mapped transactions will be rejected. Missing transactions can have a big impact on the precision of the report.

Trades - SPOT

buy, sell, swap

Mapping transactions should follow the standard CEX logic with crypto pairs (ex: ADA_USDC, ADA_EUR) dictating the buy and sell directions of assets.

Trades must not include chainData. chainData is only used in deposits and withdrawals.

F2C - Fiat to Crypto

Example: Buying 2 EUR for 1 ADA.
Type: buy
Sent Net: EUR
Received Net: ADA
Fee: EUR
chainData: null

C2F - Crypto to Fiat

Example: Selling 1 ADA for 2 EUR.
Type: sell
Sent Net: ADA
Received Net: EUR
Fee: EUR
chainData: null

C2C - Crypto to Crypto

Example: Swap ADA for USDC
Type: swap
Sent Net: ADA
Received Net: USDC
Fee: USDC
chainData: null

Deposit & Withdrawal

Crypto deposit, withdrawal

Deposit

Example: Deposit ADA from my private wallet to CEX
Type: deposit
Sent Net: null
Received Net: ADA
Fee: null
chainData:

transactionHash: hash…
network: ADA
fromAddress: null
toAddress: …

Note: network property is optional

Withdrawal

Example: Withdraw ADA to my private wallet
Type: withdraw
Sent Net: ADA
Received Net: null
Fee: ADA
chainData:

transactionHash: hash…
network: ADA
fromAddress: null
toAddress: privateWalletAddress...

Note: network property is optional

Rewards

Staking Reward

Example: Staking Reward received - ETH
Type: receive_staking
Sent Net: null
Received Net: ETH
Fee: ETH/FIAT
chainData: null

Airdrop Reward

Example: Airdrop received - ETH
Type: receive_airdrop
Sent Net: null
Received Net: ETH
Fee: ETH/FIAT
chainData: null

Fork

Example: Fork received - ETH
Type: receive_fork
Sent Net: null
Received Net: ETH
Fee: ETH/FIAT
chainData: null

Other transaction types - import procedure

Taxtris will notify the CEX partner of newly supported transaction types, as upgrades are introduced on the Taxtris platform.
As new types are introduced, the API documentation will reflect expanded supported transaction types list.

Taxtris and CEX partner will schedule meeting for introducing new types and Taxtris will provide clear documentation of which transactions can be mapped to specific new type.

Fees handling

The Fee must be specified individually in the Request Body, as a standalone property.
Sent and Received objects and respective amount properties must be specified excluding Fee.

Duplicates

Duplicate transaction list is reported back to Partner CEX in the 409 error response.

Firstly, all mapping errors need to be resolved (TYPE_MISMATCH, _INVALID_TIMESTAMP)
Duplicates will be returned in the error response after all business errors have been resolved first

Max transactions per request

The maximum number of transactions sent per request is 1000.

Successful Import of transactions

Request with list of transactions must be correctly

mapped for all transactions
no duplicates are present

Errors

[Business logic errors] Error processing for incorrectly mapped transactions

Incorrectly mapped transactions will be rejected and returned in an array of Error objects.

Refer to error response 409 for possible error cases. 409 response is the source of truth.

Error types are listed below for convenience:

INVALID_TIMESTAMP - incorrect timestamp if timestamp is set in the future
TYPE_MISMATCH - Type not properly initialised. Correct way of mapping is specified in the documentation above.

[
    {
        “id”: “149838179117",
        “error”: “TYPE_MISMATCH”,
        “message”: “BUY Transaction Type not properly initialized. Contains not allowed ‘chainMetadata’ property. Refer to apidocs for latest mapping instructions.”
    }
]

DUPLICATE_ID - duplicate transaction sent with ID

[
    {
        "id": "14983817911232",
        "error": "DUPLICATE_ID",
        "message": "The transaction with ID: 14983817911232 already exists."
    }
]

Note:Taxtris will update CEX partner in case any new errors and errors messages are introduced and provide instructions on:

what does error X signal
suggested update to resolve the issue

Schema errors

A bad request 400 will be sent for all non request body schema compliance.

Max items

{  
    "message": "body must NOT have more than 1000 items"  
}

Transaction type not supported

{
    “message”: “body/0/type must be equal to one of the allowed values”
}

externald required property - same applies for other required properties

{  
    "message": "body/0 must have required property 'externalId', body/0 must have required property 'externalId', body/0 must match a schema in anyOf"  
}