WIP: crosschain astroport lper - #3
Conversation
Update manager dependency
WalkthroughThis pull request removes an obsolete Neutron-Gaia bridge configuration and introduces new configurations for Neutron-Juno and Neutron-Terra bridges. It also extends the chain and contract configurations by adding sections for Juno and Terra with specific parameters. A new crosschain Astroport liquidity provider program is introduced, which includes its package metadata, documentation, configuration parameters, and source code for building and deploying the program configuration. Changes
Sequence Diagram(s)sequenceDiagram
participant M as main.rs
participant PB as program_builder.rs
participant DL as deployer_lib
M->>PB: Call program_builder(params)
PB-->>M: Return program configuration
M->>DL: Pass configuration to deployer_lib::main
DL-->>M: Return deployment result
Suggested reviewers
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
programs/crosschain_astroport_lper/README.md (1)
9-9: Improve grammar and clarity on program parameters description.Line 9 contains grammatical issues flagged by static analysis. The phrase "will injected" should be corrected to "will be injected" and the latter part of the sentence can be made clearer by using "named" instead of "name with." Consider rephrasing the sentence to improve clarity and readability.
- - `program_params/` - Program parameters that will injected into the program builder function, each environment will have its own program parameters toml file, name with the environment name, Example: `program_params/local.toml` or `program_params/mainnet.toml` + - `program_params/` - Program parameters that will be injected into the program builder function. Each environment should have its own program parameters TOML file, named after the environment (e.g., `program_params/local.toml` or `program_params/mainnet.toml`).🧰 Tools
🪛 LanguageTool
[grammar] ~9-~9: The modal verb ‘will’ requires the verb’s base form.
Context: ...params/` - Program parameters that will injected into the program builder function, each...(MD_BASEFORM)
[uncategorized] ~9-~9: This verb may not be in the correct form. Consider using a different form for this context.
Context: ...e its own program parameters toml file, name with the environment name, Example: `pr...(AI_EN_LECTOR_REPLACEMENT_VERB_FORM)
programs/crosschain_astroport_lper/src/program_builder.rs (3)
136-137: Implement the TODO for subroutine.There is a
TODOcomment to “add subroutine for transfer.” This functionality appears central to the cross-chain flow. Implementing this early will ensure the transfer logic is integrated and testable before finalizing the rest of the builder.
167-193: Validate permissioned withdrawer logic.The “withdraw_liquidity” authorization leverages a permissioned address. Confirm that the
permissioned_withdrawerparameter matches the intended address and that no additional checks are needed to handle partial or malformed inputs.
195-196: Consider unit tests and integration tests.Currently, the builder logic forms a non-trivial configuration. Introduce unit tests or integration tests in your Rust codebase to validate the correctness of the
ProgramConfigproduced. This helps prevent misconfiguration issues in production.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (10)
manager_configs/mainnet/bridges/neutron_gaia.toml(0 hunks)manager_configs/mainnet/bridges/neutron_juno.toml(1 hunks)manager_configs/mainnet/chains.toml(1 hunks)manager_configs/mainnet/contracts.toml(1 hunks)programs/crosschain_astroport_lper/Cargo.toml(1 hunks)programs/crosschain_astroport_lper/README.md(1 hunks)programs/crosschain_astroport_lper/output/README.md(1 hunks)programs/crosschain_astroport_lper/program_params/mainnet.toml(1 hunks)programs/crosschain_astroport_lper/src/main.rs(1 hunks)programs/crosschain_astroport_lper/src/program_builder.rs(1 hunks)
💤 Files with no reviewable changes (1)
- manager_configs/mainnet/bridges/neutron_gaia.toml
✅ Files skipped from review due to trivial changes (2)
- programs/crosschain_astroport_lper/output/README.md
- programs/crosschain_astroport_lper/Cargo.toml
🧰 Additional context used
🪛 LanguageTool
programs/crosschain_astroport_lper/README.md
[grammar] ~9-~9: The modal verb ‘will’ requires the verb’s base form.
Context: ...params/` - Program parameters that will injected into the program builder function, each...
(MD_BASEFORM)
[uncategorized] ~9-~9: This verb may not be in the correct form. Consider using a different form for this context.
Context: ...e its own program parameters toml file, name with the environment name, Example: `pr...
(AI_EN_LECTOR_REPLACEMENT_VERB_FORM)
🔇 Additional comments (8)
programs/crosschain_astroport_lper/src/main.rs (1)
1-10: Well-structured entry point for the crosschain Astroport LP program.The main.rs file provides a clean, standard entry point for the program, leveraging Tokio for async runtime support. The code properly modularizes the program builder logic and follows Rust conventions.
A few observations:
- Correctly uses tokio's main macro for async support
- Properly handles error types with the Box pattern
- Leverages the deployer_lib for execution
manager_configs/mainnet/chains.toml (1)
12-19: Juno chain configuration looks good.The added Juno chain configuration contains all the necessary parameters matching the structure of the existing Neutron configuration. The endpoints, prefixes, and gas settings appear to be properly configured for the Juno network.
One note: I see both chains use the same coin_type "118" which is the ATOM coin type, which is expected for Cosmos ecosystem chains.
manager_configs/mainnet/bridges/neutron_juno.toml (2)
1-6: Neutron side of the bridge configuration looks good.The Neutron bridge configuration includes the necessary contract addresses and connection parameters for the Polytone bridge. All required fields are present (voice_addr, note_addr, other_note_port, connection_id, and channel_id).
Verify that these contract addresses and IDs match the expected values for the mainnet environment.
7-12: Juno side of the bridge configuration looks good.The Juno bridge configuration contains all the expected fields matching the structure of the Neutron side. The configuration correctly references the counterparty contracts in the port identifiers.
Note that the bridge configuration is comprehensive with bidirectional setup between both chains.
programs/crosschain_astroport_lper/program_params/mainnet.toml (1)
1-8: Verify IBC channel identifiers and token denoms for accuracy.The configuration parameters include owner addresses, pool address, token denominations, and IBC channel IDs. While the structure looks correct, it's important to verify:
- The IBC channel IDs (
juno_gaia_ibc_channel_idandgaia_neutron_ibc_channel_id) match the production channels- The IBC token denominations are correct for both chains
- The owner and permissioned_withdrawer addresses have the proper permissions
Also, I notice both
atom_on_neutronandatom_on_junohave identical IBC denominations which seems unusual since IBC denoms should differ between chains. Verify this is intentional.programs/crosschain_astroport_lper/src/program_builder.rs (2)
21-35: Check missing parameter error handling.You’re retrieving parameters (e.g.,
owner,pool_addr) usingparams.get(...)without validating whether they exist. If these parameters are missing or empty, the code may panic at runtime. Consider adding error-handling logic or default values to avoid production failures.
140-165: Verify the contract address used for providing liquidity.The “provide_liquidity” subroutine references the
astroport_withdrawer_librarycontract when calling the “provide_double_sided_liquidity” function (see line 145). Ensure this is intentional. Typically, a deposit action would involve theastroport_lperlibrary, not the withdrawer.manager_configs/mainnet/contracts.toml (1)
6-6: Confirm newly added code IDs.The newly introduced code IDs such as
polytone_proxy = 3261(Neutron) and those under the[contracts.code_ids.juno]section should match the actual on-chain deployments. Additionally, verify whethervalence_drop_liquid_unstaker = 3255is correct for your environment, since changing code IDs without re-deploying the contracts can cause mismatches.Also applies to: 14-14, 18-25
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
programs/crosschain_astroport_lper/src/program_builder.rs (1)
74-82: Consider specifying a non-empty memo for IBC transfersThe memo field is currently empty. For cross-chain IBC transfers, memos are sometimes used for routing or ensuring compatibility with specific middleware. Verify if an empty memo is appropriate for this use case.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite
📒 Files selected for processing (4)
.gitignore(1 hunks)manager_configs/mainnet/contracts.toml(1 hunks)programs/crosschain_astroport_lper/program_params/mainnet.toml(1 hunks)programs/crosschain_astroport_lper/src/program_builder.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- programs/crosschain_astroport_lper/program_params/mainnet.toml
🔇 Additional comments (7)
.gitignore (1)
34-34: Git configuration updated to ignore scratch filesThe addition of
*scratch*to the gitignore file is appropriate for excluding temporary or scratch files/directories used during development, which helps keep the repository clean from work-in-progress files.programs/crosschain_astroport_lper/src/program_builder.rs (4)
211-223: Review unlimited withdrawal permissionsThe withdrawal authorization is set to
WithoutCallLimitfor the permissioned withdrawer. Confirm that allowing unlimited withdrawals is the intended behavior, as this grants significant control to the specified address.
1-226: Overall program structure appears well-designedThe program builder effectively sets up cross-chain liquidity provision between Juno and Neutron chains. The structure follows a logical flow:
- Defining domains and accounts
- Setting up packet forwarding for cross-chain transfers
- Configuring libraries for IBC transfer, LP provision, and withdrawal
- Creating links between components
- Setting up appropriate authorizations
The implementation correctly handles the necessary components for a cross-chain Astroport liquidity provider.
87-89:Details
❓ Verification inconclusive
Confirm compatibility with "concentrated" pool type
The pool type is set to a Custom type "concentrated". Verify that this custom type is compatible with the Astroport implementation being used.
🏁 Script executed:
#!/bin/bash # Look for other uses of the "concentrated" pool type rg -A 3 -B 3 "Custom\\(\"concentrated\"" --type rustLength of output: 694
Compatibility Check on "concentrated" Pool Type
- The grep search confirms that the custom "concentrated" pool type is only instantiated in
programs/crosschain_astroport_lper/src/program_builder.rs.- Please verify that the underlying Astroport implementation correctly supports the custom pool type value "concentrated" as used here.
- Consider ensuring through integration tests or further review of the
valence_astroport_utils::astroport_native_lp_tokenmodule that no unexpected behavior occurs when using this custom type.
58-63:Details
❓ Verification inconclusive
Verify the intention of using "invalid-pfm" as the hop chain receiver address
The comment indicates this is "necessary so entire transaction is reverted," but using an intentionally invalid address as a failure mechanism seems unusual. Consider if there's a more explicit way to handle errors or if this is indeed the recommended approach for Packet Forward Middleware.
🏁 Script executed:
#!/bin/bash # Search for other similar PFM configurations to verify pattern rg -A 5 -B 5 "hop_chain_receiver_address.*invalid" --type rustLength of output: 1278
Clarify the use of "invalid-pfm" for transaction rollback
- The pattern where
"invalid-pfm"is used as thehop_chain_receiver_addressappears only in this section ofprograms/crosschain_astroport_lper/src/program_builder.rs(lines 58–63).- The current design uses this hard-coded invalid address as a signal to revert the entire transaction. While this approach is intentional, it’s unconventional.
- Please verify whether this mechanism is the best option for signaling errors in the Packet Forward Middleware. If so, consider adding an explanatory comment or exploring a more explicit error-handling strategy to improve clarity.
manager_configs/mainnet/contracts.toml (2)
18-25: New Juno chain configuration looks appropriateThe addition of the Juno chain configuration with relevant contract code IDs aligns with the crosschain Astroport LP functionality being implemented. The structure follows the same pattern as the Neutron section.
6-6:Details
❓ Verification inconclusive
Verify polytone_proxy code ID for Neutron
The code ID for polytone_proxy (231) is significantly lower than other Neutron contract code IDs (which are in the 3200+ range). Please confirm this is the correct ID for the Neutron chain.
🏁 Script executed:
#!/bin/bash # Search for other references to the polytone_proxy code ID rg "polytone_proxy.*=.*231" --type tomlLength of output: 119
Attention: Validate Polytone Proxy Code ID for Neutron
The configuration in
manager_configs/mainnet/contracts.tomlsetspolytone_proxyto231, which is confirmed by the repository search. However, since other Neutron contract code IDs are typically above 3200, please review and confirm that231is indeed the correct ID for the Neutron chain. If this value is intentional, no further action is needed; otherwise, please update accordingly.
- Location:
manager_configs/mainnet/contracts.toml(Line 6)- Snippet:
polytone_proxy = 231
fix: use tagged version for template and fix labels
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
programs/crosschain_astroport_lper/program_params/mainnet.toml (2)
1-2: Consider separating owner and permissioned_withdrawer roles.Both addresses are currently identical. For better security practices, consider assigning these roles to different addresses if they serve distinct purposes in your architecture.
1-8: Add descriptive comments to improve configuration maintainability.This configuration file lacks documentation explaining what each parameter is used for. Adding comments would make it easier for future contributors to understand the purpose of each setting.
+# The address that owns the program and has admin privileges owner="neutron14wey3cpz2cxswu9u6gaalz2xxh03xdeyqal9cf" +# The address authorized to withdraw funds from the liquidity position permissioned_withdrawer="neutron14wey3cpz2cxswu9u6gaalz2xxh03xdeyqal9cf" +# IBC denominations for USDC on different chains usdc_on_terra="ibc/2C962DAB9F57FE0921435426AE75196009FAA1981BF86991203C8411F8980FDB" usdc_on_neutron="ibc/B559A80D62249C8AA07A380E2A2BEA6E5CA9A6F079C912C3A9E9B494105E4F81" +# Native NTRN token denomination ntrn_on_neutron="untrn" +# Address of the USDC-NTRN liquidity pool on Astroport usdc_ntrn_pool_addr="neutron18c8qejysp4hgcfuxdpj4wf29mevzwllz5yh8uayjxamwtrs0n9fshq9vtv" +# IBC channel IDs for cross-chain communication terra_noble_ibc_channel_id="channel-253" noble_neutron_ibc_channel_id="channel-18"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite
📒 Files selected for processing (13)
manager_configs/mainnet/bridges/neutron_terra.toml(1 hunks)manager_configs/mainnet/chains.toml(1 hunks)manager_configs/mainnet/contracts-data/neutron.yaml(1 hunks)manager_configs/mainnet/contracts.toml(1 hunks)manager_configs/testnet/bridges/general.toml(1 hunks)manager_configs/testnet/bridges/neutron_juno.toml(1 hunks)manager_configs/testnet/chains.toml(1 hunks)manager_configs/testnet/contracts-data/neutron.yaml(1 hunks)manager_configs/testnet/contracts.toml(1 hunks)manager_configs/testnet/general.toml(1 hunks)programs/crosschain_astroport_lper/program_params/mainnet.toml(1 hunks)programs/crosschain_astroport_lper/src/program_builder.rs(1 hunks)programs/program_template/program_params/testnet.toml(1 hunks)
✅ Files skipped from review due to trivial changes (8)
- manager_configs/testnet/bridges/neutron_juno.toml
- manager_configs/testnet/general.toml
- programs/program_template/program_params/testnet.toml
- manager_configs/testnet/bridges/general.toml
- manager_configs/mainnet/bridges/neutron_terra.toml
- manager_configs/testnet/contracts.toml
- manager_configs/mainnet/contracts-data/neutron.yaml
- manager_configs/testnet/contracts-data/neutron.yaml
🔇 Additional comments (12)
programs/crosschain_astroport_lper/program_params/mainnet.toml (1)
3-8: Verify IBC identifiers and addresses for production use.Since this is a mainnet configuration file, please verify that all IBC identifiers, channel IDs, and contract addresses are correct for the production environment before deployment.
manager_configs/testnet/chains.toml (1)
1-11: Configuration looks good, verify RPC endpoints.The testnet configuration for Neutron looks well structured. Verify that the RPC and gRPC endpoints are current and reliable for the Pion-1 testnet.
For future-proofing, consider adding comments about when these endpoints were last verified or where to check for updated endpoints.
programs/crosschain_astroport_lper/src/program_builder.rs (3)
65-70: Clarify the "invalid-pfm" workaround.The code uses "invalid-pfm" as a hop chain receiver address with a comment stating it's necessary to revert the transaction. This approach needs better documentation or a more robust solution.
Consider:
- Adding more detailed comments explaining why this workaround is necessary
- Exploring if there's a cleaner solution than using an invalid address
- Documenting potential side effects of this approach
82-88: Verify IBC transfer timeout setting.The IBC transfer timeout is set to 10 minutes (600 seconds). Ensure this is appropriate for the expected network conditions between Terra and Neutron.
Too short a timeout could cause transactions to fail during network congestion, while too long might delay error handling unnecessarily.
217-229: Permissioned withdrawal setup looks good.The withdrawal authorization is correctly set up with permissioned access, which aligns with the security model defined in the configuration parameters.
manager_configs/mainnet/chains.toml (4)
13-21: Verify Juno RPC and GRPC endpoints.The configuration uses Polkachu's public endpoints for Juno. These should be verified for reliability and performance for your production workload.
Consider evaluating alternative RPC providers or setting up dedicated infrastructure for production use if these endpoints will handle significant traffic.
23-31: Verify Terra RPC and GRPC endpoints.Similar to the Juno configuration, the Terra configuration uses Polkachu's public endpoints. Verify their reliability for your production workload.
4-4: Configuration structure looks good.The additions of Juno and Terra chain configurations follow the same pattern as the existing Neutron configuration, maintaining consistency in the config file structure.
Also applies to: 12-31
13-31:Details
❓ Verification inconclusive
Gas prices should be validated for each chain.
The gas prices vary significantly between chains (0.0053 for Neutron, 0.075 for Juno, 0.015 for Terra). Ensure these values are current and appropriate to avoid transaction failures or unnecessary costs.
🏁 Script executed:
#!/bin/bash # Check current gas prices on each chain to verify configuration echo "Checking Juno gas prices..." curl -s https://juno-rpc.polkachu.com/abci_info | grep -A 2 "gas_price" echo "Checking Terra gas prices..." curl -s https://terra-rpc.polkachu.com/abci_info | grep -A 2 "gas_price" echo "Checking Neutron gas prices..." curl -s https://rpc-voidara.neutron-1.neutron.org/abci_info | grep -A 2 "gas_price"Length of output: 431
Gas Price Validation: Manual Verification Required
The configuration in
manager_configs/mainnet/chains.tomlstatically sets gas prices for the chains (e.g., Juno at "0.075" and Terra at "0.015"). However, the automated script intended to query these values via the/abci_infoendpoints returned no gas price data. This makes it unclear whether the provided values are current and optimal.Please manually verify the following:
- Confirm whether the configured gas prices for Juno, Terra, and any other chains (e.g., Neutron, which was mentioned in discussions) are still accurate based on the latest chain documentation or alternative API endpoints.
- Double-check that the
/abci_infoendpoint is expected to return gas price data; if not, update the verification method or consult official chain sources.Ensuring these values are correct is essential to prevent transaction failures and avoid unnecessary costs.
manager_configs/mainnet/contracts.toml (3)
5-18: Neutron Section: Updated Contract Code IDsThe updated contract code IDs in the neutron section (e.g.,
polytone_proxy,valence_astroport_lper,valence_astroport_withdrawer, etc.) are clearly specified. Please verify that each numerical ID is aligned with your current registry and deployment strategy. Additionally, consider adding inline comments or documentation for the less obvious entries to improve future maintainability.
20-28: Juno Section: New Configuration for Contract Code IDsThe new section for the Juno network is well structured, assigning updated numerical IDs (such as
polytone_proxy= 3321,valence_processor= 4780, etc.). It would be beneficial to include a brief explanatory comment—similar to the neutron section if needed—to clarify any unique aspects of these entries. Also, ensure these values have been confirmed against the latest deployment documentation.
29-38: Terra Section: Addition of Terra Contract Code IDsThe added Terra section appears correct and follows the expected format. The inclusion of keys like
valence_astroport_lper(3560) andvalence_astroport_withdrawer(3561) for Terra is essential for the new crosschain LP program. Please double-check that these values are consistent with the Terra chain deployments and consider adding a descriptive comment to explain the use case.
| use std::collections::BTreeMap; | ||
|
|
||
| use valence_authorization_utils::{ | ||
| authorization::{ AuthorizationModeInfo, PermissionTypeInfo }, | ||
| authorization_message::{ Message, MessageDetails, MessageType, ParamRestriction }, | ||
| builders::{ AtomicFunctionBuilder, AtomicSubroutineBuilder, AuthorizationBuilder }, domain::Domain, | ||
| }; | ||
| use valence_generic_ibc_transfer_library::msg::{IbcTransferAmount, RemoteChainInfo}; | ||
| use valence_ibc_utils::types::PacketForwardMiddlewareConfig; | ||
| use valence_program_manager::{ | ||
| account::{ AccountInfo, AccountType }, | ||
| library::{ LibraryConfig, LibraryInfo }, | ||
| program_config::ProgramConfig, | ||
| program_config_builder::ProgramConfigBuilder, | ||
| }; | ||
| use valence_astroport_utils::PoolType; | ||
| use valence_astroport_lper::msg::LiquidityProviderConfig; | ||
| use valence_astroport_withdrawer::msg::LiquidityWithdrawerConfig; | ||
| use valence_library_utils::liquidity_utils::AssetData; | ||
|
|
||
| /// Write your program using the program builder | ||
| pub fn program_builder(params: deployer_lib::ProgramParams) -> ProgramConfig { | ||
|
|
||
| // Permissioned addresses | ||
| let owner = params.get("owner"); | ||
| let permissioned_withdrawer = params.get("permissioned_withdrawer"); | ||
|
|
||
| // Denoms | ||
| let usdc_on_terra = params.get("usdc_on_terra"); | ||
| let usdc_on_neutron = params.get("usdc_on_neutron"); | ||
| let ntrn_on_neutron = params.get("ntrn_on_neutron"); | ||
|
|
||
| // Astroport pool | ||
| let usdc_ntrn_pool_addr = params.get("usdc_ntrn_pool_addr"); | ||
|
|
||
| // IBC transfer inputs | ||
| let terra_noble_ibc_channel_id = params.get("terra_noble_ibc_channel_id"); | ||
| let noble_neutron_ibc_channel_id = params.get("noble_neutron_ibc_channel_id"); | ||
|
|
||
| // Initialize builder | ||
| let mut builder = ProgramConfigBuilder::new("test program",&owner); | ||
|
|
||
| // Domains | ||
| let neutron_domain = valence_program_manager::domain::Domain::CosmosCosmwasm( | ||
| "neutron".to_string() | ||
| ); | ||
| let terra_domain = valence_program_manager::domain::Domain::CosmosCosmwasm( | ||
| "terra2".to_string() | ||
| ); | ||
|
|
||
| // Accounts | ||
| let terra_input_account = builder.add_account( | ||
| AccountInfo::new("terra_input_account".to_string(), &terra_domain, AccountType::default()) | ||
| ); | ||
| let neutron_input_account = builder.add_account( | ||
| AccountInfo::new("neutron_input_account".to_string(), &neutron_domain, AccountType::default()) | ||
| ); | ||
| let liquidity_position_account = builder.add_account( | ||
| AccountInfo::new("liquidity_position_account".to_string(), &neutron_domain, AccountType::default()) | ||
| ); | ||
| let withdraw_output_account = builder.add_account( | ||
| AccountInfo::new("withdraw_output_account".to_string(), &neutron_domain, AccountType::default()) | ||
| ); | ||
|
|
||
| let mut terra_to_neutron_pfm_map:BTreeMap<String, PacketForwardMiddlewareConfig> = BTreeMap::new(); | ||
| terra_to_neutron_pfm_map.insert(usdc_on_terra.clone(),PacketForwardMiddlewareConfig { | ||
| local_to_hop_chain_channel_id: terra_noble_ibc_channel_id.to_string(), | ||
| hop_to_destination_chain_channel_id: noble_neutron_ibc_channel_id.to_string(), | ||
| hop_chain_receiver_address: "invalid-pfm".to_string(), // necessary so entire transaction is reverted | ||
| }); | ||
|
|
||
| // Libraries | ||
| let terra_ibc_transfer_library = builder.add_library( | ||
| LibraryInfo::new( | ||
| "terra_ibc_transfer".to_string(), | ||
| &terra_domain, | ||
| LibraryConfig::ValenceGenericIbcTransferLibrary({ | ||
| valence_generic_ibc_transfer_library::msg::LibraryConfig { | ||
| input_addr: terra_input_account.clone(), | ||
| output_addr: neutron_input_account.clone(), | ||
| denom: valence_library_utils::denoms::UncheckedDenom::Native(usdc_on_terra.to_string()), | ||
| amount: IbcTransferAmount::FullAmount, | ||
| remote_chain_info: RemoteChainInfo { | ||
| channel_id: terra_noble_ibc_channel_id.to_string(), | ||
| ibc_transfer_timeout: Some(600u64.into()), // 10 mins | ||
| }, | ||
| denom_to_pfm_map: terra_to_neutron_pfm_map, | ||
| memo: "".to_owned(), | ||
| } | ||
| }) | ||
| ) | ||
| ); | ||
|
|
||
| let pool_type = PoolType::NativeLpToken( | ||
| valence_astroport_utils::astroport_native_lp_token::PairType::Custom("concentrated".to_string()) | ||
| ); | ||
|
|
||
| let astroport_lper_library = builder.add_library(LibraryInfo::new( | ||
| "astroport_lper".to_string(), | ||
| &neutron_domain, | ||
| LibraryConfig::ValenceAstroportLper( | ||
| valence_astroport_lper::msg::LibraryConfig { | ||
| input_addr: neutron_input_account.clone(), | ||
| output_addr: liquidity_position_account.clone(), | ||
| pool_addr: usdc_ntrn_pool_addr.to_string(), | ||
| lp_config:LiquidityProviderConfig { | ||
| pool_type: pool_type.clone(), | ||
| asset_data: AssetData { | ||
| asset1: usdc_on_neutron.clone(), | ||
| asset2: ntrn_on_neutron.clone(), | ||
| }, | ||
| max_spread: None, | ||
| } | ||
| } | ||
| ) | ||
| )); | ||
|
|
||
| let astroport_withdrawer_library = builder.add_library( LibraryInfo::new( | ||
| "astroport_withdrawer".to_string(), | ||
| &neutron_domain, | ||
| LibraryConfig::ValenceAstroportWithdrawer( | ||
| valence_astroport_withdrawer::msg::LibraryConfig { | ||
| input_addr: liquidity_position_account.clone(), | ||
| output_addr: withdraw_output_account.clone(), | ||
| pool_addr: usdc_ntrn_pool_addr.to_string(), | ||
| withdrawer_config: LiquidityWithdrawerConfig { | ||
| pool_type: pool_type.clone(), | ||
| asset_data: AssetData { | ||
| asset1: usdc_on_neutron.clone(), | ||
| asset2: ntrn_on_neutron.clone() | ||
| }, | ||
| }, | ||
| } | ||
| ) | ||
| )); | ||
|
|
||
| // links | ||
| builder.add_link(&terra_ibc_transfer_library, vec![&terra_input_account], vec![&neutron_input_account]); | ||
| builder.add_link(&astroport_lper_library, vec![&neutron_input_account], vec![&liquidity_position_account]); | ||
| builder.add_link(&astroport_withdrawer_library, vec![&liquidity_position_account], vec![&withdraw_output_account]); | ||
|
|
||
|
|
||
| // authorizations | ||
| let ibc_transfer_subroutine = AtomicSubroutineBuilder::new() | ||
| .with_function(AtomicFunctionBuilder::new() | ||
| // NOTE: for crosschain domains, this must be added | ||
| .with_domain(Domain::External("terra".to_string())) | ||
| .with_contract_address(terra_ibc_transfer_library.clone()) | ||
| .with_message_details(MessageDetails { | ||
| message_type: MessageType::CosmwasmExecuteMsg, | ||
| message: Message { | ||
| name: "process_function".to_string(), | ||
| params_restrictions: Some( | ||
| vec![ | ||
| ParamRestriction::MustBeIncluded( | ||
| vec!["process_function".to_string(), "ibc_transfer".to_string()] | ||
| ) | ||
| ] | ||
| ) | ||
| } | ||
| }).build()); | ||
| builder.add_authorization( | ||
| AuthorizationBuilder::new() | ||
| .with_label("transfer_usdc_terra_to_neutron") | ||
| .with_subroutine( | ||
| ibc_transfer_subroutine.build() | ||
| ) | ||
| .build() | ||
| ); | ||
|
|
||
| let provide_liquidity_subroutine= AtomicSubroutineBuilder::new().with_function(AtomicFunctionBuilder::new() | ||
| .with_contract_address(astroport_withdrawer_library.clone()) | ||
| .with_message_details(MessageDetails { | ||
| message_type: MessageType::CosmwasmExecuteMsg, | ||
| message: Message { | ||
| name: "process_function".to_string(), | ||
| params_restrictions: Some( | ||
| vec![ | ||
| ParamRestriction::MustBeIncluded( | ||
| vec![ | ||
| "process_function".to_string(), | ||
| "provide_double_sided_liquidity".to_string() | ||
| ] | ||
| ) | ||
| ] | ||
| ), | ||
| }, | ||
| }) | ||
| .build()); | ||
|
|
||
| builder.add_authorization( | ||
| AuthorizationBuilder::new() | ||
| .with_label("provide_liquidity") | ||
| .with_subroutine( | ||
| provide_liquidity_subroutine.build() | ||
| ) | ||
| .build() | ||
| ); | ||
|
|
||
| let withdraw_liquidity_subroutine = AtomicSubroutineBuilder::new().with_function(AtomicFunctionBuilder::new() | ||
| .with_contract_address(astroport_withdrawer_library.clone()) | ||
| .with_message_details(MessageDetails { | ||
| message_type: MessageType::CosmwasmExecuteMsg, | ||
| message: Message { | ||
| name: "process_function".to_string(), | ||
| params_restrictions: Some( | ||
| vec![ | ||
| ParamRestriction::MustBeIncluded( | ||
| vec!["process_function".to_string(), "withdraw_liquidity".to_string()] | ||
| ) | ||
| ] | ||
| ), | ||
| }, | ||
| }) | ||
| .build()); | ||
|
|
||
| builder.add_authorization( | ||
| AuthorizationBuilder::new() | ||
| .with_mode( | ||
| AuthorizationModeInfo::Permissioned( | ||
| PermissionTypeInfo::WithoutCallLimit(vec![permissioned_withdrawer]) | ||
| ) | ||
| ) | ||
| .with_label("withdraw_liquidity") | ||
| .with_subroutine( | ||
| withdraw_liquidity_subroutine.build() | ||
| ) | ||
| .build() | ||
| ); | ||
|
|
||
| builder.build() | ||
| } No newline at end of file |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding error handling mechanisms.
The program lacks explicit error handling for scenarios like failed IBC transfers or liquidity provision operations. Consider implementing recovery mechanisms or fallback strategies.
For a cross-chain application, consider:
- Adding monitoring capabilities to track the state of cross-chain operations
- Implementing recovery mechanisms for when packets fail to arrive
- Adding logging for key events to aid in debugging
| let noble_neutron_ibc_channel_id = params.get("noble_neutron_ibc_channel_id"); | ||
|
|
||
| // Initialize builder | ||
| let mut builder = ProgramConfigBuilder::new("test program",&owner); |
There was a problem hiding this comment.
Update hardcoded program name for production.
The program name is hardcoded as "test program", which is inappropriate for a production deployment.
- let mut builder = ProgramConfigBuilder::new("test program",&owner);
+ let mut builder = ProgramConfigBuilder::new("crosschain_astroport_lper",&owner);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let mut builder = ProgramConfigBuilder::new("test program",&owner); | |
| let mut builder = ProgramConfigBuilder::new("crosschain_astroport_lper",&owner); |
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
programs/crosschain_astroport_lper/src/program_builder.rs (2)
1-232: Lack of error handling for cross-chain failures.
This code does not explicitly handle scenarios like failed IBC transfers, liquidity provision errors, or packet timeouts. Consider adding retry/fallback logic, as suggested in prior reviews.
24-26: Validate critical parameters to prevent deploying with empty or malformed values.
As suggested in a previous review, please add basic validation for parameters such asowner,permissioned_withdrawer, and the IBC channel IDs. For example:let owner = params.get("owner"); let permissioned_withdrawer = params.get("permissioned_withdrawer"); +if owner.is_empty() || permissioned_withdrawer.is_empty() { + panic!("Owner and permissioned_withdrawer cannot be empty"); +} let terra_cosmoshub_ibc_channel_id = params.get("terra_cosmoshub_ibc_channel_id"); let cosmoshub_neutron_ibc_channel_id = params.get("cosmoshub_neutron_ibc_channel_id"); +if terra_cosmoshub_ibc_channel_id.is_empty() || cosmoshub_neutron_ibc_channel_id.is_empty() { + panic!("IBC channel IDs cannot be empty"); +}Also applies to: 28-38
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
programs/crosschain_astroport_lper/program_params/mainnet.toml(1 hunks)programs/crosschain_astroport_lper/src/program_builder.rs(1 hunks)
🔇 Additional comments (3)
programs/crosschain_astroport_lper/program_params/mainnet.toml (2)
1-2: Consider separating the owner and permissioned_withdrawer addresses.
Currently, both fields point to the same address. Verify if that's truly intended, as it grants the same level of operational authority to a single entity.
7-8: Double-check the channel IDs.
It’s easy to mix up channel numbers in IBC configurations. Ensurechannel-0andchannel-569are correct and exist on the target chains.programs/crosschain_astroport_lper/src/program_builder.rs (1)
65-70: Assess use of “invalid-pfm” as thehop_chain_receiver_address.
This placeholder might cause the entire transaction to revert. Confirm whether this is intentional or a temporary artifact.
| let provide_liquidity_subroutine= AtomicSubroutineBuilder::new().with_function(AtomicFunctionBuilder::new() | ||
| .with_contract_address(astroport_withdrawer_library.clone()) | ||
| .with_message_details(MessageDetails { | ||
| message_type: MessageType::CosmwasmExecuteMsg, | ||
| message: Message { | ||
| name: "process_function".to_string(), | ||
| params_restrictions: Some( | ||
| vec![ | ||
| ParamRestriction::MustBeIncluded( | ||
| vec![ | ||
| "process_function".to_string(), | ||
| "provide_double_sided_liquidity".to_string() | ||
| ] | ||
| ) | ||
| ] | ||
| ), | ||
| }, | ||
| }) | ||
| .build()); | ||
|
|
There was a problem hiding this comment.
Verify that the “provide_liquidity_subroutine” calls the correct contract.
The subroutine references astroport_withdrawer_library instead of astroport_lper_library. This likely prevents proper liquidity provisioning.
let provide_liquidity_subroutine = AtomicSubroutineBuilder::new().with_function(
AtomicFunctionBuilder::new()
- .with_contract_address(astroport_withdrawer_library.clone())
+ .with_contract_address(astroport_lper_library.clone())
...
);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let provide_liquidity_subroutine= AtomicSubroutineBuilder::new().with_function(AtomicFunctionBuilder::new() | |
| .with_contract_address(astroport_withdrawer_library.clone()) | |
| .with_message_details(MessageDetails { | |
| message_type: MessageType::CosmwasmExecuteMsg, | |
| message: Message { | |
| name: "process_function".to_string(), | |
| params_restrictions: Some( | |
| vec![ | |
| ParamRestriction::MustBeIncluded( | |
| vec![ | |
| "process_function".to_string(), | |
| "provide_double_sided_liquidity".to_string() | |
| ] | |
| ) | |
| ] | |
| ), | |
| }, | |
| }) | |
| .build()); | |
| let provide_liquidity_subroutine = AtomicSubroutineBuilder::new().with_function( | |
| AtomicFunctionBuilder::new() | |
| .with_contract_address(astroport_lper_library.clone()) | |
| .with_message_details(MessageDetails { | |
| message_type: MessageType::CosmwasmExecuteMsg, | |
| message: Message { | |
| name: "process_function".to_string(), | |
| params_restrictions: Some( | |
| vec![ | |
| ParamRestriction::MustBeIncluded( | |
| vec![ | |
| "process_function".to_string(), | |
| "provide_double_sided_liquidity".to_string() | |
| ] | |
| ) | |
| ] | |
| ), | |
| }, | |
| }) | |
| .build() | |
| ); |
There was a problem hiding this comment.
Actionable comments posted: 10
🔭 Outside diff range comments (6)
programs/program_template/Cargo.toml (1)
16-48:⚠️ Potential issueResolve merge conflicts
The file contains Git merge conflict markers that need to be resolved before this PR can be merged.
Remove all merge conflict markers (
<<<<<<<,=======,>>>>>>>) and decide which dependencies to keep. Based on the changes in other files, you should likely keep the new CW dependencies while ensuring important dependencies aren't accidentally removed.README.md (1)
1-32:⚠️ Potential issueResolve merge conflicts
The README.md file contains Git merge conflict markers that need to be resolved before this PR can be merged.
Remove all merge conflict markers (
<<<<<<<,=======,>>>>>>>) and combine both sections appropriately. The new content appears to provide more detailed information about the program deployer structure and functionality.programs/program_template/README.md (1)
1-45:⚠️ Potential issueResolve leftover merge conflict markers.
Lines 1 through 45 contain
<<<<<<< HEAD,=======, and>>>>>>> template/main, which can break your build or documentation generation if not resolved. Finalize the merge by removing conflict markers and reconciling any overlapping content.-... -... +# Program example +... (retain the correct, merged README content) ...lib/src/lib.rs (3)
21-52:⚠️ Potential issueClean up merge conflict and combine code
This chunk contains leftover conflict markers and duplicated lines. Merge the comments from HEAD with the newStatusenum from the template.-<<<<<<< HEAD -// Reexport params to programs -// ... -======= // Re-export params to programs pub use helpers::EMPTY_VEC; pub use program_params::ProgramParams; #[derive(Debug, PartialEq)] enum Status { Process, Success, Fail, } impl Display for Status { fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { match self { Status::Process => write!(f, "process"), Status::Success => write!(f, "success"), Status::Fail => write!(f, "fail"), } } } ->>>>>>> template/main
95-125:⚠️ Potential issueConsolidate path verification and output path creation
Unify the approach from the template to include logging and use anoutput_pathvariable. Remove leftover conflict markers.-<<<<<<< HEAD verify_path(program_path.clone())?; -... -======= info!("Verifying program path"); verify_path(program_path.clone())?; let output_path = program_path .join("output") .join(format!("{}-{}", args.target_env, timestamp)); ->>>>>>> template/main
170-192:⚠️ Potential issueUpdate the signature of
write_to_output
Switch to passing&ProgramConfig, a mutablePathBuf, and theStatusenum per the template for consistent error handling.-<<<<<<< HEAD program_config: ProgramConfig, program_path: &PathBuf, time: &str, prefix: &str, ======= program_config: &ProgramConfig, mut path: PathBuf, status: Status, prefix: &str, ->>>>>>> template/main
🧹 Nitpick comments (3)
lib/Cargo.toml (1)
21-21: Consider pinning the library version.You may want to explicitly pin the version of
valence-library-utilsto ensure reproducible builds and avoid unexpected breakages if future changes to the library introduce incompatibilities.programs/program_template/README.md (1)
44-44: Fix the “uodate” typo.In the newly added text, “Secure uodate second forwarder config” should read “Secure update second forwarder config.”
- Secure uodate second forwarder config + Secure update second forwarder configprograms/program_template/src/program_builder.rs (1)
203-203: Unify or correct the authorization label.The label “Forward_from second_to_first” might be inconsistent with “Forward_from_first_to_second.” Consider renaming it to “Forward_from_second_to_first” for clarity.
- .with_label("Forward_from second_to_first") + .with_label("Forward_from_second_to_first")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (13)
.gitignore(1 hunks)Cargo.toml(2 hunks)README.md(4 hunks)lib/Cargo.toml(1 hunks)lib/src/helpers.rs(1 hunks)lib/src/lib.rs(7 hunks)lib/src/manager_config.rs(5 hunks)lib/src/program_config.rs(1 hunks)lib/src/program_params.rs(2 hunks)programs/program_template/Cargo.toml(2 hunks)programs/program_template/README.md(2 hunks)programs/program_template/program_params/mainnet.toml(1 hunks)programs/program_template/src/program_builder.rs(3 hunks)
✅ Files skipped from review due to trivial changes (2)
- lib/src/program_config.rs
- lib/src/helpers.rs
🚧 Files skipped from review as they are similar to previous changes (1)
- .gitignore
🧰 Additional context used
🧬 Code Definitions (1)
lib/src/lib.rs (4)
lib/src/helpers.rs (1)
verify_path(8-26)lib/src/manager_config.rs (1)
set_manager_config(65-73)lib/src/program_config.rs (2)
read_program_config_from_json(3-6)serde_json(5-5)lib/src/program_params.rs (3)
get_program_params(4-28)new(36-38)get(40-44)
🔇 Additional comments (23)
lib/src/manager_config.rs (5)
2-2: Good change to usePathinstead ofPathBufUsing
Pathinstead ofPathBufis more flexible as it allows accepting both ownedPathBufand borrowed&Pathvalues. Since the codebase doesn't need to own the path in this context, using the more generalPathtype is appropriate.
4-5: Formatting improvementBreaking the long URL string constant across two lines improves readability. This is a good change.
21-29: Simplified error handling approachThe refactored error handling is more idiomatic Rust. Using
if let Ok(cfg) = ...and directly returning the deserialized result or error improves code readability and reduces nesting.
65-65: Style consistency improvementAdding a space before the opening brace maintains consistent coding style throughout the file. Good attention to detail.
75-75: Improved function signature withPathinstead ofPathBufThis change aligns with the update to the import on line 2. Using
&Pathinstead of&PathBufis a good practice as it's more flexible, allowing the function to accept any type that can be borrowed as aPath.programs/program_template/Cargo.toml (1)
23-25: New CosmWasm dependencies addedThe addition of CosmWasm standard libraries will enable interaction with CosmWasm smart contracts, which aligns with the crosschain Astroport liquidity provider functionality.
README.md (4)
12-31: Improved documentation structureThe new documentation provides clearer explanation of the repository structure and purpose, making it easier for users to understand how to use the program deployer.
40-41: Enhanced MANAGER_MNEMONIC explanationThe additional clarification about the MANAGER_MNEMONIC helps prevent security issues by specifying that it should not be the owner's mnemonic.
65-68: Terminology updateChanging from "deploy your program" to "run your program" more accurately reflects the action being performed.
84-84: Added debug informationIncluding information about the debug-program-config.json file is valuable for troubleshooting failed deployments.
lib/src/program_params.rs (6)
2-2: Updated importsThe import is updated to include
ErrorandPathBufexplicitly, improving code clarity.
14-18: Improved error handling for missing parameter filesThe added check for the existence of parameter files before attempting to process them provides clearer error messages and fails faster when files are missing.
20-27: Simplified configuration buildingThe configuration building process has been simplified and improved by directly building the configuration and passing it to the new ProgramParams constructor.
31-38: Refactored ProgramParams structureThe ProgramParams struct now uses ConfigHelper directly instead of a HashMap, which provides more functionality and clearer structure.
40-44: Enhanced get methodThe updated get method now retrieves values directly from the ConfigHelper with improved error handling that provides more context when keys are not found.
46-53: New get_array methodThe addition of the get_array method enables retrieval of array parameters, expanding the functionality of the ProgramParams struct.
Cargo.toml (4)
28-28: Dependency versioning improvementSwitching from a branch reference to a specific tag (v0.1.2) improves stability and reproducibility of builds.
38-44: Added logging and CosmWasm dependenciesNew dependencies for logging (env_logger, log) and CosmWasm integration (cosmwasm-std, cw-utils, cw-denom) enhance the project's capabilities.
The logging dependencies will improve debugging capabilities, while the CosmWasm dependencies enable interaction with smart contracts on CosmWasm-compatible chains, which is necessary for the crosschain liquidity provider functionality.
47-61: Consistent dependency versioningAll Valence libraries have been updated to use tags (v0.1.2) instead of branch references, which is a good practice for dependency management.
64-72: Updated utility dependenciesThe utility dependencies have also been updated to use the same versioning approach, ensuring consistency across the project.
lib/Cargo.toml (1)
18-19: Good addition of logging crates.The inclusion of
env_loggerandlogcrates will improve debugging and logging capabilities.programs/program_template/program_params/mainnet.toml (1)
5-8: Verify correctness of new parameter values.The parameters
denom,max_first_forward_amount,max_second_forward_amount, andauthorized_addrare newly introduced. Confirm they match your intended mainnet specs, as incorrect denominators or addresses can break cross-chain transfers.lib/src/lib.rs (1)
6-6: Import usage looks good
Addingfmt::Displayis necessary for the newStatusenum’s string formatting.
| <<<<<<< HEAD | ||
| valence-encoder-broker = { workspace = true } | ||
| valence-neutron-ic-querier = { workspace = true } | ||
| valence-drop-liquid-staker = { workspace = true } | ||
| ======= | ||
| >>>>>>> template/main |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Potential removal of required dependencies
The removed dependencies (valence-encoder-broker, valence-neutron-ic-querier, and valence-drop-liquid-staker) might be needed for some functionality. Ensure these removals are intentional and won't break existing code.
🏁 Script executed:
#!/bin/bash
# Check if any of the removed dependencies are used in the codebase
echo "Checking for usage of removed dependencies..."
rg "valence_encoder_broker|encoder_broker" --type rust
rg "valence_neutron_ic_querier|neutron_ic_querier" --type rust
rg "valence_drop_liquid_staker|drop_liquid_staker" --type rustLength of output: 287
Please execute the above script to verify if any references to these dependencies exist beyond the Rust file scope.
🏁 Script executed:
#!/bin/bash
# A more comprehensive search for the removed dependencies across the entire codebase.
echo "Performing comprehensive search for removed dependency usage..."
# Search for both dashed and underscored naming conventions across all files
rg "valence-encoder-broker|valence_encoder_broker|encoder_broker" -n .
rg "valence-neutron-ic-querier|valence_neutron_ic_querier|neutron_ic_querier" -n .
rg "valence-drop-liquid-staker|valence_drop_liquid_staker|drop_liquid_staker" -n .Length of output: 2343
Action Required: Confirm Dependency Removal Consistency
The removal of the following dependencies in programs/program_template/Cargo.toml (lines 43–48):
valence-encoder-brokervalence-neutron-ic-queriervalence-drop-liquid-staker
has been flagged. Our comprehensive search shows that these dependencies are still referenced in several other parts of the codebase, including:
- Other package manifests (e.g., in
programs/astroport_lper/Cargo.tomlandprograms/crosschain_astroport_lper/Cargo.toml) - The
Cargo.lockfile (multiple entries for each dependency) - Manager configurations for
valence-drop-liquid-staker(in both testnet and mainnet setups)
Please verify whether their removal in programs/program_template/Cargo.toml (as indicated by the merge conflict) is intentional. If these dependencies are required for the project’s functionality, consider reverting the removal or updating all related files to maintain consistency. Otherwise, ensure that the removal is propagated appropriately across the entire codebase to avoid any runtime issues.
| # CW | ||
| cosmwasm-std = { version = "2.1.3" } | ||
| cw-utils = "2.0.0" | ||
| cw-denom = { package = "cw-denom", git = "https://github.com/DA0-DA0/dao-contracts", branch = "cw-std-2" } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify cw-denom dependency configuration
The cw-denom dependency is configured with a branch "cw-std-2" which might not be stable. Consider using a tagged version like the other dependencies.
🌐 Web query:
Is there a stable release or tag for the cw-denom package in the DAO-DAO dao-contracts repository?
💡 Result:
The cw-denom package, used for validating CW20 and Cosmos SDK native denominations, has a stable release available on crates.io as version 2.4.1, last updated on July 21, 2024[6][9]. This release includes type definitions (UncheckedDenom and CheckedDenom) and validation logic aligned with Cosmos SDK standards[1][6].
While the DAO-DAO ecosystem (daodao.zone) utilizes CosmWasm smart contracts extensively[8][10], the cw-denom package itself appears to be maintained as an independent Rust crate rather than part of DAO-DAO's specific dao-contracts repository. The latest version implements denomination validation through:
- Regex checks for native tokens (
[a-zA-Z][a-zA-Z0-9/:._-]{2,127})[1] - CW20 contract address verification[1]
- Type-safe differentiation between unchecked/validated denominations[1][6]
No explicit references to DAO-DAO repository tags were found in the provided sources, but the crate's versioning on crates.io confirms its stable status[6][9]. For integration with DAO-DAO contracts, developers would typically reference the crate via its crates.io listing rather than repository-specific tags.
Citations:
- 1: https://docs.rs/cw-denom
- 2: https://corporations.utah.gov/wp-content/uploads/2023/12/DAOapplication.pdf
- 3: https://assets.publishing.service.gov.uk/media/5a757b41e5274a1622e2221e/acronyms_and_abbreviations_dec08.pdf
- 4: https://blog.blockmagnates.com/how-to-create-a-dao-7383326b1a31
- 5: https://www.aragon.org/how-to/build-a-dao-plugin-using-aragon-osx
- 6: https://crates.io/crates/cw-denom/2.4.1
- 7: https://docs.rs/cw-vesting
- 8: https://daodao.zone
- 9: https://crates.io/crates/cw-denom/2.4.1/dependencies
- 10: https://arxiv.org/html/2501.12972v1
Update cw-denom Dependency to Stable Release Version
The current configuration in Cargo.toml references cw-denom via a Git branch (cw-std-2), which may lead to instability. Since a stable release exists—version 2.4.1 available on crates.io—please update the dependency to use this tagged version.
-
File: Cargo.toml (Line 44)
-
Suggested Change:
- cw-denom = { package = "cw-denom", git = "https://github.com/DA0-DA0/dao-contracts", branch = "cw-std-2" } + cw-denom = "2.4.1"
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| cw-denom = { package = "cw-denom", git = "https://github.com/DA0-DA0/dao-contracts", branch = "cw-std-2" } | |
| cw-denom = "2.4.1" |
| <<<<<<< HEAD | ||
| owner = "neutron1phx0sz708k3t6xdnyc98hgkyhra4tp44et5s68" | ||
| ======= |
There was a problem hiding this comment.
Remove leftover merge conflict markers.
Lines 1 to 3 still have the <<<<<<< HEAD and >>>>>>> template/main markers. Complete the merge to keep a single final version that blends your changes correctly.
| <<<<<<< HEAD | ||
| ======= | ||
| use std::str::FromStr; |
There was a problem hiding this comment.
Resolve leftover merge conflict markers.
The code includes <<<<<<< HEAD, =======, and >>>>>>> template/main from lines 1-3 and 70-71. Merge conflicts must be resolved before building or deploying the program.
-<<<<<<< HEAD
-use std::str::FromStr;
-=======
-use other::stuff;
->>>>>>> template/main
+use std::str::FromStr;Also applies to: 70-71
| output_addr: acc_second.clone(), | ||
| forwarding_configs: vec![valence_forwarder_library::msg::UncheckedForwardingConfig { | ||
| denom: UncheckedDenom::Native(denom.clone()), | ||
| max_amount: Uint128::from_str(max_first_forward_amount.as_str()).unwrap(), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Handle potential parse failures safely.
Unwrapping from_str could panic at runtime. For robust error handling, consider using ? or a custom error message to handle invalid input more gracefully.
- Uint128::from_str(max_first_forward_amount.as_str()).unwrap()
+ Uint128::from_str(max_first_forward_amount.as_str())?Also applies to: 134-134
| <<<<<<< HEAD | ||
| ======= | ||
|
|
||
| async fn print_success_msg(program_config: &ProgramConfig) { | ||
| let gc = valence_program_manager::config::GLOBAL_CONFIG.lock().await; | ||
| let ui_link_main = format!("https://app.valence.zone/programs/{}", program_config.id); | ||
| let ui_link = format!("{}?queryConfig={{\"main\":{{\"registryAddress\":\"{}\",\"name\":\"neutron\",\"chainId\":\"neutron-1\",\"rpcUrl\":\"{}\"}},\"external\":[]}}", ui_link_main, gc.general.registry_addr, gc.chains.get("neutron").unwrap().rpc); | ||
|
|
||
| let success_msg = format!( | ||
| "Program deployed successfully! | ||
| Program id: {} | ||
| View program on Valence UI: {}", | ||
| program_config.id, ui_link | ||
| ); | ||
|
|
||
| println!("{success_msg}"); | ||
| } | ||
| >>>>>>> template/main |
There was a problem hiding this comment.
Restore the print_success_msg function
Keep the new function from the template for improved user feedback. Remove the conflict markers.
-<<<<<<< HEAD
-=======
async fn print_success_msg(program_config: &ProgramConfig) {
let gc = valence_program_manager::config::GLOBAL_CONFIG.lock().await;
let ui_link_main = format!("https://app.valence.zone/programs/{}", program_config.id);
let ui_link = format!("{}?queryConfig={{\"main\":{{\"registryAddress\":\"{}\",\"name\":\"neutron\",\"chainId\":\"neutron-1\",\"rpcUrl\":\"{}\"}},\"external\":[]}}", ui_link_main, gc.general.registry_addr, gc.chains.get("neutron").unwrap().rpc);
let success_msg = format!(
"Program deployed successfully!
Program id: {}
View program on Valence UI: {}",
program_config.id, ui_link
);
println!("{success_msg}");
}
->>>>>>> template/main📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <<<<<<< HEAD | |
| ======= | |
| async fn print_success_msg(program_config: &ProgramConfig) { | |
| let gc = valence_program_manager::config::GLOBAL_CONFIG.lock().await; | |
| let ui_link_main = format!("https://app.valence.zone/programs/{}", program_config.id); | |
| let ui_link = format!("{}?queryConfig={{\"main\":{{\"registryAddress\":\"{}\",\"name\":\"neutron\",\"chainId\":\"neutron-1\",\"rpcUrl\":\"{}\"}},\"external\":[]}}", ui_link_main, gc.general.registry_addr, gc.chains.get("neutron").unwrap().rpc); | |
| let success_msg = format!( | |
| "Program deployed successfully! | |
| Program id: {} | |
| View program on Valence UI: {}", | |
| program_config.id, ui_link | |
| ); | |
| println!("{success_msg}"); | |
| } | |
| >>>>>>> template/main | |
| async fn print_success_msg(program_config: &ProgramConfig) { | |
| let gc = valence_program_manager::config::GLOBAL_CONFIG.lock().await; | |
| let ui_link_main = format!("https://app.valence.zone/programs/{}", program_config.id); | |
| let ui_link = format!("{}?queryConfig={{\"main\":{{\"registryAddress\":\"{}\",\"name\":\"neutron\",\"chainId\":\"neutron-1\",\"rpcUrl\":\"{}\"}},\"external\":[]}}", ui_link_main, gc.general.registry_addr, gc.chains.get("neutron").unwrap().rpc); | |
| let success_msg = format!( | |
| "Program deployed successfully! | |
| Program id: {} | |
| View program on Valence UI: {}", | |
| program_config.id, ui_link | |
| ); | |
| println!("{success_msg}"); | |
| } |
| <<<<<<< HEAD | ||
| let content = serde_json::to_string(&program_config)?; | ||
| ======= | ||
| let content = serde_json::to_string(program_config)?; | ||
| >>>>>>> template/main |
There was a problem hiding this comment.
Use the reference directly in serde_json::to_string
Remove the leftover conflict lines and maintain the call that passes program_config as a reference.
-<<<<<<< HEAD
let content = serde_json::to_string(&program_config)?;
-=======
let content = serde_json::to_string(program_config)?;
->>>>>>> template/main📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <<<<<<< HEAD | |
| let content = serde_json::to_string(&program_config)?; | |
| ======= | |
| let content = serde_json::to_string(program_config)?; | |
| >>>>>>> template/main | |
| let content = serde_json::to_string(&program_config)?; |
| <<<<<<< HEAD | ||
| write_to_output(program_config.clone(), &program_path, ×tamp, "raw")?; | ||
|
|
||
| // Use program manager to deploy the program | ||
| valence_program_manager::init_program(&mut program_config).await?; | ||
|
|
||
| // Write instantiated program to file | ||
| write_to_output(program_config, &program_path, ×tamp, "instantiated")?; | ||
| ======= | ||
| info!("Writing raw program config to file"); | ||
| write_to_output(&program_config, output_path.clone(), Status::Process, "raw")?; | ||
|
|
||
| // Use program manager to deploy the program | ||
| println!("Instantiating program..."); | ||
| match valence_program_manager::init_program(&mut program_config).await { | ||
| Ok(_) => (), | ||
| Err(e) => { | ||
| write_to_output(&program_config, output_path.clone(), Status::Fail, "debug")?; | ||
|
|
||
| return Err(Box::new(e)); | ||
| } | ||
| }; | ||
|
|
||
| // Write instantiated program to file | ||
| write_to_output( | ||
| &program_config, | ||
| output_path, | ||
| Status::Success, | ||
| "instantiated", | ||
| )?; | ||
|
|
||
| print_success_msg(&program_config).await; | ||
| >>>>>>> template/main |
There was a problem hiding this comment.
Incorporate status-based deployment flow
The new approach uses a Status enum to manage success/fail states and logs progress. Keep the template’s logic and remove conflict markers.
-<<<<<<< HEAD
write_to_output(program_config.clone(), &program_path, ×tamp, "raw")?;
valence_program_manager::init_program(&mut program_config).await?;
// ...
-=======
info!("Writing raw program config to file");
write_to_output(&program_config, output_path.clone(), Status::Process, "raw")?;
println!("Instantiating program...");
match valence_program_manager::init_program(&mut program_config).await {
Ok(_) => (),
Err(e) => {
write_to_output(&program_config, output_path.clone(), Status::Fail, "debug")?;
return Err(Box::new(e));
}
};
// ...
print_success_msg(&program_config).await;
->>>>>>> template/main📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <<<<<<< HEAD | |
| write_to_output(program_config.clone(), &program_path, ×tamp, "raw")?; | |
| // Use program manager to deploy the program | |
| valence_program_manager::init_program(&mut program_config).await?; | |
| // Write instantiated program to file | |
| write_to_output(program_config, &program_path, ×tamp, "instantiated")?; | |
| ======= | |
| info!("Writing raw program config to file"); | |
| write_to_output(&program_config, output_path.clone(), Status::Process, "raw")?; | |
| // Use program manager to deploy the program | |
| println!("Instantiating program..."); | |
| match valence_program_manager::init_program(&mut program_config).await { | |
| Ok(_) => (), | |
| Err(e) => { | |
| write_to_output(&program_config, output_path.clone(), Status::Fail, "debug")?; | |
| return Err(Box::new(e)); | |
| } | |
| }; | |
| // Write instantiated program to file | |
| write_to_output( | |
| &program_config, | |
| output_path, | |
| Status::Success, | |
| "instantiated", | |
| )?; | |
| print_success_msg(&program_config).await; | |
| >>>>>>> template/main | |
| info!("Writing raw program config to file"); | |
| write_to_output(&program_config, output_path.clone(), Status::Process, "raw")?; | |
| // Use program manager to deploy the program | |
| println!("Instantiating program..."); | |
| match valence_program_manager::init_program(&mut program_config).await { | |
| Ok(_) => (), | |
| Err(e) => { | |
| write_to_output(&program_config, output_path.clone(), Status::Fail, "debug")?; | |
| return Err(Box::new(e)); | |
| } | |
| }; | |
| // Write instantiated program to file | |
| write_to_output( | |
| &program_config, | |
| output_path, | |
| Status::Success, | |
| "instantiated", | |
| )?; | |
| print_success_msg(&program_config).await; |
| <<<<<<< HEAD | ||
| // Load .env file environment variables | ||
| ======= | ||
| // Enable logs | ||
| env_logger::init(); | ||
|
|
||
| println!("Starting program deployment..."); | ||
|
|
||
| // Load .env file environment variables | ||
| info!("Loading environment variables from .env file"); | ||
| >>>>>>> template/main |
There was a problem hiding this comment.
Resolve merge conflicts around logging initialization
Adopt the template approach to initialize logging and show environment loading. Remove the leftover merge conflict lines.
-<<<<<<< HEAD
-// Load .env file environment variables
-=======
// Enable logs
env_logger::init();
println!("Starting program deployment...");
// Load .env file environment variables
info!("Loading environment variables from .env file");
->>>>>>> template/main📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <<<<<<< HEAD | |
| // Load .env file environment variables | |
| ======= | |
| // Enable logs | |
| env_logger::init(); | |
| println!("Starting program deployment..."); | |
| // Load .env file environment variables | |
| info!("Loading environment variables from .env file"); | |
| >>>>>>> template/main | |
| // Enable logs | |
| env_logger::init(); | |
| println!("Starting program deployment..."); | |
| // Load .env file environment variables | |
| info!("Loading environment variables from .env file"); |
| <<<<<<< HEAD | ||
| ======= | ||
| use log::info; | ||
| >>>>>>> template/main |
There was a problem hiding this comment.
Remove leftover Git conflict markers
It appears the merge conflict markers are still present. You should unify the changes and remove these lines to avoid compilation errors.
-<<<<<<< HEAD
-=======
use log::info;
->>>>>>> template/mainCommittable suggestion skipped: line range outside the PR's diff.
3 participants
WIP. still debugging deploy errors
Summary by CodeRabbit