You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Experimental idea: Implement ERC404 and build a cross-chain NFT minting game:
10,000 ERC-20 tokens & same number of associated “Replicant” NFTs.
If someone buys one full token on a DEX on Optimism testnet, one replicant NFT will be minted on Base.
If the token is sold, the connected NFT must be burned.
Gamification: Users initiate a sell from Base with a defined slippage (lower slippage means more points) and users on the Optimism DEX earn points for throwing off price to fail trades due to slippage (higher slippage failed tx means more points).
Note: Having fun with Acknowledgements by building complex onRecvPacket and onAcknowledgment behaviors.
In IBC when a packet is sent, it goes through three distinct phases of the packet lifecycle: (1) the initiating sendPacket transaction from the source chain, (2) the corresponding recvPacket transaction on the destination chain that executes a specific action (referred to as the 'onRecvPacket' callback action), and (3) finally a acknowledgment or timeout transaction. The acknowledgment serves as a notification to the originating chain about the receipt of the packet on the destination.
NOTE: timeouts are currently not supported on testnet
If the action involves the minting of a specific token on the destination chain, there are ways to improve UX: the user tokens on source are unlocked or not burned in case of a failed onRecvPacket callback action of minting new tokens.
The text was updated successfully, but these errors were encountered:
Volatile Pricing: The gamification aspect that rewards users for throwing off prices on the DEX could lead to extreme volatility and manipulation, making it difficult to maintain a stable market for the ERC-20 tokens and associated NFTs.
Liquidity Challenges: If users are incentivized to fail trades due to slippage, it might discourage genuine buyers and sellers, leading to liquidity issues on the DEX.
Complexity of IBC Interactions: Managing the intricate details of IBC packet lifecycle, including handling acknowledgments and potential timeouts, can be complex, especially when dealing with cross-chain NFT minting and burning mechanisms.
User Experience Challenges: The combination of multiple blockchain networks, DEXs, NFTs, and gamification elements could create a steep learning curve for users, potentially deterring widespread adoption.
Potential Solutions:
Controlled Volatility: Instead of rewarding users for throwing off prices, consider implementing a controlled volatility mechanism. For example, you could introduce a dynamic slippage tolerance that adjusts based on market conditions, ensuring a balance between price stability and trade execution.
Liquidity Incentives: Offer incentives for genuine buyers and sellers to participate in the market, such as trading fee discounts or airdrops, to maintain healthy liquidity levels.
Simplified IBC Interactions: Abstract away the complexities of IBC packet lifecycle by implementing robust error handling and fallback mechanisms. For example, if an NFT minting fails on the destination chain, automatically refund the tokens on the source chain to ensure a seamless user experience.
Gamified Education: Introduce gamified educational elements to onboard users gradually, helping them understand the underlying concepts and mechanics of the system in an engaging and interactive manner.
Experimental idea: Implement ERC404 and build a cross-chain NFT minting game:
Gamification: Users initiate a sell from Base with a defined slippage (lower slippage means more points) and users on the Optimism DEX earn points for throwing off price to fail trades due to slippage (higher slippage failed tx means more points).
Note: Having fun with Acknowledgements by building complex onRecvPacket and onAcknowledgment behaviors.
In IBC when a packet is sent, it goes through three distinct phases of the packet lifecycle: (1) the initiating sendPacket transaction from the source chain, (2) the corresponding recvPacket transaction on the destination chain that executes a specific action (referred to as the 'onRecvPacket' callback action), and (3) finally a acknowledgment or timeout transaction. The acknowledgment serves as a notification to the originating chain about the receipt of the packet on the destination.
NOTE: timeouts are currently not supported on testnet
If the action involves the minting of a specific token on the destination chain, there are ways to improve UX: the user tokens on source are unlocked or not burned in case of a failed onRecvPacket callback action of minting new tokens.
The text was updated successfully, but these errors were encountered: