---
# System prepended metadata

title: Bandwidth Protocol

---

# Bandwidth Protocol
### Why Bandwidth protocol?
When a user buys the VPN bandwidth from the provider there is a possibility of cheating in terms of bandwidth since there are no proofs that the provider provided the specified bandwidth and user consumed the bandwidth unless they both record all the datagrams. But in the current situation, the user is blindly trusting the provider and whatever the provider says about the bandwidth consumption. So to eliminate this trust factor both need a new protocol/service kind of thing which never logs entire datagrams but gives a rough estimation of consumption with proofs.

### Protocol level bandwidth proofs
In this VPN protocol, the client and server maintain their own private keys where these private keys are used for creating the signatures. For every X packets that are transferred between the client and server, the client and server share the signatures between each other saying the server provided Y bytes of data, and client received Z bytes of data. Here the difference between Y and Z is called as error rate which can be between 0-10% of total bandwidth transferred. This error can happen because of protocol level compression and retransmission of packets in case there is a loss. This error rate can be configured by the user and the provider.

### Bandwidth proofs exchange as a service
In this scenario, a service will be running at server and client where these services will connect to each other and maintain a state channel. These services will be monitoring all the packets (just packet size) between each other and for every X seconds or Y bytes, they both share the bandwidth signatures. If any of these services fail to share the signature in specified TTL they break the VPN connection. Finally, when there is an interruption in the VPN connection one of the services (mostly server-side service) will commit the latest signature to the blockchain where the settlement of bandwidth consumption will happen.