The problem LootPang solves

LootPang aims to radically simplify the way users engage with Web3 quests, especially those requiring multi-chain token holdings. Today, many quest platforms overwhelm users with:
• A flood of complex, noisy, and often outdated quests.
• High technical barriers for completing cross-chain tasks.
• The burden of managing bridge/swap/gas operations across unfamiliar networks.

For example, a typical user holding ETH on Ethereum mainnet may encounter a quest requiring 0.1 KK token on Base. This normally involves:
• Using a bridge to move ETH to Base.
• Swapping ETH for KK on a DEX.
• Paying gas fees across both chains.
• Hoping the quest conditions are still valid upon arrival.

LootPang automates and abstracts this chaos.

Instead of the user doing all the work, LootPang introduces two AI-powered agents:
1. Quest Curation Agent: Automatically analyzes quests from platforms like Galxe based on user preferences, wallet contents, and effort-to-reward ratio. It filters and recommends only relevant, easy-to-complete quests.
2. Token Loan Agent: For “Hold X Token on Y Chain” quests, the agent enables users to temporarily borrow tokens by depositing ETH on another chain as collateral. This avoids the need for bridging, swapping, or guessing how much gas is needed.

Through this design, LootPang transforms frustrating multi-step tasks into one-click completions.

Challenges I ran into

While building LootPang, I encountered several technical and architectural hurdles across different components:

Limited Documentation for ElizaOS

One of the biggest challenges was working with ElizaOS, especially due to its sparse documentation. Implementing a custom plugin was not straightforward — I had to experiment via the CLI, manually tweaking files and testing iteratively until it finally worked.

Moreover, the structure and fields within character.json were poorly documented. At one point, my custom action wouldn’t trigger at all, and I later realized it was due to improperly formatted example fields inside the config. It was a frustrating yet valuable lesson in how even minor misconfigurations can silently break agent behavior.

Through trial and error, I also discovered that ElizaOS is better suited for conversational, prompt-based flows. If I simply wanted to trigger a task like “Borrow 5 KK Token” via a UI button, there was little benefit to involving an autonomous agent. In such cases, direct API integration with OpenAI was more efficient than writing a full ElizaOS action.

Misunderstanding Chainlink CCIP

I initially jumped into using Chainlink CCIP without thoroughly reading the documentation. As a result, although messages were being sent between chains, they failed with permission errors.

After carefully reviewing the official docs, I identified the missing authorization steps. Fortunately, the documentation was well-written and the provided examples were solid, which helped me resolve the issue successfully.

Handling CCIP Delays and Nonce Issues

One subtle but critical issue came from CCIP’s delay time — each message took around 20 minutes to be delivered. During that window, nonce mismatches became a major problem.

For example, if a message was sent with nonce X, and the backend didn’t keep state correctly, the verification step 20 minutes later might expect a different nonce. This led to repeated “Invalid nonce” errors during delivery confirmation.

I resolved this by implementing a dynamic nonce renewal mechanism, ensuring the correct values were always fetched at execution time. This fix dramatically improved message reliability across chains.

These challenges taught me not just how to patch bugs, but also how to balance when to use orchestration tools like ElizaOS vs. when to go lightweight, and how important it is to thoroughly understand asynchronous cross-chain behavior in production environments.