The PAKET project encourages developers with feature rewards and bug bounty programs. If you are interested in contributing to the project and earning money for it, please visit our incentives page.
As a project that revolves around decentralization, PAKET uses and produces free, libre and open-source software, the PAKET protocol is open and the PAKET network if fully transparent. We believe that everyone stands to profit from more and more players joining the ecosystem and enriching it, so we wish to make it as easy and simple as possible to hop on the wagon and join in on the ride.
The PAKET protocol is fully decentralized and open, and you can use it directly over the Stellar public network. If you are familiar with Stellar and wish to take that route, simply head over to the Working with Stellar documentation. Most developers, however, prefer to develop on a higher level. That's where the PAKET API server comes in.
The PAKET API server is a bridge, constructed from HTTP and JSON, between applications and the underlying PAKET protocol. To run your own instance of the PAKET API server just follow the instructions on the README page. To use the API you will need to meet the following requirements:
Once you meet these three requirements, you can experiment with our endpoints from our live API page. To get right down to business and launch a package, just follow the walkthrough (pay close attention to the authentication process).
The PAKET Protocol establishes trust and enables the cooperation between multiple parties on the safe and timely delivery of goods. For modularity and robustness, the protocol is divided into the following layers:
This layer establishes a decentralized consensus regarding the conditional transfer of value, as well as an inspectable, immutable history of that consensus. Our current L0 is Stellar, so it is advised that you familiarize yourself with its basic workings. Especially Assets and the different Signer Types.
This layer defines the cryptographic tokens and the smart contracts which govern its behaviour.
On the logical level, what we do is quite simple. For every package that a user wants to send (we call such a user a Launcher), we create an escrow into which the Launcher deposits his promised Payment. The escrow has a predefined Recipient and a predefined Courier, and once the Recipient confirms the receipt of the package, the Payment is released to the Courier. The escrow also had a predefined Deadline, and if the Courier fails to deliver the package to the Recipient by the time the Deadline passes, the escrow will release the Payment back to the Launcher as refund.
In addition, the Launcher can demand that the Courier deposits a Collateral into the escrow, as a form of insurance for the package. Once the Recipient confirms the receipt of the package, the escrow will release the Collateral to the Courier along with the Payment, but if the Deadline passes before that, the escrow will pay the Collateral to the Launcher along with his refunded Payment.
The only remaining bit is the relay. A Courier who is given a package to transport can relay the package to another Courier, promising him a part of the Payment, to be paid only when the Recipient confirms the receipt of the package. The relaying Courier can also demand that the new Courier cover his Collateral, in which case the new Courier deposits the Collateral into the escrow (to be returned only upon successful delivery) and the relaying Courier is given his Collateral back.
This layer matches requirements of senders with capacity and cost of couriers, while providing a detailed and highly contextualized view into the supply and demand of the market. Our current implementation is very rough, but the fundamental idea is a p2p communication network that handles publication and matching of launcher requirements with courier capacities.
Communication on the network is authenticated using the same keypairs from the two lower layers, which enables secure, robust, and simple pinning of identities through the layers.
This layer consolidates tools and applications that allow simple and intuitive usage of the network. It is in very early stages of development, and currently consists of only two projects:
This layer builds organizations and services that thrive in the PAKET ecosystem and enrich it. We have some interesting plans regarding it, but no current implementations.
Our Stellar library - implementing the Stellar side of the PAKET layer(L1)
Our bridge server - functioning as a bridge between Stellar Horizon servers and user applications, providing access to the PAKET layer (L1)
Our routing server - providing a temporary centralized routing layer (L2)
Our funding server - providing tokens to those who wish to use them
Our manager scaffolding - providing scripts for deploying, updating, testing, and running our servers
The first mobile app to use PAKET - enabling simple, decentralized deliveries
Our branch of the stellar-core Python package - we occasionally get the chance to contribute to the official Python package!