| UIP | Title | Description | Author | Status | Type | Category | Created |
|---|---|---|---|---|---|---|---|
0132 |
Planet Token |
Externalize spawn capacity as an ERC20 token |
~master-malwyl |
Draft |
Standards Track |
PKI |
~2025.1.26 |
This proposal aims to integrate Urbit’s address space with the broader decentralized finance ecosystem by introducing a fungible ERC20 token called URBIT to represent each star’s unspawned planets. By externalizing that capacity into a standalone ERC20, star owners can convert their unspawned planets into tokens for trading, collateralization, or other DeFi activities, all while retaining the star’s existing functionality. The proposal also establishes a Senate-controlled Ministry contract, which initially serves as a deposit address for naive rollup migrations and may be expanded to support bidirectional migrations across different consensus environments in future proposals.
The current model treats spawn capacity as an intrinsic property of star ownership through NFTs. While NFTs excel at representing unique digital property, their non-fungible nature keeps address space largely isolated from major cryptocurrency markets and DeFi protocols. Currently, stars can only trade their planets by selling their entire star NFT or spawning and selling each planet individually. Although NFT marketplaces exist, they are poorly suited for continuous or high-volume trading. Converting spawn capacity to fungible planet tokens through the ERC20 standard opens up the broader landscape of blockchain infrastructure, allowing for access to deeper liquidity and capital flows.
To introduce this system with minimal disruption, the following sequence is required:
- Senate approval of the proposal and contract code
- Deployment of the
PlanetToken,PlanetTreasury, andMinistrycontracts, with no initial supply - Updating
Eclipticto reference the new contracts - Releasing updates to
roller.hoonandnaive.hoonfor validation rule alignment - Executing a one-time token minting process
The PlanetToken contract implements the standard ERC20 interface as a non-upgradeable contract with initial total supply calculated as (65,280 stars × 65,535 planets) minus all previously spawned planets.
The PlanetTreasury is an upgradable contract designed to hold the initial token supply in escrow. Tokens remain locked in escrow until they are either withdrawn by the star owner through the withdrawCapacity function or burned during the planet spawning process. A hasCapacity mapping is used to track whether a star’s tokens are still held in escrow, which determines if the star maintains its ability to spawn planets. The star's spawning capacity can be replenished by invoking the depositCapacity function, where the star owner deposits tokens equivalent to the number of unspawned planets associated with the star.
During the spawn process, Ecliptic verifies that a star’s hasCapacity is true and then instructs PlanetTreasury to burn tokens on that star’s behalf.
For previously migrated stars assigned to the address 0x111...111, capacity tokens are assigned to the Ministry contract by default. This allows for potential reconciliation if such stars return to the primary chain in the future.
Several modifications to Ecliptic are required to accommodate ERC20-based spawn capacity. Upon an attempted spawn, Ecliptic checks if the star has capacity in PlanetTreasury. If not, the spawn fails; if it does, PlanetToken burns the necessary token(s). A new migrate function is also introduced, enabling point ownership to transfer to the Ministry contract. This function emits a PointMigrated event to inform roller agents of a valid migration.
The Ministry contract is Senate-controlled and serves as a secure vault for points migrating from L1 to alternative consensus environments. Any migration must pass through Ecliptic’s new migrate function, placing custody of the point under Ministry. The Senate may later decide how to approve or release points from this vault, and the contract could be expanded to handle cross-chain transfers or reverse migrations in future proposals.
Updates to roller.hoon and naive.hoon will distinguish distinguish between migrations made before and after this new system is live. Transfers to the legacy deposit address remain valid under existing naive rules if they happened before a specific block height, whereas points must use Ministry to migrate once the new system is active. This structure clearly differentiates legacy and modern migration processes and preserves all historical state on the existing secondary layer.
This approach intentionally keeps the Azimuth system intact and avoids redeploying the Azimuth contract. Since Azimuth is non-upgradeable, it cannot simply accept a new field such as hasCapacity for all star points. Although this design results in two “sources of truth”—one for ownership and one for capacity—it prevents a network-wide overhaul.
Tokenizing planets without altering the underlying Point struct follows a minimal-disruption philosophy. Owners uninterested in ERC20 markets can retain their spawn capacity in escrow as before, while others can move capacity into a liquid ERC20 market. The Ministry contract further extends this idea by acting as a more flexible deposit address for naive rollups, with the potential to evolve into a fully bidirectional bridging mechanism for L1 and L2 interactions.
This design balances trade-offs between architectural purity, system complexity, and practicality of deployment. By tokenizing spawn capacity, the proposal connects Urbit’s address space with established DeFi markets and trading venues, unlocking greater liquidity, price discovery, and economic possibilities. Although participation in this token-based system is optional, it can serve as a catalyst for broader awareness and engagement, drawing more attention to Urbit’s address space and fostering deeper integration with the wider blockchain ecosystem.