Technology
Implementation
QBUX is currently an ERC-20 token running on the Ethereum protocol. In the future, versions of QBUX running on other protocols may be developed, exchangeable 1-1 with the current QBUX token.
When Communities install a Widget from a Hosting company on their website, they initiate a Trustline with this Hosting Company. This Trustline represents a "line of credit" between the two parties, and records the balance of {App}BUX between them. For example, it may range from —X to X, and start out at zero.
Communities then start embedding Widgets into their webpages, and signing them with authorization to spend a micropayment along their respective trustline. When a User's browser (user-agent) loads the webpage hosted by the Community, it also fetches the Widget from the Hosting company's domain (via an iframe). This request includes the signed authorization from the community to update the Trustline and deduct the micropayment. In the response, the Hosting company can return its own signed version of the Trustline, signifying its acceptance of the micropayment.
​
When the balance of the Community along the {App}BUX Trustline with the Hosting company reaches zero, the Hosting company may refuse to honor the request to render the Widget, and display a standard message informing the user that the Community needs to "top up" their account balance for this App. A properly configured Community would have detected the balance approaching zero and automatically bought more {App}BUX Vouchers from the App Developer.
​
The {App}BUX are vouchers issued and signed by the App Developer, earmarked to be used on a specific Trustline (this is to prevent double-spending). They are typically used in order to "add credits" on a specific Trustline between a Community and a Hosting company. App Developers sell {App}BUX vouchers to Communities in exchange for QBUX, and redeem the vouchers whenever a Hosting company presents them as being spent on the associated Trustline.
​
Attempts by a Community use {App}BUX vouchers on any other Trustline (of a different App or Hosting Company) would be rejected by any honest (or simply self-interested) Hosting company, since it wouldn't be able to cash it out. Even if the App Developer and Community would collude to issue unlimited vouchers, the Hosting company wouldn't realize this, and being self-interested, would ignore improper vouchers from a Community and reject its Widget requests.
​
The Qbix Platform is continuously building measures into its front-end system to make it harder for Communities and Hosting Companies to collude in order to exclude App Developers from making revenue. For example, the front-end Qbix Javascript that comes with all Qbix Platform installations, browser extension, and mobile browser, enforces {App}BUX to be deducted from the Trustline in order for a successful Widget request to be processed. The amount of {App}BUX is seen and approved by the user, who can set up auto-payment to avoid having to approve every request. When the balance on the Trustline reaches zero, the Qbix Platform rejects the request even if a colluding Hosting Company would have approved it.
​
Of course, there are ways to fork any client software requiring a Non-Fungible-Token or online registration, and not pay anything to the network. But in this case, a user would have to fork the entire Qbix front-end framework, and convince tons of Communities and Hosting Companies to use this version, which doesn't pay App Developers anything. Since Qbix Platform hosts multi-user applications, the user base using the fork would not be able to easily interact with the potentially millions of users on the "real" Qbix Platform. Thus, the Network Effect of multi-user applications running on the Qbix Platform is ultimately what keeps a "free software" fork from taking off.