In today’s article, we will focus on the financial aspects of Bitpost. Let’s take a closer look at service pricing, rewards, governance and the token associated with it. Or rather more than one token?

1. Shipping fee

The most important question worth discussing is how to design a pricing model for Bitpost delivery services? What mechanisms should determinate the shipping fee paid by customers and what factors should affect it?

First, let’s consider a fixed price for any kind of parcel, stored in the Bitpost’s smart contracts, which can be updated by the project community voting. In such a model, the profitability of handling the parcel by network members would be too much variable depending on the distance between the sender and the recipient. When the parcel would be addressed to the same city, the entire shipping fee would be paid to a single courier, while in the case of a long-distance international shipment, the fee amount would be divided among so many participants that the individual courier’s share in the profit would have only symbolic value. Additionally, a fixed price valid all over the world is not a good idea, for example due to differences in fuel prices around the world. Being a Bitpost courier could be more profitable in some countries than others.

Also any variations based on a fixed rate has its own drawbacks. For example, in the case of a fixed price per 1 mile of distance, Bitpost’s services would be uncompetitive with traditional delivery companies that charge a flat fee regardless of distance. On the other hand, a fixed fee per 1 routing hop, although it seems to be the most reasonable model of those mentioned so far, does not fully fit the dynamics of the Bitpost network. The shipment route (and thus also the number of hops) may change many times during its transportation, but the customer should know the final shipping fee before it’s shipped.

That’s why we left the price for Bitpost services to the principles of free market. Bitpost services will not have any fixed price. The sender of the parcel will be able to pay as much as they want and couriers will only pick up shipments whose fees are high enough to make that carriage profitable. By observing previous transactions, it will be possible to estimate what fee is sufficient for a given geographic area, distance of the sender and recipient, etc. Overpriced shipments will be a tasty morsel for couriers so they will be transported in the blink of an eye. On the other hand, underpriced shipments still have a chance to reach the recipient. After all, if a driver goes from the hub A to hub B with shipments those are already profitable for him, why wouldn’t he fill the remaining space in the car with some less profitable ones. Ultimately, if it happens that an underpaid shipment luckily completes half of its route, but later gets stuck in some hub and no courier is interested in moving it further, the sender, the recipient, or even any third party can make an additional payment to the smart contract of parcel. Only in this model, fees in individual areas are self-adaptive to all local economic conditions, fuel prices, etc., and that’s exactly what we need for Bitpost.

This model was inspired by how transaction fees work on most blockchains. There, the user can also basically pay any fee, but only an appropriately estimated amount guarantees quick transaction execution. Overpriced transactions get included into the block first, and underpriced ones usually also get confirmed after a longer wait and if they don’t, you just have to pay extra.

2. Rewarding members

When it comes to rewarding the Bitpost network participants, we actually considered two models. The first one is the most similar to the operaton of traditional companies. The Bitpost protocol does not control the supply of its token, the supply is fixed, and all rewards for network members comes directly from the distribution of shipping fees collected from customers. The balance of collected fees and rewards paid must be zero and no shipments handled means no profit.

In the second model, the Bitpost protocol controls the supply of its token, the shipping fee paid by the client is burned, and the tokens rewarding network members are minted. Rewards for participants do not have to be strictly associated with fees came from handled shipments. A courier who does not have any available transport orders but is on standby for them can still earn some base reward, the same applies to a hub in a less populated area.

While most crypto projects would definitely choose the second model, we strongly do not agree with generating value out of thin air. The Bitpost’s settlement currency must be stable enough to be used for long-term security deposits, and increasing its supply without increasing demand for Bitpost’s services is a straight path to zero value. Additionally, the possibility of earning money without verifiably performed work in a trustless environment like Bitpost opens the door to new frauds. We would certainly soon see a lot of hubs and couriers registered in the middle of the ocean, robbing the protocol of money on a daily basis, while never handling a single parcel. For these reasons, we decided to choose the first mentioned model for the final Bitpost implementation.

3. Billing token

Imagine your local grocery accepts payments only in its own token. To pay your phone and internet bill, you need some MobileCoins and FiberCoins. You can’t go to the doctor without exchanging some funds for DocCoins, and if you would like to refuel your car, prepare some PetrolCoins in advance. Sounds like a nightmare, but in the world of decentralized applications it is commonplace.

We do not support this approach. We believe that instead of creating a separate currency for each project, decentralized application should focus on accepting payments in general purpose cryptocurrencies that are already in their users’ wallets. That’s why we created a general-purpose cryptocurrency – BPX. Apart from being the exclusive payment method for Bitpost, in the future it will power the entire range of our other projects and today it is already open for 3rd party developers. Fair distribution of new coins through super energy efficient mining on physical hardware combined with deflationary properties makes BPX a token that meets all the needs of Bitpost settlement currency.

4. Governance

On the other hand, if Bitpost is to conquer the world, the project needs considerable funding, but the fair distribution of BPX coin excludes the possibility of conducting an Initial Coin Offering (ICO). As a fully decentralized, community-managed project, it also needs some governance solutions. As with traditional joint-stock companies, there is no need for every Bitpost user to also be a “shareholder” of the project. After all, the vast majority of customers who will use Bitpost just to pick up a few packages from time to time, would not be active in governance discussions and votings. That’s why BPG – The Bitpost Governance token – comes into play. It will be a fixed supply, one-time emission ERC-20 token giving its holders an access to voting on the further development of the project, proposing updates, and participating in the profits achieved by Bitpost as a whole. The only way to obtain the BPG will be through the ICO and then by purchasing it from the market.

Conclusion

If we compared Bitpost to a traditional company, BPX would be the currency used for buying the company products and paying employee salaries, and BPG would be the company’s shares:


BPX

BPG
A native coin of its blockchain.An ERC-20 token.
• paying shipping fees
• rewarding hubs, couriers, lockers and BPG holders
• security deposits
• compensation for lost or damaged shipments
• participating in votes on changes to the Bitpost protocol
• proposing changes to the Bitpost protocol
• share in the profits generated by the project

To summarize, the Bitpost will use two different cryptoassets according to the rules explained in this article. These two tokens are intended for different purposes and tailored to optimally meet the needs of users, network members and investors.