Documentation

Background

Proof of work blockchains require hashpower to create new blocks and secure the networks. Block rewards and network fees compensate the miners for the computational resources expended to perform this work. Miners typically pool their efforts to produce more stable rewards. The Alkimiya platform introduces smart contracts that allow miners to sell their future production of rewards for a fixed amount. The smart contracts receive information about the hashpower produced by a miner working in a pool through an oracle, and settle the contracts accordingly. Contracts exist as bilateral agreements between a miner and purchaser of the future rewards, with predetermined logic for payouts in the event of miner default.

1. Architecture

1.1 Smart Contract

The bilateral agreement between miner and buyers for the purchase of hashrate production is implemented on a smart contract. For each agreement, a new smart contract is deployed with a unique token enabling a claim to the future rewards. The initialization and deployment of the smart contract occurs with a specified production amount, term, price and deposit from the miner. Once a buyer deposits the requested price, the contract becomes active.

The miner’s production is then routed to the smart contract address. After the term of the contract has expired, the miner calls a redemption function to withdraw the buyer’s payment, as well their deposit. The holders of the token can burn their tokens for the produced reward. Additionally, there is a function on the smart contract to check for a miner default and provide the corresponding payouts.

1.2 Oracles

A set of oracles provides hashrate confirmation and reward data used to verify the activity of the miner. An oracle smart contract is deployed for each mining pool supported by the Alkimiya protocol. Upon contract creation, the miner specifies the mining pool and miner identifier, which are used to confirm that the specified hashrate is produced and the corresponding reward has been sent to the contract address.

Mining pool APIs are used to continually fetch and monitor miner production. The Alkimiya platform, as the oracle provider, posts to the oracles on a daily basis in the format required by the smart contracts to evaluate production.

1.3 Mining Pool Integration

Any mining pool with a public API can be integrated into the Alkimiya platform, allowing miners to use their preferred mining pool while still accessing the market for their hashrate. The mining pools can be directly or indirectly incorporated into the Alkimiya platform.

1.3.1 Direct Integration

Mining pools can be directly integrated into the platform by providing an interface for their miners to access Alkimiya platform and contract details. The mining pool interface can ensure that the reward to the miner for their contribution to the pool’s production is rerouted to the smart contracts for fulfilment of the contract.

1.3.2 Indirect Integration

For a mining pool with a publicly available API, a miner can use the Alkimiya platform by providing an identifier for their work at a pool, and manually changing the reward address to route reward payments to any contracts that are active. No action is required on the part of the mining pool, but a static and mature API for the pool is required to allow miners to use this method.

2. Contract Specification

The Alkimiya platform provides the interface to specify and initialize the contract. The diagram below illustrates the lifecycle:

2.1 Parameters

Contract parameters include term, hashrate, contract price, and security deposit amount. Once a contract has been list and deployed, the parameters are immutable. In order to change the parameters, the miner must cancel and relist the contract.

2.2 Reserve Balance

Due to the variability in hashrate production and in order to prevent unintended default, the miner may choose to overallocate hashrate production to the contract. Any additional reward from the excess hashrate remains in the contract as a buffer to default, and is returned to the miner upon successful completion of the contract.

2.3 Miner Deposit

At contract initialization, the miner chooses an amount to collateralize the contract. If the contract is successfully purchased and hashrate production satisfied, the deposit is returned to the miner. If the contract is not purchased or is canceled, the miner receives the deposit back. In the event of default, the purchaser of the contract receives the full miner deposit.

2.4 Contract Redemption

At the end of the contract, based on successful production of contractual hashrate and delivery of corresponding reward into the smart contract, a redemption function on the smart contract is available to disperse the funds.

The miner calls the redemption function from the address used to deploy the contract. They receive the full upfront payment, their initial deposit, and any excess reward which has accrued in the smart contract.

The holder(s) of the token at the end of the contract redeem their token in the smart contract to receive a portion of the produced reward proportional to the amount of tokens they hold.

2.5 Default

If the miner fails to deliver the reward amount corresponding to the contractual hashrate into the smart contract, the contract is put into default. The purchaser receives any accrued reward, the miner deposit, and recovery on their initial payment. The recovery of the initial payment is calculated as:

Recovery = Initial Payment (1 − 80% (Days Elapsed / Contract Length)^3)

The remaining balance of the initial payment is paid to the miner.

Get in touch

Get updates on new research we publish as well as new product releases