How We Integrated Mercury Protocol into Dust

As we touched on in First Integration of the Mercury Protocol, Dust will receive two initial GMT tokenized features, Premium Exposure and Premium Distribution. These features are implemented through a combination of server, client, and smart-contract code.

Client-Side Transaction Processing

The architecture for the interaction between Dust, Ethereum, and the Mercury Protocol is as follows:

Every user maintains a public and private key on the client. The key is encrypted and stored only on the client, never on our servers. The Dust client creates and signs an Ethereum transaction using its encrypted private key, and passes it to the Mercury Protocol server, which forwards it to an Ethereum node running on AWS.

Premium Exposure

Users can use GMT to be listed on the front page of the Discover section for 24-hours. For this to happen, the following steps must take place:

1. Dust fetches pricePerDay from thePremiumExposure contract and presents it to the user
2. Upon confirmation Dust calls approve(address spender, uint value) on the GMT contract, approving thePremiumExposure (spender) contract to spend the pricePerDay (value) on behalf of the user
3. Dust calls purchasePremiumExposure(uint256 _value) with a _value that matches the approved value from the previous step
4. PremiumExposure contracts attempts to transferFrom(address from, address to, uint value) the Dust user to the Growth Pool and Service Provider, and if successful fires the PurchasedPremiumExposure event which indicates the amount paid and the duration of exposure
5. Mercury Protocol server passes the event to Dust which saves the Dust user to Mongo DB in a featured users table
6. Dust server runs an hourly cron job that checks for expired users, when it finds one it calls cleanupFeaturedUser(address _userAddress) on the PremiumExposure contract, which checks against its locally maintained mapping of featured users. If the user is in fact expired, she is removed from the featuredUsers mapping, and upon successful removal, the ExposureEnded event is fired
7. Mercury Protocol server passes the ExposureEnded event to Dust which removes the expired user from its Mongo Database, which is then reflected in the Dust client application

The Dust server maintains an offline copy of the list of featured users, but defers to the smart contract as the one source of truth. Featured users are only added and removed from Mongo when the Dust server receives an event indicating that a user PurchasedPremiumExposure or that their ExposureEnded. If at any time there is a dispute over the validity of a featured user, the contract mapping can be referenced.

Here is a code snippet of the bread-and-butter purchasePremiumExposurefunction:

Premium Distribution

Users can use GMT to send out a “Blast” to a number of users that don’t follow them as a way to expand their network. For this to happen, the following steps must take place:

1. Dust fetches pricePerRecipient from thePremiumDistribution contract and presents it to the user, allowing the user to choose a desired number of recipients and updating the price accordingly
2. Upon confirmation Dust calls approve(address spender, uint value) on the GMT contract, approving thePremiumDistribution (spender) contract to spend the pricePerRecipient x numRecipients (value) on behalf of the user
3. Dust calls purchasePremiumDistribution(uint256 _value) with a _valuethat matches the approved value from the previous step
4. PremiumDistribution contract attempts to transferFrom(address from, address to, uint value) the Dust user to the Growth Pool and Service Provider, and if successful fires the PurchasedPremiumDistribution event which indicates the amount paid and the number of recipients
5. Mercury Protocol server listens to events from the smart contract, and when it detects a PurchasedPremiumDistribution event, it notifies the Dust server to send out the user’s “Blast” to the number of recipients paid for

As of now, this PremiumDistribution feature relies on Ethereum primarily to facilitate and validate tokens spent. Here is a code snippet of the bread-and-butter purchasePremiumDistribution function:

In the PremiumExposure feature we are able to leverage the blockchain to ensure users receive the services they spend GMT on, however the PremiumDistribution feature would require the use of an outside oracle to do the same. In order to verify that users received the content, we need to query the application logic, which cannot be done directly from the smart contract since smart contracts can’t communicate with the external world. Given the nature of premium communication features like this one, we see oracles playing a big role in validating the delivery of premium services, thus we are actively researching oracles for potential integration in the near future.

Conclusion

We have integrated the Mercury Protocol into Dust by way of GMT tokenization. There are two initial features, Premium Exposure and Premium Distribution, implemented both in Dust and in corresponding smart-contracts deployed to the Ethereum blockchain (Rinkeby Testnet for now). Dust interacts with these contracts, and responds to events triggered by user purchases of premium services. We’ll be deploying these contracts onto the Ethereum Mainnet and releasing an update to Dust after the conclusion of the GMT token launch event so that Dust users will immediately be able to use these tokenized features.

Connect

Slack
Telegram
Twitter
Reddit
Facebook
LinkedIn

Learn more about the Mercury Protocol
Read the Mercury Protocol whitepaper