Skip to content

Conversation

@darioAnongba
Copy link
Contributor

@darioAnongba darioAnongba commented Sep 19, 2025

Enable burning of assets by specifying a group key.

  • Add AssetSpecifier to tapcommon.proto and use it in the BurnAssetRequest
  • Change tapcli to accept group_key param in tapd assets burn commands
  • Update tapfreighter to support passing a group key in the asset specifier
  • Update BurnAsset RPC request to accept an AssetSpecifier. Breaking change!
  • Update integration tests

Example:

  • Mint asset in group key X: 1000 units
  • Mint asset in group X: 100 units
  • Burn 1080 units
  • Creates 3 outputs:
    • change: 20 units
    • burn output: 1000 units
    • burn output: 80 units

@darioAnongba darioAnongba self-assigned this Sep 19, 2025
@darioAnongba darioAnongba requested review from GeorgeTsagk and ffranr and removed request for GeorgeTsagk September 19, 2025 12:00
@levmi levmi moved this from 🆕 New to 🏗 In progress in Taproot-Assets Project Board Sep 22, 2025
@darioAnongba darioAnongba marked this pull request as ready for review September 23, 2025 11:27
@darioAnongba darioAnongba moved this from 🏗 In progress to 👀 In review in Taproot-Assets Project Board Sep 23, 2025
Copy link
Member

@GeorgeTsagk GeorgeTsagk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work!

@levmi levmi added this to the v0.8 milestone Sep 25, 2025
@darioAnongba darioAnongba removed the request for review from ffranr September 25, 2025 15:59
@darioAnongba darioAnongba force-pushed the feat/burn-group-key branch 3 times, most recently from 13a399f to 9cd15a7 Compare September 29, 2025 10:57
@jtobin jtobin self-requested a review September 29, 2025 13:08
@coveralls
Copy link

coveralls commented Sep 30, 2025

Pull Request Test Coverage Report for Build 18141060997

Details

  • 106 of 299 (35.45%) changed or added relevant lines in 5 files are covered.
  • 65 unchanged lines in 16 files lost coverage.
  • Overall coverage decreased (-0.05%) to 56.466%

Changes Missing Coverage Covered Lines Changed/Added Lines %
taprpc/taprootassets.pb.go 0 5 0.0%
tapfreighter/wallet.go 24 35 68.57%
taprpc/tapcommon.pb.go 30 68 44.12%
rpcserver.go 52 96 54.17%
cmd/commands/assets.go 0 95 0.0%
Files with Coverage Reduction New Missed Lines %
fn/context_guard.go 1 91.94%
address/mock.go 2 96.2%
mssmt/compacted_tree.go 2 77.65%
tapdb/mssmt.go 2 90.45%
tapdb/multiverse.go 2 80.59%
tapdb/sqlc/transfers.sql.go 2 83.33%
tapgarden/custodian.go 2 76.83%
universe_rpc_diff.go 2 76.0%
universe/syncer.go 2 84.22%
itest/assertions.go 3 87.67%
Totals Coverage Status
Change from base Build 18140243029: -0.05%
Covered Lines: 63754
Relevant Lines: 112906

💛 - Coveralls

@darioAnongba darioAnongba force-pushed the feat/burn-group-key branch 2 times, most recently from a9fc25c to 544f5b4 Compare September 30, 2025 16:39
@darioAnongba darioAnongba requested review from ffranr and removed request for jtobin September 30, 2025 16:42
@darioAnongba darioAnongba force-pushed the feat/burn-group-key branch 2 times, most recently from c0a0cae to c3082d6 Compare September 30, 2025 19:21
@darioAnongba darioAnongba changed the base branch from main to 0-8-0-staging October 1, 2025 15:09
@darioAnongba darioAnongba force-pushed the feat/burn-group-key branch 4 times, most recently from 86b225f to ca49ac9 Compare October 13, 2025 10:19
@darioAnongba darioAnongba requested a review from ffranr October 13, 2025 10:41
Copy link
Member

@GeorgeTsagk GeorgeTsagk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getting there
some final Qs

@darioAnongba darioAnongba force-pushed the feat/burn-group-key branch 2 times, most recently from 24569f4 to 34ff428 Compare October 16, 2025 10:03
Copy link
Member

@GeorgeTsagk GeorgeTsagk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, pending some nits

@GeorgeTsagk
Copy link
Member

We'll have to rebase 0-8-0-staging on main in order to get the LiT tests working again (there were some version bumps)

@darioAnongba
Copy link
Contributor Author

darioAnongba commented Oct 21, 2025

Oops @GeorgeTsagk, deleted a comment but wasn't on purpose. Here is the response:

Yes, I found them particularly annoying and they didn't help since in the tests I can either log anything I want to debug or apply an assertion as part of the test. Especially when we are dumping the entire response multiple times in the test.

Allow the creation of multiple vPackets when burning by group key.
Copy link
Member

@GeorgeTsagk GeorgeTsagk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re-ACKing

Copy link
Contributor

@ffranr ffranr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your continued effort and patience with this PR. I just want to confirm that we're aligned on the behavior for asset-ID-specific burning of grouped assets.

Comment on lines +3769 to +3789
// Handle different scenarios based on what was provided:
// 1. If only assetID is provided, look up the group key.
// 2. If only groupKey is provided, use it directly
// 3. If both are provided, validate consistency.
switch {
case assetID != nil && groupKey == nil:
assetGroup, err := r.cfg.TapAddrBook.QueryAssetGroupByID(
ctx, *assetID,
)
switch {
case err == nil && assetGroup.GroupKey != nil:
groupKey = &assetGroup.GroupPubKey

case errors.Is(err, address.ErrAssetGroupUnknown):
rpcsLog.Trace("Asset group key not found, asset " +
"may not be part of a group")

case err != nil:
return nil, fmt.Errorf("error querying asset "+
"group: %w", err)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the intended behaviour was:

  • If only an asset ID is specified, burn assets matching that asset ID.
  • If only an asset group is specified, burn across any tranche within that group.
  • If both an asset ID and an asset group are specified, burn assets matching the asset ID, but verify that the asset belongs to the specified group.

This approach allows burning assets across a group when the caller doesn’t care about the tranche, while preserving the option to target specific tranches (asset IDs) when needed.

Perhaps something like this:
https://gist.github.com/ffranr/9b94850c4fc828a1a3e5170b1d1af199

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// 1. If only assetID is provided, look up the group key.

This part concerns me slightly. Do we assert in the integration test that when a group collectable is burned by asset ID, only that specific asset ID is burned and not another collectable from the same group? Why do we need to populate the group key when only an asset ID is specified?

Copy link
Contributor Author

@darioAnongba darioAnongba Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • If only an asset ID is specified, burn assets matching that asset ID.
  • If only an asset group is specified, burn across any tranche within that group.
  • If both an asset ID and an asset group are specified, burn assets matching the asset ID, but verify that the asset belongs to the specified group.

This is what the code does. Did you find a bug in the current logic that somehow doesn't execute this flow?

Why do we need to populate the group key when only an asset ID is specified

This branche of the PR is the one that does not change. As you can see, the previous code already populates the group key when only the assetID is specified. My goal was specifically not to alter the previous behavior. I can investigate the reason why the group key is needed but that should not matter for this PR unless we want to change the previous logic.

@ffranr ffranr merged commit 80083ec into 0-8-0-staging Oct 28, 2025
37 of 38 checks passed
@github-project-automation github-project-automation bot moved this from 👀 In review to ✅ Done in Taproot-Assets Project Board Oct 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

7 participants