multiversx-factory-manager_skill

Overview

This skill implements a factory/manager pattern for deploying, tracking, and upgrading child smart contracts from a single template. It is designed for use cases that need many identical or near-identical contract instances, with admin-controlled deployment and upgrade flows. The manager includes a registry, template management, and role checks for secure lifecycle operations.

How this skill works

The manager stores a template address and uses from_source() to clone new child instances with configurable CodeMetadata (e.g., UPGRADEABLE, READABLE, PAYABLE). Each deploy call registers the new child in a SetMapper for iteration and a SingleValueMapper keyed by ID for O(1) lookup. Upgrades call the child proxy upgrade() to replace code from the current template, guarded by admin checks and a require_managed_child validation.

When to use it

• When you need many instances of the same contract (per user, market, pool).
• When each tenant or user must have an isolated contract instance.
• When you want centralized lifecycle control (deploy, track, upgrade).
• When you need O(1) lookup by ID plus the ability to iterate all children.
• When children must be upgradeable over time without redeploying users’ data.

Best practices

• Always include CodeMetadata::UPGRADEABLE when deploying children you may upgrade later.
• Maintain both a SetMapper (for iteration/contains) and a SingleValueMapper (ID → address) for efficient operations.
• Enforce admin/owner checks for deploy and upgrade endpoints to prevent unauthorized changes.
• Validate that a target address is in the registry before performing upgrades or admin actions.
• Use READABLE and PAYABLE flags only when the child requires cross-contract reads or direct payments.

Example use cases

• A marketplace that spawns one sale contract per listing and later upgrades logic for all active listings.
• A launchpad that deploys a managed token sale contract for every project with centralized upgrades and tracking.
• A multi-tenant protocol where each tenant has an isolated contract instance tied to an ID for permissions and billing.
• A lending protocol that creates a pool contract per collateral type and needs to iterate and upgrade pools.
• A subscription system that provisions a per-subscriber contract to hold state and payments.