Urbit Docs
  • What is Urbit?
  • Get on Urbit
  • Build on Urbit
    • Contents
    • Environment Setup
    • Hoon School
      • 1. Hoon Syntax
      • 2. Azimuth (Urbit ID)
      • 3. Gates (Functions)
      • 4. Molds (Types)
      • 5. Cores
      • 6. Trees and Addressing
      • 7. Libraries
      • 8. Testing Code
      • 9. Text Processing I
      • 10. Cores and Doors
      • 11. Data Structures
      • 12. Type Checking
      • 13. Conditional Logic
      • 14. Subject-Oriented Programming
      • 15. Text Processing II
      • 16. Functional Programming
      • 17. Text Processing III
      • 18. Generic and Variant Cores
      • 19. Mathematics
    • App School I
      • 1. Arvo
      • 2. The Agent Core
      • 3. Imports and Aliases
      • 4. Lifecycle
      • 5. Cards
      • 6. Pokes
      • 7. Structures and Marks
      • 8. Subscriptions
      • 9. Vanes
      • 10. Scries
      • 11. Failure
      • 12. Next Steps
      • Appendix: Types
    • App School II (Full-Stack)
      • 1. Types
      • 2. Agent
      • 3. JSON
      • 4. Marks
      • 5. Eyre
      • 6. React app setup
      • 7. React app logic
      • 8. Desk and glob
      • 9. Summary
    • Core Academy
      • 1. Evaluating Nock
      • 2. Building Hoon
      • 3. The Core Stack
      • 4. Arvo I: The Main Sequence
      • 5. Arvo II: The Boot Sequence
      • 6. Vere I: u3 and the Serf
      • 7. Vere II: The Loom
      • 8. Vanes I: Behn, Dill, Kahn, Lick
      • 9. Vanes II: Ames
      • 10. Vanes III: Eyre, Iris
      • 11. Vanes IV: Clay
      • 12. Vanes V: Gall and Userspace
      • 13. Vanes VI: Khan, Lick
      • 14. Vanes VII: Jael, Azimuth
    • Runtime
      • U3
      • Conn.c Guide
      • How to Write a Jet
      • API Overview by Prefix
      • C in Urbit
      • Cryptography
      • Land of Nouns
    • Tools
      • Useful Links
      • JS Libraries
        • HTTP API
      • Docs App
        • File Format
        • Index File
        • Suggested Structure
    • Userspace
      • Command-Line App Tutorial
      • Remote Scry
      • Unit Tests
      • Software Distribution
        • Software Distribution Guide
        • Docket File
        • Glob
      • Examples
        • Building a CLI App
        • Debugging Wrapper
        • Host a Website
        • Serving a JS Game
        • Ship Monitoring
        • Styled Text
  • Urbit ID
    • What is Urbit ID?
    • Azimuth Data Flow
    • Life and Rift
    • Urbit HD Wallet
    • Advanced Azimuth Tools
    • Custom Roller Tutorial
    • Azimuth.eth Reference
    • Ecliptic.eth Reference
    • Layer 2
      • L2 Actions
      • L2 Rollers
      • L2 Roller HTTP RPC-API
      • L2 Transaction Format
  • Urbit OS
    • What is Urbit OS?
    • Base
      • Hood
      • Threads
        • Basics Tutorial
          • Bind
          • Fundamentals
          • Input
          • Output
          • Summary
        • HTTP API Guide
        • Spider API Reference
        • Strandio Reference
        • Examples
          • Child Thread
          • Fetch JSON
          • Gall
            • Poke Thread
            • Start Thread
            • Stop Thread
            • Take Facts
            • Take Result
          • Main-loop
          • Poke Agent
          • Scry
          • Take Fact
    • Kernel
      • Arvo
        • Cryptography
        • Move Trace
        • Scries
        • Subscriptions
      • Ames
        • Ames API Reference
        • Ames Cryptography
        • Ames Data Types
        • Ames Scry Reference
      • Behn
        • Behn API Reference
        • Behn Examples
        • Behn Scry Reference
      • Clay
        • Clay API Reference
        • Clay Architecture
        • Clay Data Types
        • Clay Examples
        • Clay Scry Reference
        • Filesystem Hierarchy
        • Marks
          • Mark Examples
          • Using Marks
          • Writing Marks
        • Using Clay
      • Dill
        • Dill API Reference
        • Dill Data Types
        • Dill Scry Reference
      • Eyre
        • EAuth
        • Eyre Data Types
        • Eyre External API
        • Eyre Internal API
        • Eyre Scry Reference
        • Low-Level Eyre Guide
        • Noun channels
      • Gall
        • Gall API Reference
        • Gall Data Types
        • Gall Scry Reference
      • Iris
        • Iris API Reference
        • Iris Data Types
        • Iris Example
      • Jael
        • Jael API Reference
        • Jael Data Types
        • Jael Examples
        • Jael Scry Reference
      • Khan
        • Khan API Reference
        • Khan Data Types
        • Khan Example
      • Lick
        • Lick API Reference
        • Lick Guide
        • Lick Examples
        • Lick Scry Reference
  • Hoon
    • Why Hoon?
    • Advanced Types
    • Arvo
    • Auras
    • Basic Types
    • Cheat Sheet
    • Cryptography
    • Examples
      • ABC Blocks
      • Competitive Programming
      • Emirp
      • Gleichniszahlenreihe
      • Islands
      • Luhn Number
      • Minimum Path Sum
      • Phone Letters
      • Restore IP
      • Rhonda Numbers
      • Roman Numerals
      • Solitaire Cipher
      • Water Towers
    • Generators
    • Hoon Errors
    • Hoon Style Guide
    • Implementing an Aura
    • Irregular forms
    • JSON
    • Limbs and wings
      • Limbs
      • Wings
    • Mips (Maps of Maps)
    • Parsing Text
    • Runes
      • | bar · Cores
      • $ buc · Structures
      • % cen · Calls
      • : col · Cells
      • . dot · Nock
      • / fas · Imports
      • ^ ket · Casts
      • + lus · Arms
      • ; mic · Make
      • ~ sig · Hints
      • = tis · Subject
      • ? wut · Conditionals
      • ! zap · Wild
      • Constants (Atoms and Strings)
      • --, == · Terminators
    • Sail (HTML)
    • Serialization
    • Sets
    • Standard Library
      • 1a: Basic Arithmetic
      • 1b: Tree Addressing
      • 1c: Molds and Mold-Builders
      • 2a: Unit Logic
      • 2b: List Logic
      • 2c: Bit Arithmetic
      • 2d: Bit Logic
      • 2e: Insecure Hashing
      • 2f: Noun Ordering
      • 2g: Unsigned Powers
      • 2h: Set Logic
      • 2i: Map Logic
      • 2j: Jar and Jug Logic
      • 2k: Queue Logic
      • 2l: Container from Container
      • 2m: Container from Noun
      • 2n: Functional Hacks
      • 2o: Normalizing Containers
      • 2p: Serialization
      • 2q: Molds and Mold-Builders
      • 3a: Modular and Signed Ints
      • 3b: Floating Point
      • 3c: Urbit Time
      • 3d: SHA Hash Family
      • 3e: AES encryption (Removed)
      • 3f: Scrambling
      • 3g: Molds and Mold-Builders
      • 4a: Exotic Bases
      • 4b: Text Processing
      • 4c: Tank Printer
      • 4d: Parsing (Tracing)
      • 4e: Parsing (Combinators)
      • 4f: Parsing (Rule-Builders)
      • 4g: Parsing (Outside Caller)
      • 4h: Parsing (ASCII Glyphs)
      • 4i: Parsing (Useful Idioms)
      • 4j: Parsing (Bases and Base Digits)
      • 4k: Atom Printing
      • 4l: Atom Parsing
      • 4m: Formatting Functions
      • 4n: Virtualization
      • 4o: Molds
      • 5a: Compiler Utilities
      • 5b: Macro Expansion
      • 5c: Compiler Backend & Prettyprinter
      • 5d: Parser
      • 5e: Molds and mold builders
      • 5f: Profiling support
    • Strings
    • The Engine Pattern
    • Udon (Markdown-esque)
    • Vases
    • Zuse
      • 2d(1-5): To JSON, Wains
      • 2d(6): From JSON
      • 2d(7): From JSON (unit)
      • 2e(2-3): Print & Parse JSON
      • 2m: Ordered Maps
  • Nock
    • What is Nock?
    • Decrement
    • Definition
    • Fast Hints and Jets
    • Implementations
    • Specification
  • User Manual
    • Contents
    • Running Urbit
      • Cloud Hosting
      • Home Servers
      • Runtime Reference
      • Self-hosting S3 Storage with MinIO
    • Urbit ID
      • Bridge Troubleshooting
      • Creating an Invite Pool
      • Get an Urbit ID
      • Guide to Factory Resets
      • HD Wallet (Master Ticket)
      • Layer 2 for planets
      • Layer 2 for stars
      • Proxies
      • Using Bridge
    • Urbit OS
      • Basics
      • Configuring S3 Storage
      • Dojo Tools
      • Filesystem
      • Shell
      • Ship Troubleshooting
      • Star and Galaxy Operations
      • Updates
Powered by GitBook

GitHub

  • Urbit ID
  • Urbit OS
  • Runtime

Resources

  • YouTube
  • Whitepaper
  • Awesome Urbit

Contact

  • X
  • Email
  • Gather
On this page
  • Moving a pre-existing ship to L2
  • Dominion
  • Planets
  • %l1 planets
  • %l2 planets
  • Stars
  • %l1 stars
  • %spawn stars
  • %l2 stars
  • Galaxies
  • %l1 galaxies
  • %spawn galaxies
Edit on GitHub
  1. Urbit ID
  2. Layer 2

L2 Actions

There are a total of eleven layer 2 actions, each corresponding to a familiar layer 1 action: %transfer-point, %spawn, %configure-keys, %escape, %cancel-escape, %adopt, %reject, %detach, %set-management-proxy, %set-spawn-proxy, and %set-transfer-proxy. Descriptions of what these actions do may be found by searching for them at Azimuth.eth.

Once a ship moves to layer 2, the owner will still utilize the same private keys they used before the transfer to perform Azimuth actions. This includes the ownership key as well as proxies. Stars and galaxies may move their spawn proxy to layer 2 while otherwise remaining on layer 1, but it is not possible to transfer only the management proxy to layer 2; it may only happen as a side-effect of transferring ownership to layer 2.

Moving a pre-existing ship to L2

In order to move your ship from layer 1 to layer 2, transfer ownership of your ship to the address 0x1111111111111111111111111111111111111111. The easiest way to accomplish this is using Bridge. The Azimuth smart contracts interpret any ship at this address as being on layer 2.

Dominion

Layer 2 Azimuth data for a given ship includes which layer that ship is on. We call this the ship's dominion. There are three dominions: %l1, l2, and %spawn. Planets may exist in dominion %l1 or %l2, stars may exist in any of the three dominions, and galaxies may exist in dominion %l1 or %spawn. We detail what this means in each case in the following.

Planets

Permitted dominions: %l1, %l2.

%l1 planets

Permitted layer 2 actions:

  • owner: %escape, %cancel-escape

  • management proxy: %escape, %cancel-escape

  • transfer proxy: none

A planet in dominion %l1 is said to exist on layer 1, which is the default state for all planets prior to the introduction of naive rollups. In addition to the ordinary layer 1 Azimuth actions a planet can perform, they may also choose to %escape or %cancel-escape on layer 2 using either their ownership key or management proxy. See the layer 2 sponsorship section for more information on layer 1 ships performing layer 2 sponsorship actions.

Layer 1 planets may also move to dominion %l2 by depositing their ownership to the layer 2 deposit address.

%l2 planets

Permitted layer 2 actions:

  • owner: %transfer-point, %configure-keys,%escape, %cancel-escape, %set-management-proxy, %set-transfer-proxy

  • management proxy: %configure-keys, %escape, %cancel-escape,%set-management-proxy

  • transfer proxy: %transfer-point, %set-transfer-proxy

A planet in dominion %l2 is said to exist on layer 2. A planet may be on layer 2 either by previously being a layer 1 planet deposited to the layer 2 address, or by being spawned by a star in dominion %spawn or %l2, in which case it will always be on layer 2.

A layer 2 planet is no longer capable of performing any layer 1 actions, and cannot move to layer 1.

Stars

Permitted dominions: %l1, %spawn, %l2.

%l1 stars

Permitted layer 2 actions:

  • owner: %escape, %cancel-escape, %adopt,%reject, %detach

  • management proxy: %escape, %cancel-escape, %adopt,%reject, %detach

  • spawn proxy: none

  • transfer proxy: none

A star in dominion %l1 is said to exist on layer 1, which is the default state for all stars prior to the introduction of naive rollups. In addition to the ordinary Azimuth actions a star can perform, they may also perform any sponsorship-related actions on layer 2.

A %l1 dominion star may move to dominion %spawn by depositing its spawn proxy to the layer 2 deposit address, or may move to dominion %l2 by depositing its ownership to the layer 2 deposit address. Both actions are irreversible.

%spawn stars

Permitted layer 2 actions:

  • owner: %escape, %cancel-escape, %adopt,%reject, %detach, %spawn, %set-spawn-proxy

  • management proxy: %escape,%cancel-escape, %adopt, %reject, %detach

  • spawn proxy: %spawn,%set-spawn-proxy

  • transfer proxy: none

A star in dominion %spawn is said to exist on layer 1.

A star in dominion %spawn may spawn planets directly on layer 2, but will no longer be able to spawn layer 1 planets and will no longer be able to set its spawn proxy on layer 1. All other layer 1 Azimuth actions may still be performed by the star.

A star moving from %l1 to %spawn has no effect on sponsorship status of any of its sponsored planets. Moving to %spawn from %l1 is currently irreversible - the only further change to dominion permitted is moving to %l2.

%l2 stars

Permitted layer 2 actions:

  • owner: %transfer-point, %spawn, %configure-keys, %escape,%cancel-escape, %adopt, %reject, %detach, %set-management-proxy,%set-spawn-proxy,%set-transfer-proxy

  • management proxy: %escape,%cancel-escape, %adopt, %reject, %detach, %configure-keys,%set-management-proxy

  • spawn proxy: %spawn, %set-spawn-proxy

  • transfer proxy: %transfer-point, %set-transfer-proxy

A star in dominion %l2 is said to exist on layer 2. A star may exist on layer 2 by being deposited to the layer 2 deposit address from layer 1, or by being spawned by a %spawn dominion galaxy.

A star in dominion %l2 cannot perform any layer 1 actions.

Galaxies

Permitted dominions: %l1, %spawn.

%l1 galaxies

Permitted layer 2 actions:

  • owner: %adopt, %reject, %detach

  • management proxy: %adopt, %reject, %detach

  • spawn proxy: none

  • transfer proxy: none

  • voting proxy: none.

A galaxy in dominion %l1 is said to exist on layer 1, which is the default state for all galaxies prior to the introduction of naive rollups. In addition to the ordinary Azimuth actions a galaxy can perform, they may also perform any sponsorship-related actions on layer 2. %l1 galaxies can perform all the usual layer 1 Azimuth actions, and may also perform layer 2 sponsorship actions.

A %l1 dominion galaxy may move to dominion %spawn by depositing its spawn proxy to the layer 2 deposit address. This action is irreversible. Note, however that the majority of galaxies already have all of their stars spawned in the Linear Star Release Contract. Layer 2 has no interactions with this contract - all stars released in this manner are %l1 dominion stars. Moving to the %spawn dominion has no effect on sponsorship status.

%spawn galaxies

Permitted layer 2 actions:

  • owner: %adopt, %reject, %detach, %spawn, %set-spawn-proxy

  • management proxy: %adopt, %reject, %detach

  • spawn proxy: %spawn, %set-spawn-proxy

  • transfer proxy: none

  • voting proxy: none

Galaxies may either remain on layer 1, or, similar to stars, they may deposit their spawn proxy to layer 2. They cannot move their ownership, management proxy, or voting proxy to layer 2. However, as with stars, sponsorship actions may be performed on layer 2 using the ownership or management proxies regardless of the dominion status of the galaxy.

PreviousLayer 2NextL2 Rollers

Last updated 1 day ago