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
note:
assetId: BTC_TEST
source: class SourceTransferPeerPathResponse {
type: VAULT_ACCOUNT
subType:
id: 106
name: Simplecoin:Wallet
walletId: null
}
sourceAddress: tb1qu8ulev7pyhw7qz7y209vjfws4mkpa5f8g4yqvf
tag: null
destination: class DestinationTransferPeerPathResponse {
type: ONE_TIME_ADDRESS
subType:
id: null
name: N/A
walletId: null
}
destinations: []
destinationAddress: n2XpnPd32Tvt2x7sPZMzwpGc5sAp3tVRPh
destinationAddressDescription:
destinationTag:
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]
rejectedBy:
authorizationInfo: null
exchangeTxId:
customerRefId: null
amlScreeningResult: null
complianceResult: null
extraParameters: null
signedMessages: []
numOfConfirmations: 1
blockInfo: class BlockInfo {
blockHeight: 2818820
blockHash: 00000000b73d34ca4391b888b23befc34c121d2aaa33eb64f757e76ee0068306
}
index: null
rewardInfo: null
systemMessages: null
addressType:
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
subType:
id: null
name: N/A
walletId: null
}``
