feat(fungible): add a message to burn funds in the fungible module #4063
feat(fungible): add a message to burn funds in the fungible module #4063
fungible): add a message to burn funds in the fungible module #4063Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughThis change introduces a new feature enabling the burning of fungible assets (both ZRC20 tokens and native ZETA) held by the fungible module. It adds the corresponding message type, updates protobuf and TypeScript definitions, implements message server logic and tests, extends the authority module with a migration for new authorizations, and updates documentation and test coverage. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant MsgServer
participant AuthorityKeeper
participant BankKeeper
participant ZRC20Contract
User->>MsgServer: Submit MsgBurnFungibleModuleAsset (creator, zrc20_address)
MsgServer->>AuthorityKeeper: Check authorization
AuthorityKeeper-->>MsgServer: Authorization result
alt zrc20_address == zero address (burn ZETA)
MsgServer->>BankKeeper: Query spendable ZETA balance
BankKeeper-->>MsgServer: Balance
alt Balance > 0
MsgServer->>BankKeeper: BurnCoins (fungible module, amount)
BankKeeper-->>MsgServer: Success/Error
else Balance == 0
MsgServer-->>User: Error (zero balance)
end
else (burn ZRC20)
MsgServer->>ZRC20Contract: Validate address, query balance
ZRC20Contract-->>MsgServer: Balance
alt Balance > 0
MsgServer->>ZRC20Contract: Burn (fungible module, amount)
ZRC20Contract-->>MsgServer: Success/Error
else Balance == 0
MsgServer-->>User: Error (zero balance)
end
end
MsgServer-->>User: MsgBurnFungibleModuleAssetResponse / Error
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–25 minutes Suggested labels
Suggested reviewers
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #4063 +/- ##
===========================================
+ Coverage 64.71% 64.80% +0.08%
===========================================
Files 472 475 +3
Lines 34696 34818 +122
===========================================
+ Hits 22454 22563 +109
- Misses 11189 11199 +10
- Partials 1053 1056 +3
🚀 New features to boost your workflow:
|
|
A few things to fix in the lint and unit test but the E2E test pass. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
docs/openapi/openapi.swagger.yaml (1)
58234-58235: Add minimal schema details for the new response type
MsgBurnFungibleModuleAssetResponseis introduced as a bare object without even an emptyproperties:map or a shortdescription:. While an empty proto message does translate to an empty JSON object, having at least a description (and ideally an explicit emptyproperties: {}) preserves consistency with the neighbouringMsgDeployFungibleCoinZRC20Responsedefinition and improves generated client docs.zetachain.zetacore.fungible.MsgBurnFungibleModuleAssetResponse: - type: object + type: object + description: Response returned after successfully burning all assets held by the fungible module. The message contains no fields. + properties: {}docs/spec/generated.md (1)
734-735: Fix indentation formatting issues.The static analysis tool detected hard tabs in the proto message definition. Please replace tabs with spaces for consistent formatting.
- string creator = 1; - string zrc20_address = 2; + string creator = 1; + string zrc20_address = 2;e2e/txserver/bank.go (1)
27-34: Fix misleading error messageThe error message references "authorization" but this method performs a bank transfer operation. The error message should accurately reflect the operation being performed.
- if err != nil { - return fmt.Errorf("failed to add authorization: %w", err) - } + if err != nil { + return fmt.Errorf("failed to transfer ZETA tokens: %w", err) + }x/fungible/keeper/msg_server_burn_fungible_module_asset.go (1)
91-91: Remove unnecessary trailing newlineStatic analysis correctly identified an unnecessary trailing newline that should be removed for code consistency.
Remove the trailing newline:
} - return &types.MsgBurnFungibleModuleAssetResponse{}, nil }x/fungible/keeper/msg_server_burn_fungible_module_asset_test.go (1)
3-19: Improve import organization for better readability.The import order should follow Go conventions: standard library packages first, then external packages, then internal packages.
import ( "errors" + "math/big" + "testing" + sdktypes "github.com/cosmos/cosmos-sdk/types" + sdkerrors "github.com/cosmos/cosmos-sdk/types/errors" + "github.com/stretchr/testify/mock" + "github.com/stretchr/testify/require" + "github.com/zeta-chain/node/cmd/zetacored/config" "github.com/zeta-chain/node/pkg/constant" - "math/big" - "testing" - - sdkerrors "github.com/cosmos/cosmos-sdk/types/errors" - "github.com/stretchr/testify/require" keepertest "github.com/zeta-chain/node/testutil/keeper" "github.com/zeta-chain/node/testutil/sample" authoritytypes "github.com/zeta-chain/node/x/authority/types" "github.com/zeta-chain/node/x/fungible/keeper" "github.com/zeta-chain/node/x/fungible/types" )x/fungible/types/message_burn_fungible_module_asset.go (1)
45-56: Fix misleading comment in validation.The validation logic is sound, but the comment on line 50 is misleading.
- // check if the system contract address is valid + // check if the ZRC20 address is valid if !ethcommon.IsHexAddress(msg.Zrc20Address) { - return cosmoserror.Wrapf(sdkerrors.ErrInvalidAddress, "invalid system contract address (%s)", msg.Zrc20Address) + return cosmoserror.Wrapf(sdkerrors.ErrInvalidAddress, "invalid ZRC20 address (%s)", msg.Zrc20Address) }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
x/fungible/types/tx.pb.gois excluded by!**/*.pb.go,!**/*.pb.go
📒 Files selected for processing (23)
changelog.md(1 hunks)cmd/zetae2e/local/local.go(1 hunks)docs/openapi/openapi.swagger.yaml(1 hunks)docs/spec/generated.md(1 hunks)e2e/e2etests/e2etests.go(2 hunks)e2e/e2etests/test_burn_fungible_module_asset.go(1 hunks)e2e/txserver/bank.go(1 hunks)proto/zetachain/zetacore/fungible/tx.proto(2 hunks)testutil/keeper/mocks/fungible/bank.go(2 hunks)typescript/zetachain/zetacore/fungible/tx_pb.ts(3 hunks)x/authority/keeper/migrator.go(2 hunks)x/authority/migrations/v4/migrate.go(1 hunks)x/authority/migrations/v4/migrate_test.go(1 hunks)x/authority/module.go(2 hunks)x/authority/types/authorization_list.go(1 hunks)x/authority/types/authorization_list_test.go(1 hunks)x/fungible/keeper/msg_server_burn_fungible_module_asset.go(1 hunks)x/fungible/keeper/msg_server_burn_fungible_module_asset_test.go(1 hunks)x/fungible/types/codec.go(2 hunks)x/fungible/types/errors.go(1 hunks)x/fungible/types/expected_keepers.go(1 hunks)x/fungible/types/message_burn_fungible_module_asset.go(1 hunks)x/fungible/types/message_burn_fungible_module_asset_test.go(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.go
⚙️ CodeRabbit Configuration File
Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
Files:
x/authority/types/authorization_list_test.gox/fungible/types/codec.gox/authority/keeper/migrator.gox/authority/types/authorization_list.gox/fungible/types/errors.gox/fungible/types/expected_keepers.goe2e/txserver/bank.gox/authority/module.gox/fungible/types/message_burn_fungible_module_asset_test.goe2e/e2etests/e2etests.goe2e/e2etests/test_burn_fungible_module_asset.gox/fungible/keeper/msg_server_burn_fungible_module_asset_test.gocmd/zetae2e/local/local.gotestutil/keeper/mocks/fungible/bank.gox/authority/migrations/v4/migrate.gox/authority/migrations/v4/migrate_test.gox/fungible/keeper/msg_server_burn_fungible_module_asset.gox/fungible/types/message_burn_fungible_module_asset.go
**/*.proto
⚙️ CodeRabbit Configuration File
Review the Protobuf definitions, point out issues relative to compatibility, and expressiveness.
Files:
proto/zetachain/zetacore/fungible/tx.proto
🧠 Learnings (15)
📓 Common learnings
Learnt from: skosito
PR: zeta-chain/node#3939
File: go.mod:52-52
Timestamp: 2025-05-30T16:31:30.275Z
Learning: The ethermint dependency updates in the zeta-chain/node repository are typically moves between feature branches and main branch of the same fork, not breaking API changes. CI status should be verified before assuming compilation issues.
x/fungible/types/codec.go (5)
Learnt from: ws4charlie
PR: #2987
File: pkg/memo/codec.go:55-64
Timestamp: 2024-10-10T18:18:17.785Z
Learning: In the pkg/memo package, the functions NewCodecABI and NewCodecCompact are defined and accessible within the package scope, eliminating the need for explicit import statements in this file.
Learnt from: ws4charlie
PR: #2987
File: pkg/memo/codec_abi.go:88-92
Timestamp: 2024-10-10T18:34:29.749Z
Learning: In the pkg/memo/codec_abi.go file, the parsedABI method in the CodecABI struct uses the same list of ABI types for both inputs and outputs in the ABI definition, as the codec method encodes inputs and decodes outputs using the same types.
Learnt from: kingpinXD
PR: #3095
File: x/observer/module.go:37-39
Timestamp: 2024-11-14T02:18:12.028Z
Learning: The codec.Codec interface embeds both BinaryCodec and JSONCodec, so switching to codec.Codec provides a unified interface without necessitating changes in other modules.
Learnt from: ws4charlie
PR: #2987
File: pkg/memo/codec.go:31-33
Timestamp: 2024-10-10T18:17:38.781Z
Learning: In the pkg/memo package, the CodecArg type is defined and accessible within the package scope, eliminating the need for explicit import statements in each file.
Learnt from: ws4charlie
PR: #2987
File: pkg/memo/codec_abi.go:46-50
Timestamp: 2024-10-10T18:32:56.299Z
Learning: In pkg/memo/codec_abi.go, when constructing the ABI method in the AddArguments method of CodecABI, argument names are not necessary in the ABI type definitions for ABI encoding.
changelog.md (1)
Learnt from: skosito
PR: #3939
File: go.mod:52-52
Timestamp: 2025-05-30T16:31:30.275Z
Learning: The ethermint dependency updates in the zeta-chain/node repository are typically moves between feature branches and main branch of the same fork, not breaking API changes. CI status should be verified before assuming compilation issues.
x/authority/types/authorization_list.go (1)
Learnt from: lumtis
PR: #2984
File: x/crosschain/keeper/msg_server_whitelist_erc20.go:39-48
Timestamp: 2024-11-01T10:30:27.952Z
Learning: In the context of whitelisting assets in MsgWhitelistERC20 within x/crosschain/keeper/msg_server_whitelist_erc20.go, there is no specific address validation required for Solana addresses.
e2e/txserver/bank.go (6)
Learnt from: ws4charlie
PR: #4053
File: e2e/e2etests/test_bitcoin_std_deposit.go:42-42
Timestamp: 2025-07-28T18:08:13.883Z
Learning: In Bitcoin deposit E2E tests for the ZetaChain project, DepositBTCWithAmount is preferred over DepositBTCWithExactAmount because depositing exact amounts to a ZEVM receiver is complex. The tests use rough amounts and then calculate the actual received amount from the raw Bitcoin transaction to verify balance changes, making the tests more robust and less flaky.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:184-247
Timestamp: 2024-07-05T00:02:31.446Z
Learning: The CreateSignerObserverBTC function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: fbac
PR: #2979
File: x/fungible/keeper/zrc20_unlock_token.go:69-72
Timestamp: 2024-10-08T14:57:52.954Z
Learning: In x/fungible/keeper/zrc20_unlock_token.go, when performing type assertions like transferred, ok := ret[0].(bool), using the ok check is sufficient to prevent panics, and additional type handling is not required.
Learnt from: gartnera
PR: #3632
File: zetaclient/chains/solana/signer/signer.go:304-304
Timestamp: 2025-03-04T22:39:58.395Z
Learning: The Solana signer implementation in zetaclient/chains/solana/signer/signer.go has limited test coverage, particularly for the transaction broadcasting logic with fallback scenarios. Adding this coverage has been acknowledged as a potential future improvement outside the scope of immediate fixes.
Learnt from: gartnera
PR: #3070
File: cmd/zetae2e/init.go:0-0
Timestamp: 2024-10-30T17:56:16.341Z
Learning: In code reviews for Go files like cmd/zetae2e/init.go in the ZetaChain project, avoid suggesting unrelated refactoring. Focus comments on changes relevant to the PR objectives.
Learnt from: gartnera
PR: #3228
File: cmd/zetaclientd/start.go:222-231
Timestamp: 2024-11-27T22:02:48.034Z
Learning: In the zetaclient codebase, port numbers like 26657 are hardcoded, and changing them to be configurable via the config struct is considered unrelated refactoring.
x/authority/module.go (4)
Learnt from: gartnera
PR: #2817
File: contrib/rpcimportable/go.mod:1-3
Timestamp: 2024-09-24T18:43:46.232Z
Learning: In this project, minor version differences in Go modules are acceptable and do not require strict consistency.
Learnt from: ws4charlie
PR: #3793
File: pkg/contracts/sui/withdraw_and_call_ptb.go:111-118
Timestamp: 2025-04-22T15:32:20.706Z
Learning: The constant moduleName is defined in pkg/contracts/sui/gateway.go with the value "gateway" and is used across multiple files in the sui package.
Learnt from: ws4charlie
PR: #3793
File: pkg/contracts/sui/withdraw_and_call_ptb.go:111-118
Timestamp: 2025-04-22T15:32:20.706Z
Learning: The constant moduleName is defined in pkg/contracts/sui/gateway.go with the value "gateway" and is used across multiple files in the sui package.
Learnt from: ws4charlie
PR: #3461
File: x/observer/migrations/v10/migrate.go:29-34
Timestamp: 2025-02-04T06:03:54.382Z
Learning: In the observer module's ChainParams struct, the Confirmation field is a value type (not a pointer), so nil checks are not needed.
x/fungible/types/message_burn_fungible_module_asset_test.go (7)
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:184-247
Timestamp: 2024-07-05T00:02:31.446Z
Learning: The CreateSignerObserverBTC function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:116-181
Timestamp: 2024-07-05T00:02:36.493Z
Learning: The CreateSignerObserverEVM function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/orchestrator.go:192-217
Timestamp: 2024-07-04T23:46:38.428Z
Learning: The GetUpdatedSigner method in zetaclient/orchestrator/orchestrator.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go and zetaclient/orchestrator/orchestrator_test.go.
Learnt from: ws4charlie
PR: #2987
File: testutil/sample/memo.go:0-0
Timestamp: 2024-10-10T18:54:33.554Z
Learning: In the testutil/sample/memo.go file, unchecked type assertions in the ABIPack function are acceptable because it is designed for unit tests and simplicity.
Learnt from: gartnera
PR: #3632
File: zetaclient/chains/solana/signer/signer.go:304-304
Timestamp: 2025-03-04T22:39:58.395Z
Learning: The Solana signer implementation in zetaclient/chains/solana/signer/signer.go has limited test coverage, particularly for the transaction broadcasting logic with fallback scenarios. Adding this coverage has been acknowledged as a potential future improvement outside the scope of immediate fixes.
Learnt from: gartnera
PR: #3079
File: e2e/e2etests/test_pause_erc20_custody.go:65-68
Timestamp: 2024-11-01T17:07:59.584Z
Learning: In the file e2e/e2etests/test_pause_erc20_custody.go, prefer verbosity and avoid extracting common event handling logic into helper functions to enhance readability and ease future refactoring.
Learnt from: fbac
PR: #2979
File: x/fungible/keeper/zrc20_unlock_token.go:69-72
Timestamp: 2024-10-08T14:57:52.954Z
Learning: In x/fungible/keeper/zrc20_unlock_token.go, when performing type assertions like transferred, ok := ret[0].(bool), using the ok check is sufficient to prevent panics, and additional type handling is not required.
e2e/e2etests/e2etests.go (12)
Learnt from: gartnera
PR: #3079
File: e2e/e2etests/test_pause_erc20_custody.go:65-68
Timestamp: 2024-11-01T17:07:59.584Z
Learning: In the file e2e/e2etests/test_pause_erc20_custody.go, prefer verbosity and avoid extracting common event handling logic into helper functions to enhance readability and ease future refactoring.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:184-247
Timestamp: 2024-07-05T00:02:31.446Z
Learning: The CreateSignerObserverBTC function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/orchestrator.go:192-217
Timestamp: 2024-07-04T23:46:38.428Z
Learning: The GetUpdatedSigner method in zetaclient/orchestrator/orchestrator.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go and zetaclient/orchestrator/orchestrator_test.go.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:116-181
Timestamp: 2024-07-05T00:02:36.493Z
Learning: The CreateSignerObserverEVM function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: gartnera
PR: #3632
File: zetaclient/chains/solana/signer/signer.go:304-304
Timestamp: 2025-03-04T22:39:58.395Z
Learning: The Solana signer implementation in zetaclient/chains/solana/signer/signer.go has limited test coverage, particularly for the transaction broadcasting logic with fallback scenarios. Adding this coverage has been acknowledged as a potential future improvement outside the scope of immediate fixes.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/orchestrator.go:222-237
Timestamp: 2024-07-04T23:47:56.072Z
Learning: The GetUpdatedChainObserver method in the Orchestrator class is covered by unit tests in zetaclient/orchestrator/orchestrator_test.go and zetaclient/orchestrator/chain_activate_test.go.
Learnt from: ws4charlie
PR: #4053
File: e2e/e2etests/test_bitcoin_std_deposit.go:42-42
Timestamp: 2025-07-28T18:08:13.883Z
Learning: In Bitcoin deposit E2E tests for the ZetaChain project, DepositBTCWithAmount is preferred over DepositBTCWithExactAmount because depositing exact amounts to a ZEVM receiver is complex. The tests use rough amounts and then calculate the actual received amount from the raw Bitcoin transaction to verify balance changes, making the tests more robust and less flaky.
Learnt from: ws4charlie
PR: #2907
File: zetaclient/chains/bitcoin/observer/outbound_test.go:81-82
Timestamp: 2024-09-23T19:51:43.360Z
Learning: In the mineTxNSetNonceMark function within bitcoin/observer/outbound_test.go, it's acceptable to hardcode the chain ID, as the tests do not require varying chain IDs.
Learnt from: ws4charlie
PR: #2907
File: zetaclient/chains/bitcoin/observer/outbound_test.go:81-82
Timestamp: 2024-10-08T15:34:48.217Z
Learning: In the mineTxNSetNonceMark function within bitcoin/observer/outbound_test.go, it's acceptable to hardcode the chain ID, as the tests do not require varying chain IDs.
Learnt from: ws4charlie
PR: #2870
File: zetaclient/orchestrator/orchestrator.go:413-413
Timestamp: 2024-09-13T22:29:09.747Z
Learning: When a method is renamed (e.g., IsUTXO() to IsBitcoin()), and existing tests cover the affected code paths, do not request additional tests for the renamed methods.
Learnt from: ws4charlie
PR: #2987
File: testutil/sample/memo.go:0-0
Timestamp: 2024-10-10T18:54:33.554Z
Learning: In the testutil/sample/memo.go file, unchecked type assertions in the ABIPack function are acceptable because it is designed for unit tests and simplicity.
Learnt from: gartnera
PR: #3105
File: e2e/runner/setup_bitcoin.go:51-69
Timestamp: 2024-11-06T21:10:14.301Z
Learning: In test code (e2e/runner/setup_bitcoin.go), adding security measures for private key handling in the GetBtcAddress method is not required.
e2e/e2etests/test_burn_fungible_module_asset.go (12)
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:184-247
Timestamp: 2024-07-05T00:02:31.446Z
Learning: The CreateSignerObserverBTC function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: ws4charlie
PR: #4053
File: e2e/e2etests/test_bitcoin_std_deposit.go:42-42
Timestamp: 2025-07-28T18:08:13.883Z
Learning: In Bitcoin deposit E2E tests for the ZetaChain project, DepositBTCWithAmount is preferred over DepositBTCWithExactAmount because depositing exact amounts to a ZEVM receiver is complex. The tests use rough amounts and then calculate the actual received amount from the raw Bitcoin transaction to verify balance changes, making the tests more robust and less flaky.
Learnt from: gartnera
PR: #3079
File: e2e/e2etests/test_pause_erc20_custody.go:65-68
Timestamp: 2024-11-01T17:07:59.584Z
Learning: In the file e2e/e2etests/test_pause_erc20_custody.go, prefer verbosity and avoid extracting common event handling logic into helper functions to enhance readability and ease future refactoring.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:116-181
Timestamp: 2024-07-05T00:02:36.493Z
Learning: The CreateSignerObserverEVM function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: gartnera
PR: #3071
File: e2e/e2etests/test_stress_eth_withdraw.go:0-0
Timestamp: 2024-10-31T16:21:47.362Z
Learning: In e2e/e2etests/test_stress_eth_withdraw.go, when handling the error returned by stats.Describe in the TestStressEtherWithdraw function, log the error instead of failing the test.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/orchestrator.go:192-217
Timestamp: 2024-07-04T23:46:38.428Z
Learning: The GetUpdatedSigner method in zetaclient/orchestrator/orchestrator.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go and zetaclient/orchestrator/orchestrator_test.go.
Learnt from: gartnera
PR: #3632
File: zetaclient/chains/solana/signer/signer.go:304-304
Timestamp: 2025-03-04T22:39:58.395Z
Learning: The Solana signer implementation in zetaclient/chains/solana/signer/signer.go has limited test coverage, particularly for the transaction broadcasting logic with fallback scenarios. Adding this coverage has been acknowledged as a potential future improvement outside the scope of immediate fixes.
Learnt from: gartnera
PR: #3071
File: e2e/e2etests/test_stress_eth_withdraw.go:41-42
Timestamp: 2024-10-31T16:23:17.250Z
Learning: In e2e/e2etests/test_stress_eth_withdraw.go, since some goroutines may fail, we should use a mutex to append durations of successful withdrawals for accurate latency reporting.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/orchestrator.go:222-237
Timestamp: 2024-07-04T23:47:56.072Z
Learning: The GetUpdatedChainObserver method in the Orchestrator class is covered by unit tests in zetaclient/orchestrator/orchestrator_test.go and zetaclient/orchestrator/chain_activate_test.go.
Learnt from: gartnera
PR: #2817
File: contrib/rpcimportable/go.mod:5-6
Timestamp: 2024-09-24T18:45:32.028Z
Learning: In the contrib/rpcimportable test, the go.mod file should be empty when committed, and the go.sum file should not be committed, as committing go.sum causes the test to fail.
Learnt from: ws4charlie
PR: #2899
File: zetaclient/chains/bitcoin/observer/inbound.go:366-371
Timestamp: 2024-09-19T18:28:58.296Z
Learning: The bitcoin.CalcDepositorFee function is covered by live tests.
Learnt from: lumtis
PR: #2459
File: e2e/config/config.go:285-293
Timestamp: 2024-07-11T13:10:39.153Z
Learning: Tests should not be suggested in the e2e package for the zeta-chain/node repository.
x/fungible/keeper/msg_server_burn_fungible_module_asset_test.go (9)
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:184-247
Timestamp: 2024-07-05T00:02:31.446Z
Learning: The CreateSignerObserverBTC function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:116-181
Timestamp: 2024-07-05T00:02:36.493Z
Learning: The CreateSignerObserverEVM function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: gartnera
PR: #3079
File: e2e/e2etests/test_pause_erc20_custody.go:65-68
Timestamp: 2024-11-01T17:07:59.584Z
Learning: In the file e2e/e2etests/test_pause_erc20_custody.go, prefer verbosity and avoid extracting common event handling logic into helper functions to enhance readability and ease future refactoring.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/orchestrator.go:192-217
Timestamp: 2024-07-04T23:46:38.428Z
Learning: The GetUpdatedSigner method in zetaclient/orchestrator/orchestrator.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go and zetaclient/orchestrator/orchestrator_test.go.
Learnt from: gartnera
PR: #3632
File: zetaclient/chains/solana/signer/signer.go:304-304
Timestamp: 2025-03-04T22:39:58.395Z
Learning: The Solana signer implementation in zetaclient/chains/solana/signer/signer.go has limited test coverage, particularly for the transaction broadcasting logic with fallback scenarios. Adding this coverage has been acknowledged as a potential future improvement outside the scope of immediate fixes.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/orchestrator.go:222-237
Timestamp: 2024-07-04T23:47:56.072Z
Learning: The GetUpdatedChainObserver method in the Orchestrator class is covered by unit tests in zetaclient/orchestrator/orchestrator_test.go and zetaclient/orchestrator/chain_activate_test.go.
Learnt from: gartnera
PR: #2817
File: contrib/rpcimportable/go.mod:5-6
Timestamp: 2024-09-24T18:45:32.028Z
Learning: In the contrib/rpcimportable test, the go.mod file should be empty when committed, and the go.sum file should not be committed, as committing go.sum causes the test to fail.
Learnt from: fbac
PR: #2979
File: x/fungible/keeper/zrc20_unlock_token.go:69-72
Timestamp: 2024-10-08T14:57:52.954Z
Learning: In x/fungible/keeper/zrc20_unlock_token.go, when performing type assertions like transferred, ok := ret[0].(bool), using the ok check is sufficient to prevent panics, and additional type handling is not required.
Learnt from: ws4charlie
PR: #4053
File: e2e/e2etests/test_bitcoin_std_deposit.go:42-42
Timestamp: 2025-07-28T18:08:13.883Z
Learning: In Bitcoin deposit E2E tests for the ZetaChain project, DepositBTCWithAmount is preferred over DepositBTCWithExactAmount because depositing exact amounts to a ZEVM receiver is complex. The tests use rough amounts and then calculate the actual received amount from the raw Bitcoin transaction to verify balance changes, making the tests more robust and less flaky.
cmd/zetae2e/local/local.go (12)
Learnt from: gartnera
PR: #3079
File: e2e/e2etests/test_pause_erc20_custody.go:65-68
Timestamp: 2024-11-01T17:07:59.584Z
Learning: In the file e2e/e2etests/test_pause_erc20_custody.go, prefer verbosity and avoid extracting common event handling logic into helper functions to enhance readability and ease future refactoring.
Learnt from: gartnera
PR: #3071
File: e2e/e2etests/test_stress_eth_withdraw.go:0-0
Timestamp: 2024-10-31T16:21:47.362Z
Learning: In e2e/e2etests/test_stress_eth_withdraw.go, when handling the error returned by stats.Describe in the TestStressEtherWithdraw function, log the error instead of failing the test.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:116-181
Timestamp: 2024-07-05T00:02:36.493Z
Learning: The CreateSignerObserverEVM function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: gartnera
PR: #2817
File: contrib/rpcimportable/go.mod:5-6
Timestamp: 2024-09-24T18:45:32.028Z
Learning: In the contrib/rpcimportable test, the go.mod file should be empty when committed, and the go.sum file should not be committed, as committing go.sum causes the test to fail.
Learnt from: ws4charlie
PR: #2870
File: zetaclient/orchestrator/orchestrator.go:413-413
Timestamp: 2024-09-13T22:29:09.747Z
Learning: When a method is renamed (e.g., IsUTXO() to IsBitcoin()), and existing tests cover the affected code paths, do not request additional tests for the renamed methods.
Learnt from: gartnera
PR: #3105
File: e2e/runner/setup_bitcoin.go:51-69
Timestamp: 2024-11-06T21:10:14.301Z
Learning: In test code (e2e/runner/setup_bitcoin.go), adding security measures for private key handling in the GetBtcAddress method is not required.
Learnt from: ws4charlie
PR: #2411
File: zetaclient/orchestrator/chain_activate.go:184-247
Timestamp: 2024-07-05T00:02:31.446Z
Learning: The CreateSignerObserverBTC function in zetaclient/orchestrator/chain_activate.go is covered by unit tests in zetaclient/orchestrator/chain_activate_test.go.
Learnt from: ws4charlie
PR: #2870
File: zetaclient/orchestrator/bootstrap.go:142-142
Timestamp: 2024-09-13T22:51:02.192Z
Learning: When code changes involve only renaming without functional changes, and static analysis tools flag missing test coverage, acknowledge that existing tests likely already cover the functionality, and additional tests may not be necessary.
Learnt from: ws4charlie
PR: #2987
File: testutil/sample/memo.go:0-0
Timestamp: 2024-10-10T18:54:33.554Z
Learning: In the testutil/sample/memo.go file, unchecked type assertions in the ABIPack function are acceptable because it is designed for unit tests and simplicity.
Learnt from: ws4charlie
PR: #2907
File: zetaclient/chains/bitcoin/observer/outbound_test.go:81-82
Timestamp: 2024-09-23T19:51:43.360Z
Learning: In the mineTxNSetNonceMark function within bitcoin/observer/outbound_test.go, it's acceptable to hardcode the chain ID, as the tests do not require varying chain IDs.
Learnt from: ws4charlie
PR: #2907
File: zetaclient/chains/bitcoin/observer/outbound_test.go:81-82
Timestamp: 2024-10-08T15:34:48.217Z
Learning: In the mineTxNSetNonceMark function within bitcoin/observer/outbound_test.go, it's acceptable to hardcode the chain ID, as the tests do not require varying chain IDs.
Learnt from: ws4charlie
PR: #4053
File: e2e/e2etests/test_bitcoin_std_deposit.go:42-42
Timestamp: 2025-07-28T18:08:13.883Z
Learning: In Bitcoin deposit E2E tests for the ZetaChain project, DepositBTCWithAmount is preferred over DepositBTCWithExactAmount because depositing exact amounts to a ZEVM receiver is complex. The tests use rough amounts and then calculate the actual received amount from the raw Bitcoin transaction to verify balance changes, making the tests more robust and less flaky.
testutil/keeper/mocks/fungible/bank.go (3)
Learnt from: ws4charlie
PR: #2870
File: zetaclient/orchestrator/orchestrator.go:413-413
Timestamp: 2024-09-13T22:29:09.747Z
Learning: When a method is renamed (e.g., IsUTXO() to IsBitcoin()), and existing tests cover the affected code paths, do not request additional tests for the renamed methods.
Learnt from: fbac
PR: #2979
File: x/fungible/keeper/zrc20_unlock_token.go:69-72
Timestamp: 2024-10-08T14:57:52.954Z
Learning: In x/fungible/keeper/zrc20_unlock_token.go, when performing type assertions like transferred, ok := ret[0].(bool), using the ok check is sufficient to prevent panics, and additional type handling is not required.
Learnt from: ws4charlie
PR: #4053
File: e2e/e2etests/test_bitcoin_std_deposit.go:42-42
Timestamp: 2025-07-28T18:08:13.883Z
Learning: In Bitcoin deposit E2E tests for the ZetaChain project, DepositBTCWithAmount is preferred over DepositBTCWithExactAmount because depositing exact amounts to a ZEVM receiver is complex. The tests use rough amounts and then calculate the actual received amount from the raw Bitcoin transaction to verify balance changes, making the tests more robust and less flaky.
x/authority/migrations/v4/migrate_test.go (1)
Learnt from: ws4charlie
PR: #2987
File: testutil/sample/memo.go:0-0
Timestamp: 2024-10-10T18:54:33.554Z
Learning: In the testutil/sample/memo.go file, unchecked type assertions in the ABIPack function are acceptable because it is designed for unit tests and simplicity.
typescript/zetachain/zetacore/fungible/tx_pb.ts (1)
Learnt from: ws4charlie
PR: #4007
File: e2e/contracts/sui/example-authenticated-call/sources/example.move:69-71
Timestamp: 2025-07-14T21:05:38.534Z
Learning: In Sui Move test contracts for the ZetaChain project, it's acceptable to define generic structs with phantom type parameters for testing type argument functionality without fully implementing their usage in entry functions. The goal is to validate the type system behavior, not to provide complete operational functionality.
proto/zetachain/zetacore/fungible/tx.proto (2)
Learnt from: ws4charlie
PR: #3793
File: pkg/contracts/sui/withdraw_and_call_ptb.go:111-118
Timestamp: 2025-04-22T15:32:20.706Z
Learning: The constant moduleName is defined in pkg/contracts/sui/gateway.go with the value "gateway" and is used across multiple files in the sui package.
Learnt from: ws4charlie
PR: #3793
File: pkg/contracts/sui/withdraw_and_call_ptb.go:111-118
Timestamp: 2025-04-22T15:32:20.706Z
Learning: The constant moduleName is defined in pkg/contracts/sui/gateway.go with the value "gateway" and is used across multiple files in the sui package.
🧬 Code Graph Analysis (11)
x/authority/types/authorization_list_test.go (1)
typescript/zetachain/zetacore/fungible/tx_pb.ts (1)
MsgBurnFungibleModuleAsset(497-507)
x/fungible/types/codec.go (1)
typescript/zetachain/zetacore/fungible/tx_pb.ts (1)
MsgBurnFungibleModuleAsset(497-507)
x/authority/keeper/migrator.go (2)
x/authority/migrations/v4/migrate.go (1)
MigrateStore(15-45)x/authority/migrations/v3/migrate.go (1)
MigrateStore(15-65)
x/fungible/types/errors.go (1)
x/fungible/types/keys.go (1)
ModuleName(10-10)
e2e/txserver/bank.go (3)
e2e/txserver/zeta_tx_server.go (1)
ZetaTxServer(81-91)e2e/utils/zetacore.go (1)
AdminPolicyName(27-27)cmd/zetacored/config/config.go (1)
BaseDenom(11-11)
x/fungible/keeper/msg_server_burn_fungible_module_asset_test.go (8)
testutil/keeper/fungible.go (4)
FungibleKeeperWithMocks(81-189)FungibleMockOptions(35-41)GetFungibleAuthorityMock(204-208)GetFungibleBankMock(216-220)testutil/sample/crypto.go (2)
AccAddress(217-221)EthAddress(89-91)testutil/keeper/authority.go (2)
MockGetChainListEmpty(91-93)MockCheckAuthorization(81-83)x/fungible/types/message_burn_fungible_module_asset.go (1)
NewMsgBurnFungibleModuleAsset(14-22)x/fungible/types/errors.go (4)
ErrZeroBalance(54-54)ErrInvalidAddress(17-17)ErrForeignCoinNotFound(25-25)ErrFailedToBurn(55-55)x/authority/types/errors.go (1)
ErrUnauthorized(6-6)cmd/zetacored/config/config.go (1)
BaseDenom(11-11)pkg/constant/constant.go (1)
EVMZeroAddress(35-35)
cmd/zetae2e/local/local.go (1)
e2e/e2etests/e2etests.go (1)
TestBurnFungibleModuleAssetName(209-209)
testutil/keeper/mocks/fungible/bank.go (1)
testutil/keeper/mocks/mocks.go (1)
FungibleBankKeeper(66-68)
x/authority/migrations/v4/migrate.go (1)
x/authority/types/authorization_list.go (1)
DefaultAuthorizationsList(65-96)
typescript/zetachain/zetacore/fungible/tx_pb.ts (1)
typescript/zetachain/zetacore/pkg/coin/coin_pb.ts (1)
file_zetachain_zetacore_pkg_coin_coin(12-13)
x/fungible/types/message_burn_fungible_module_asset.go (3)
typescript/zetachain/zetacore/fungible/tx_pb.ts (2)
Msg(534-632)MsgBurnFungibleModuleAsset(497-507)testutil/sample/crypto.go (1)
AccAddress(217-221)x/fungible/types/codec.go (1)
ModuleCdc(46-46)
🪛 markdownlint-cli2 (0.17.2)
docs/spec/generated.md
734-734: Hard tabs
Column: 1
(MD010, no-hard-tabs)
735-735: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🪛 GitHub Check: lint
x/fungible/keeper/msg_server_burn_fungible_module_asset.go
[failure] 91-91:
unnecessary trailing newline (whitespace)
🪛 GitHub Actions: Linters and SAST
x/fungible/keeper/msg_server_burn_fungible_module_asset.go
[error] 91-91: golangci-lint: unnecessary trailing newline (whitespace)
🔇 Additional comments (44)
changelog.md (1)
11-11: Entry looks correct & consistentThe new feature entry adheres to the existing changelog style (link format, ordering, and wording). No adjustments required.
x/authority/types/authorization_list_test.go (1)
440-440: LGTM! Test updated to include new burn message.The addition of
MsgBurnFungibleModuleAssetto theAdminPolicyMessageListcorrectly aligns the test with the new burn functionality and maintains consistency with the authorization framework.x/authority/types/authorization_list.go (1)
47-47: Appropriate authorization level for burn operations.The placement of
MsgBurnFungibleModuleAssetin theAdminPolicyMessagesis correct, ensuring that only admin policy addresses can execute burn operations. This provides the necessary security control for destructive asset operations.cmd/zetae2e/local/local.go (1)
403-403: Integration with admin test suite looks good.The addition of
TestBurnFungibleModuleAssetNameto the admin test routine appropriately includes the new burn functionality in E2E testing and maintains consistency with the admin-only authorization model.x/authority/keeper/migrator.go (2)
7-7: Import follows established pattern.The import of the v4 migration package is consistent with the existing v3 import pattern and necessary for the new migration functionality.
27-30: Migration method implementation is consistent.The
Migrate3to4method follows the established pattern of previous migration methods, properly delegating to the v4 migration logic and maintaining consistency in the migration framework.x/fungible/types/codec.go (2)
22-22: Amino codec registration follows established pattern.The registration of
MsgBurnFungibleModuleAssetin the legacy Amino codec is consistent with other message types and uses the appropriate naming convention.
38-38: Protobuf interface registration completed correctly.The addition of
MsgBurnFungibleModuleAssetto the protobuf interface registry ensures proper message type recognition in the Cosmos SDK message handling pipeline.docs/spec/generated.md (1)
727-738: LGTM: Documentation accurately reflects the new burn functionality.The documentation for
MsgBurnFungibleModuleAssetis clear and follows the established pattern. It correctly describes the dual functionality of burning ZRC20 tokens or native ZETA when using the zero address.x/fungible/types/errors.go (1)
54-55: LGTM: Error definitions follow established conventions.The new error variables
ErrZeroBalanceandErrFailedToBurnare properly structured with sequential error codes and descriptive messages. They align with the existing error handling patterns in the module.x/authority/module.go (2)
23-23: LGTM: Consensus version properly incremented.The consensus version increment to 4 is appropriate for the addition of new authorization functionality.
131-133: LGTM: Migration registration follows established pattern.The migration registration for version 3 to 4 is properly implemented, consistent with the existing migration setup, and appropriately uses panic for initialization failures.
proto/zetachain/zetacore/fungible/tx.proto (2)
32-34: LGTM: RPC method properly defined.The
BurnFungibleModuleAssetRPC method follows the established pattern and correctly maps the request/response message types.
154-160: LGTM: Message definitions are well-structured.The
MsgBurnFungibleModuleAssetmessage properly includes the signer annotation and necessary fields. The empty response message is appropriate for burn operations. The design follows established protobuf conventions in the codebase.x/fungible/types/expected_keepers.go (2)
35-35: LGTM: BurnCoins method properly defined.The
BurnCoinsmethod signature follows the standard Cosmos SDK bank keeper interface pattern and is essential for the burn functionality.
38-38: LGTM: SpendableCoin method appropriately added.The
SpendableCoinmethod provides necessary functionality to query spendable amounts for specific denominations, which is useful for balance validation before burn operations.e2e/e2etests/e2etests.go (1)
209-209: LGTM - Well-structured test registrationThe new E2E test registration follows established conventions perfectly, including proper constant naming, descriptive text, and appropriate minimum version constraint for the v33.0.0 release.
Also applies to: 1544-1550
x/authority/migrations/v4/migrate_test.go (1)
13-68: Excellent test coverage for migration logicThe test cases comprehensively cover all migration scenarios including successful updates, default initialization, and error handling for invalid data. The arrange/act/assert structure enhances readability and maintainability.
x/fungible/types/message_burn_fungible_module_asset_test.go (1)
14-114: Comprehensive message validation testingThe test suite thoroughly validates all essential methods of the
MsgBurnFungibleModuleAssetmessage type, including proper error handling for invalid addresses, panic testing for malformed signers, and verification of message metadata. This ensures robust validation at the message layer.typescript/zetachain/zetacore/fungible/tx_pb.ts (4)
17-17: LGTM - Auto-generated protobuf descriptor updateThe file descriptor has been correctly updated to include the new burn message types and service method.
494-507: LGTM - Well-structured message type definitionThe
MsgBurnFungibleModuleAssetmessage type follows the established patterns with appropriate field types for the burn functionality.
509-527: LGTM - Correct schema and response definitionsThe message schema and empty response type follow the established patterns for transaction messages.
623-630: LGTM - Properly defined RPC methodThe
burnFungibleModuleAssetRPC method is correctly configured with appropriate input/output schemas and unary method kind.e2e/e2etests/test_burn_fungible_module_asset.go (1)
17-20: LGTM - Well-organized test structureThe main test function properly delegates to specialized sub-tests for ZRC20 and ZETA scenarios, maintaining clear separation of concerns.
testutil/keeper/mocks/fungible/bank.go (2)
18-34: LGTM - Standard mockery implementationThe
BurnCoinsmock method correctly follows the established mockery patterns with proper parameter handling and type assertions.
90-106: LGTM - Consistent mock implementationThe
SpendableCoinmock method maintains consistency with other mock methods and correctly handles the expected return type.x/fungible/keeper/msg_server_burn_fungible_module_asset.go (3)
17-29: LGTM - Secure authorization implementationThe authorization check correctly validates permissions using the authority keeper and follows security best practices with proper error wrapping.
31-47: LGTM - Robust native token burn implementationThe native ZETA burn logic is well-structured with proper balance validation and secure coin burning through the bank keeper.
48-91: LGTM - Comprehensive ZRC20 burn implementationThe ZRC20 burn logic includes thorough validation, proper balance checking, and secure token burning with comprehensive error handling.
x/authority/migrations/v4/migrate.go (3)
9-17: LGTM - Well-designed migration interfaceThe migration function signature and keeper interface abstraction follow established patterns and provide clear documentation of the migration purpose.
19-31: LGTM - Correct authorization setupThe migration properly handles both default and existing authorization lists, and the new burn authorization is correctly configured with admin policy restrictions.
33-44: LGTM - Robust migration completionThe migration correctly adds the new authorization, validates the updated list, and handles errors appropriately before persisting the changes.
x/fungible/keeper/msg_server_burn_fungible_module_asset_test.go (7)
21-73: Excellent test coverage for the happy path scenario.This test comprehensively covers the successful burning of ZRC20 tokens, including:
- Proper setup with system contracts and ZRC20 deployment
- Balance verification before and after burn
- Testing subsequent zero balance error condition
The test structure follows best practices with clear setup, execution, and verification phases.
75-91: Well-focused authorization test.This test appropriately isolates and validates the authorization mechanism, ensuring unauthorized users cannot burn fungible module assets.
93-109: Proper input validation testing.This test correctly validates that invalid ZRC20 addresses are rejected with appropriate error handling.
111-127: Good coverage of foreign coin lookup failure.This test appropriately validates the scenario where a valid Ethereum address doesn't correspond to a registered foreign coin, ensuring proper error handling.
129-156: Comprehensive native ZETA burning test.This test effectively validates the special case of burning native ZETA tokens using the zero address, with proper bank keeper mocking for balance queries and burn operations.
158-182: Appropriate zero balance validation for ZETA.This test correctly handles the edge case where native ZETA balance is zero, ensuring proper error handling without attempting unnecessary burn operations.
184-212: Good coverage of burn operation failure.This test appropriately validates error handling when the underlying bank keeper fails to burn coins, ensuring proper error propagation and domain-specific error wrapping.
x/fungible/types/message_burn_fungible_module_asset.go (5)
1-8: Clean and appropriate imports.All imports are necessary and properly organized for the message type functionality.
10-12: Proper constant definition and interface compliance.The message type constant follows naming conventions and the interface compliance check ensures the struct implements sdk.Msg correctly.
14-22: Standard message constructor implementation.The constructor follows Cosmos SDK conventions with appropriate parameter handling and struct initialization.
24-38: Standard SDK message interface methods.The Route(), Type(), and GetSigners() methods follow Cosmos SDK conventions. The panic in GetSigners() is acceptable as address validation should occur in ValidateBasic() before this method is called.
40-43: Correct signing bytes implementation.The GetSignBytes() method properly serializes the message using the module codec and ensures deterministic JSON ordering.
4 participants
Description
Closes Add an admin message that can "flush" all funds on the fungible/protocol address
Support any ZRC20 and ZETA burn by using the zero address
Summary by CodeRabbit
New Features
Bug Fixes
Tests
Chores