Chainstation Alpha is a big station, with plenty to do, but there's a universe of possibilities out there beyond even this one station. MoonCats and other digital residents who wish to begin their adventure can do so via the JumpPort! Whether they wish to explore exciting new realms on the boundaries of charted space, or take some time to explore on their own without their Etherian owners, an unlimited amount of adventures await!
Scientists who study the mysteries of Deep Space have found other places to travel to beyond our spacetime, and in order to get there, specialized ships, tools, or means need to be employed to exit Chainstation Alpha's spacetime and enter another. One technique that the scientists are exploring is creating Portals to these other realms. Some Portals allow ships and denizens to transport fully to the other side, like walking across a bridge to a new shore. Other portals allow seeing through or projecting one's digital self to another place, while your physical self remains safe at Chainstation Alpha.
This guide is intended for end-users; if you're a builder and looking to add JumpPort functionality to a project, you'd likely be more interested in this guide.
The JumpPort is a single smart contract that serves as a custodial place for ERC721-compliant tokens to be held and tracked by other smart contracts. Owners of tokens may deposit the token into the JumpPort and may withdraw it at a later time. The JumpPort tracks ownership and only allows tokens being withdrawn to be delivered back to the address that originally deposited it. There is one exception to the JumpPort Administrators rescuing a token by withdrawing it; see the "Governance" section for details.
The JumpPort only allowing tokens to return to their original depositors is an added layer of security that means even if the original owner was tricked into signing a transaction to withdraw their assets from the JumpPort, they would not end up in an attacker's possession from that one transaction.
Tokens deposited into the JumpPort can be withdrawn by their original owner at any time, unless the token has become locked. To lock a token, one must interact with a Portal. Portals are smart contracts that interact with the JumpPort, and if the JumpPort Governance approves of a specific Portal contract, that Portal can then use its logic to set when a token becomes locked or unlocked in the JumpPort. This logic will vary from Portal to Portal, depending on the needs of the application it is supporting.
Similar to how the ERC721 standard allows owners to "approve" other addresses to act on their behalf for tokens they own, the JumpPort allows designating a different address as a Copilot, which grants them the ability to interact with Portals on behalf of the token's owner.
While there is only one JumpPort contract, there are many different Portal contracts, and more can be developed by additional projects that wish to interact with the JumpPort. When a smart contract is designated as a Portal by the JumpPort Governance process, it gains the ability to lock and unlock tokens in the JumpPort. Multiple Portals can set a lock on a specific token, and that token will be unable to be withdrawn until all the locks are cleared.
Users can browse the list of available Portals and can interact with any or all at once.
The JumpPort is set up in such a way that the end user is able to choose when and if their tokens get locked into the JumpPort. Once a token is locked, an individual owner will not be able to break the commitment they made to keep it locked for as long as the application infrastructure they interacted with requires. For example, if a Portal were created to prove a user's "diamond paws" by locking up a token for a month, it would defeat the purpose if the end user could decide to back out of the arrangement. To ensure that a user cannot be tricked into signing a transaction that locks up their tokens in a way they didn't expect (phished/social engineering attacks), the JumpPort has a governance system built in where a smart contract must be approved to be a Portal before it is allowed to lock tokens.
Addresses that are designated as Administrators of the JumpPort contract can approve and revoke other smart contracts being designated as Portals. Administrator addresses can also set a preference that a given Portal's locks are all invalid. This administrator ability is intended to be used to assist if there were to be a collapse of an application using a side chain. Portals that act as "bridges" to other chains could cause tokens to become stuck if the other chain's ability to message the JumpPort failed. This ability allows the Administrators to react in this situation and unlock the tokens that would otherwise be stuck.
Administrators can also rescue tokens that were deposited into the JumpPort incorrectly. In order to be successfully credited as the owner of a token in the JumpPort, the token should be sent with the "Safe Transfer From" function, or using the "Approve, then Deposit" functions. If the ERC721 "Transfer From" function is used (the one without the "safe" prefix), the ownership of the token will not be properly recorded. In this case, the former owner will lose access to it. Administrators are able to withdraw tokens that were sent in this incorrect way, and make a decision as to where they should be transferred.
If a user has lost their private key, and therefore cannot interact with their tokens in the JumpPort, the Administrators can initiate a process that starts a one year timeout. This requests that the owner of the token trigger a response message. If that user has indeed lost their private key, then after one year, an Administrator can withdraw the token and return it to them. Why the one year wait? This makes it harder for bad actors to abuse this process by posing as the owner of a token. Say for example a nefarious user named Eve claims that she is the owner of MoonCat #1289, who at the time is in the JumpPort. Eve says she doesn't have her private key any more, and therefore cannot prove it. If she manages to spin a tale convincing-enough for an Administrator to start the process to attempt to recover that MoonCat for her, there is then a one year window of time for the real owner to notice their response is needed and make an on-chain transaction to prove that they are the owner. That will cancel the request, and should clearly indicate to the Administrators that Eve is lying.
Initially, Governance of the JumpPort will rest solely with ponderware, but as the use of the JumpPort grows to include other teams, it will eventually transition to a multi-sig/DAO structure. The other projects will then be able to participate in the governance of the JumpPort.
You made it to the end! If you're still interested in learning more about the JumpPort and Portal Network, this guide will provide more technical details.