Over the past year, AI has stopped being just another trending label inside the Web3 community. More and more real problems are emerging: How should agents pay? How should wallets and permissions be designed when AI initiates onchain actions? How do developer tools actually plug into real workflows? Where do we need new protocols and standards instead of just wrapping old ideas in a new narrative?

Our view is straightforward: AI is likely to be one of the most important new growth directions worth positioning for in Web3 over the next 12–24 months. Not because it is hot, but because it is already developing an independent problem space — one that contains application opportunities, protocol opportunities, and entirely new infrastructure demands.

So what AI x Web3 School wants to do is not run another lively but short-lived event. We want to organize the entry point, the builders, and the knowledge assets around this direction earlier and more systematically.

What is AI x Web3 School?

AI x Web3 School (https://aiweb3.school/) is a cross-disciplinary AI × Web3 initiative jointly launched by LXDAO and ETHPanda.

Our first cohort will follow this structure:

• Bootcamp as the core: build a shared language, complete foundational training, and identify who is truly willing to commit.
• Hackathon as the extension: turn ideas into demos, repositories, and design docs.
• Handbook as the long-term archive: organize course content, problem maps, case studies, and strong projects into accessible bilingual assets.
• Showcase / Opportunity network as the output layer: make sure strong builders, projects, and partners can keep connecting after the program ends.

In other words, this is not a loose combination of teach first, then run a competition. It is a complete path:

Problem definition → Bootcamp training → Project execution → Public showcase → Talent and opportunity accumulation

Why don’t we just run a hackathon?

A one-off hackathon absolutely has value, but it comes with a well-known problem that people rarely solve seriously: it can easily attract participants who come mainly for prize money, but it is much harder to retain people who will keep building long term.

The common problems are roughly these:

1. Many teams form at the last minute just to compete, patch something together, and disappear as soon as the event ends.
2. Sponsors get a burst of brand exposure, but their products never truly enter developers’ daily workflows.
3. Organizers see submission counts, but it is hard to tell who really understands the problem and who just completed a short-term task.
4. After the event, the industry is left with very little reusable knowledge, very few reusable cases, and almost no lasting project network.