Modules
A module is a JSON descriptor for a task you’d otherwise build by hand. The Home page’s Modules panel shows them side-by-side with a chip indicating type:
- Green chip — onchain module (mint, claim, etc.).
- Blue chip — social module (signup form, quest submission).
Click any module’s Create Tasks button to open the Build dialog pre-filled with the module’s settings. You still pick the wallet group (onchain) or account group (social).
Why modules exist
For repeated drops on the same launchpad (e.g., a new collection on a known contract pattern), or for sites the community has reverse-engineered the API for, the team publishes a module so you don’t redo the recon yourself.
Modules update from the license-worker on app launch — there’s no manual sync. If a contract pattern changes, the module is updated server-side and the next launch picks it up.
Where they come from
The license-worker at license.zyper.app serves:
GET /v1/modules— onchain templates.GET /v1/social-modules— off-chain templates.
The app fetches both on launch and caches them. There’s no client-side editing — modules are read-only from the desktop side.
Pinning vs badging
The admin dashboard can mark modules as:
- Pinned — sticky at the top of the Modules panel on Home.
- Badged — a small label like
new,live, orpopular.
These are pure UI affordances. Functionally a pinned module behaves identically to an unpinned one.
When to use vs build from scratch
| Use the module | Build from scratch |
|---|---|
| Module description matches your drop exactly. | Slight variant (different mint price, different qty). |
| You haven’t done this contract before. | You’ve already optimized the args yourself. |
| Social site has a published module. | Site changed since the module was published. |
Hitting Create Tasks on a module copies the descriptor into a regular task, so you can override fields if you need to deviate.