CosmWASM NFT Swap Contract Failing to Deliver Replacement

NFT
1

I built a CosmWASM NFT swap contract that burns an old NFT and sends a new one, but the new token isn’t delivered. Sample code:

use cosmwasm_std::{Addr, MessageInfo, Response};
use serde_json::from_slice;

pub fn handle_incoming(info: MessageInfo, recv: Cw721ReceiveMsg) -> Result<Response, ContractError> {
    let token = recv.token_id;
    let user = recv.sender;
    let swap_request: SwapMsg = from_slice(&recv.msg)?;
    let new_contract = swap_request.new_contract_addr;

    if info.sender != Addr::unchecked("chain_dummy_addr") {
        return Err(ContractError::Unauthorized {});
    }

    NFTModule::new(Addr::unchecked("chain_dummy_addr"))
        .burn(token.clone())?;
    NFTModule::new(new_contract)
        .transfer(user, token)?;

    Ok(Response::new().add_attribute("action", "nft_swapped"))
}
2

In my experience, similar issues sometimes occur because the inter-contract communication isn’t fully reliable within a single transaction. I faced a situation where transferring the new token immediately after burning the old one did not complete as expected. It might be beneficial to verify whether the new NFT module holds the appropriate permissions for transferring the token and if the message execution order is correctly maintained. Carefully reviewing logs and transactional events helped me identify subtle permission issues in similar scenarios. Testing in a more granular manner could provide further clarity on the process.

3

hey, i faced a simmilar prob too. try double-checking if the new contract has the right auth settings for transfers. i found that using extra debug log statements helped me narrow it down. might be an intercontract communication issue atm.

4

hey all, i’ve been tinkering with similar stuff and now i’m wondering if the issue might be coming from how the contract handles state updates between the burn and the transfer. sometimes i feel that the ctx might not be committing the state change properly, so the transfer never happens even if the burn went through. could it be that some module or handler in the backend is missing extra validation or confirmation of the state update? also, has anyone looked at the logs to see if both actions are called correctly? i think it might help to try breaking the process into two phases and see if that reveals anything. what do you guys think could be done differently to troubleshoot this? any more insights would be really welcome!

5

From experience, an issue like this might occur if there’s an implicit assumption about the immediacy or atomicity of state changes between operations. It may be worth diving deeper into how the NFT module processes burn and transfer calls synchronously and verifying if any internal state conflict or race condition arises. Examining whether the transfer is susceptible to subtle misconfigurations, such as issues with address validation or asynchronous handling, could reveal if the operation fails silently. Implementing detailed logging around both operations might uncover the exact sequence of events leading to the observed behavior.