Open leighmcculloch opened 3 years ago
There is an additional issue with account missing from Claimable balance, when I use 'revoke sponsorship' operation on a claimable balance, then query account's operations, these particular operations are not listed (even if that account is transaction's source account). So when I revoke sponsorship of Account, Trustline, Signer, and Data, they show up as operations for the account, but Revoking sponsorship of Claimable Balance will not show up. I can only see these operations when I look at operations for transaction (instead of operations for account), or by querying operations on Sponsor account. I realized that this is probably because nothing in the ledger records that CB 'belongs' to that source account, until after sponsorship is revoked. I think your proposal of creator (or maybe just source_account? ) is going to improve things a bit. But maybe it will also need adjustments when loading operation list.
The creator of the claimable balance also needs populating on the claimable_balance_claimant_created
and claim_claimable_balance
operations.
When streaming operations for an account it is impossible to figure out who created the claimable balance for a claimable balance that has been claimed, and adding the creator to the claimable balance response (this issue) will be insufficient because once a claimable balance is claimed that response will disappear and 404, so the information needs capturing on the operation as well for historical lookup.
I ran into this problem trying to ingest operation streams for accounts in my own project.
There is an additional issue with account missing from Claimable balance, when I use 'revoke sponsorship' operation on a claimable balance, then query account's operations, these particular operations are not listed (even if that account is transaction's source account). So when I revoke sponsorship of Account, Trustline, Signer, and Data, they show up as operations for the account, but Revoking sponsorship of Claimable Balance will not show up.
@ire-and-curses @2opremio This looks like a bug. I know you folks are looking at claimable balances at the moment, and this is probably a separate issue to the existing issues.
@secondclaw I've investigated your claims and am running into an issue: claimable balances can't have their sponsorship revoked. This is outlined in CAP-33 itself as an error case in the RevokeSponsorship
operation:
// Claimable balances must be sponsored
If !willBeSponsored and le.type() == CLAIMABLE_BALANCE
Fail with REVOKE_SPONSORSHIP_ONLY_TRANSFERABLE
I'm seeing the same thing trying to reproduce this via Horizon, op_only_transferable
, after sponsoring a claimable balance (which are already implicitly sponsored, afaik), and trying to revoke said sponsorship.
Can you elaborate on the situation you're seeing, and perhaps create an issue with steps to reproduce the problem?
@Shaptic Hi George. The issue is really with history/audit trail, and I don't think the issue is a separate one from lack of 'source account' in claimable balance entry. What happens is when an account creates claimable balances, I reassign sponsor of the CB to a dedicated sponsor account. Since CB doesn't have 'sourceAccount' or any other reference to account that created it, if I were to reassign sponsorship back to original account, the effect of removal of sponsorship from dedicated sponsor account and reassignment back to original account is not accessible from the that original account. This is contrary to how other 'revoke' operations work. If source account has its trustlines sponsored, and I revoke that sponsorship, revoke effect is still listed on the source account. Bottom line is, when I revoke sponsorship back to source account, then look at the history of the source account, I see revoke effects of account, trustline, and signers. But I do not see it for CBs. So, I don't really think its a bug, but simply an outcome of lack of source (or creator) account on it.
I'll give you an example that's set up right now in testnet. I created an account - GDDA35IID6QVAFA7TLDFQZQHRQBDGJEWIKYDYRU5KPHSHLYU5OLGZROI, with all of its entries sponsored. Account created a claimable balance whose reserve is sponsored as well. If you go to Effects of the account, you will see that when CB is originally created, the sponsorship reassignment is visible when pulling account's effects, under "claimable_balance_sponsorship_created". Now when I revoke all sponsorship and redirect it back to the account, then look at account's effects, the 'remove sponsorship' effects are listed for account's entities, but not for CB. It's not listed under account's effects or under accounts operations. Yet, the account is now the sponsor of CB again. I think it's a gap in CB design, not a bug, stemming from lack of dedicated account field. So, what I would expect to see is when CB's sponsorship is reassigned back to original account that this reassignment is in history of the account. If that's contrary to CB's intended design, its fine, but it doesn't seem consistent with how other effects and operations are recorded.
@leighmcculloch with the work in https://github.com/stellar/go/pull/3483, there's now /claimable_balances/00000.../transactions
, and /claimable_balances/00000.../operations
endpoints. With those you can find the first operation for a claimable balance and get the creator from that. Is that a good enough work around for you for this, or is this still worth doing?
The issue I'm raising here is that the response is confusing and unintuitive.
It's awesome that we can now discover the creator via the transactions and operations sub-endpoints. 🎉 However, I think without including the creator
here, the problem remains, the response is confusing. We have evidence of this because several folks have looked at the response and assumed the sponsor
is the creator, written code, then discovered the sponsor is not always the creator.
This issue is about addressing the confusing nature of the current response and not about making the information accessible, which as you pointed out is addressed in #3305 and #3483.
What problem does your feature solve?
When looking at the response of a claimable balance it is confusing who the creator is.
The response has a
sponsor
field, and that is the only account address contained in the response that isn't a claimant. Several people I have talked to have thought that this field is the creator/sender, and in many cases it is because in many cases the creator/sender is also sponsoring the XLM reserves required to pay for the ledger space in use by the claimable balance.It is also difficult to find out who the creator/sender of a claimable balance is, but that is a separate issue and that problem will likely be addressed by the addition of links in #3305. The issue I'm raising here is that the response is confusing and unintuitive.
What would you like to see?
I'd like to see a new top-level field on the claimable balances response that contains the creator/sender's account address.
Example:
What alternatives are there?
The documentation for claimable balances could be expanded to discuss that the creator is not captured anywhere in the response. I think this would have little meaningful impact on the problem. Developers look at JSON responses and make assumptions, because JSON responses are often self-describing.
Related issues: #3305 #3306