Missing counter transaction when sending tx to self

In special use case API is not returning counter transaction which is expected to show. I need to know if this is bug o feature.

  • have a VAULT with BTC asset and some balance.
  • list VAULT:BTC addresses and take one ADDRESS.
  • send one-time transaction from VAULT:BTC to ADDRESS (sending it so self)
  • in transaction history I see one outgoing transaction when I expect to see 2 (outgoing and incoming)

when I send tx to another vault I can see 2 tx as expected:

External Simplecoin:Exchange 0.13693376 BTC_TEST Bitcoin Test Completed
Simplecoin:Wallet One Time Address 0.136933765 BTC_TEST Bitcoin Test

I don’t see any reason why I should not see incoming tx. Without it account balance does not equal sum of all transaction and it is huge problem without easy solution.

Hey @pavel.niedoba

The logic is the following:

When sending from source Vault to destination Vault (both are different vaults in your workspace) there would be only 1 record of the rebalancing transaction.

When sending from source Vault to destination One Time Address (while the one time address is actually an address of a different vault in your workspace) - you will see 2 notifications (1 outgoing to One time address, 1 incoming from External).

From your description it sounds like exactly the obvious is happening in your case - can you please share transaction IDs for example so we will take a look?

I’m sending tx to One time address from sending vault. Tx id is 13e83ea9-2500-4725-947a-28b458aeb984.

I’m aware of Vaut to Vault behaviour, but this is Vault to OneTimeAddr of the sanding vault.

If one time addr is from another vault, it works as expected, but sending it to same Vaut, only outgoin tx is showing. Bitcoind wallet (the one from satoshi) works this way and we rely on it, which make migration difficult.

@pavel.niedoba ok I see the problem now…

The system does not send a notification on the incoming transaction in this specific case because it’s identified as the incoming change to the same wallet, and we do not create new transaction records for change outputs.

May I ask what is the use case of sending the funds from a vault account to an address within the same vault account?

Hello, the use case is to replace bitcoind which behaves this way. It can happen, when one our client withdraw funds from his wallet to another client wallet. It legal use case, which would leave sender wallet but never arrive to recipient wallet. Alternatively I could block such behavior, but I would need to maintain lists of addresses per each vault. Is there another way of knowing that specific one-time address is from my own vault?
I still want to have single vault for all my clients, so I don’t need to thorough omnibus burden.
Also I don’t see any reason why the transaction should be hidden in this case unless it’s bad design limitation.
Can you confirm that this not likely to be fixed?

After some thinking, there could be easy solution which would work for me. If the transaction is marked somehow that I can find out that its “rebalancing” then it’s totally fine to create opposite transaction “manually”.

However I don’t see anything i could filter these. Not on console:

Nor in API response. But maybe I missed something.

 id: 13e83ea9-2500-4725-947a-28b458aeb984
    externalTxId: null
    status: COMPLETED
    subStatus: CONFIRMED
    txHash: 16d7b6f43ecdf8e8468b6df40f87fd063f5194374cc483657e65b8992ade73e4
    operation: TRANSFER
    assetId: BTC_TEST
    source: class SourceTransferPeerPathResponse {
        type: VAULT_ACCOUNT
        id: 106
        name: Simplecoin:Wallet
        walletId: null
    sourceAddress: tb1qu8ulev7pyhw7qz7y209vjfws4mkpa5f8g4yqvf
    tag: null
    destination: class DestinationTransferPeerPathResponse {
        type: ONE_TIME_ADDRESS
        id: null
        name: N/A
        walletId: null
    destinations: []
    destinationAddress: n2XpnPd32Tvt2x7sPZMzwpGc5sAp3tVRPh
    contractCallDecodedData: null
    amountInfo: class AmountInfo {
        amount: 0.146752925
        requestedAmount: 0.146752925
        netAmount: 0.14675292
        amountUSD: 9881.33737567
    treatAsGrossAmount: null
    feeInfo: class FeeInfo {
        networkFee: 0.00175307
        serviceFee: null
        gasPrice: null
    feeCurrency: BTC_TEST
    networkRecords: null
    createdAt: 1717058672382
    lastUpdated: 1717059440596
    createdBy: ea49edb0-1ed8-43ad-9fdb-0ef8be714783
    signedBy: [8b23db03-99b1-480d-81c5-796222f25aaf]
    authorizationInfo: null
    customerRefId: null
    amlScreeningResult: null
    complianceResult: null
    extraParameters: null
    signedMessages: []
    numOfConfirmations: 1
    blockInfo: class BlockInfo {
        blockHeight: 2818820
        blockHash: 00000000b73d34ca4391b888b23befc34c121d2aaa33eb64f757e76ee0068306
    index: null
    rewardInfo: null
    systemMessages: null
    requestedAmount: 0.146752925
    amount: 0.146752925
    netAmount: 0.14675292
    amountUSD: 9881.33737567
    serviceFee: null
    fee: 0.00175307
    networkFee: 0.00175307
    errorDescription: null

for example if Id here is populated correctly, problem would be solved

 destination: class DestinationTransferPeerPathResponse {
        type: ONE_TIME_ADDRESS
        id: null
        name: N/A
        walletId: null