1.What is Alkimiya


Alkimiya is a permissionless, open-source protocol for consensus capital markets. Every “consensus producer” (e.g., PoW miners, staking validators) requires continuously expending resources to participate in the mining or staking activities. These resources are either in certain forms of computation (e.g., hashpower) or opportunity costs of liquid assets (e.g., coins staked).

The primary motivation for most people to participate in consensus production is to capture the profit margin between block rewards (revenue) and the costs of resources (expense). On most networks, the costs tend to increase over time as competition heats up. Meanwhile, the revenue is extremely difficult to manage as it involves the fluctuations of coin price, difficulty (or equivalent metric), and network fees.

Similar to how traditional commodity producers use financial instruments to hedge against the uncertainties, consensus producers need a way to lock-in the return upfront. Alkimiya allows any consensus producers to create financial contracts backed by the underlying “consensus resources”.

In v1.0, Alkimiya will focus primarily on the financial abstractions of proof-of-work. Alkimiya v1.0 has two core products: HashSand and Hash Vaults.


HashSands are commodity swaps between seller and buyer of hashpower. In a traditional commodities market, a swap is a contract calling for an exchange of payments, on one or more dates, determined by the differences in two prices.

In this case, HashSand represents a swap between the upfront payment that the buyer agrees to purchase the contract with, and the mining rewards produced by the amount of hashpower specified during the contract period.

Due to the non-custodial nature of HashSands, the seller will not receive the payment right away. Every day the seller delivers the required amount of mining rewards, the seller “earns” a portion of the payment.

For example, a miner running 10Gh/s of Ethash pays $2,000 every month for hosting. In a bear market where the miner wants to protect against the downside, the miner can issue a N Gh/s over 30 days HashSand @ 2,000 USDT (N < 10). Everyday the miner is expected to deliver (N * Reward_Per_Gh/s_Per_Day) number of ETH, in exchange for a portion of the 2,000 USDT. The Reward_Per_Gh/s_Day Index tracks the number of ETH 1Gh/s produced on a given day (see Architecture Overview).

See Specifications section for detailed calculation for the USDT “earn rate”.

1.2.Hash Vaults

Analogous to structured products, Hash Vaults are pools of HashSands that contain additional payout logic. In the most simple terms, HashVault can be viewed as a portfolio of HashSands. It is an umbrella smart contract that holds all the HashSands that the Hash Vault Admin has purchased on behalf of the buyers of the Hash Vault. The HashVault Admin can be dedicated teams running pre-specified strategies, or committee members elected by a DAO.

Users can pool together multiple bilateral contracts and restructure the payout logic into other forms of yield generating assets (e.g. fixed-income bonds, convertibles, perpetual swap, DAO payouts). Unlike most yield generating products collateralized by a basket of coins, the cash flow of a HashVault is secured by the underlying hashpower, which represents the economic activities accrued on the blockchain.

Similar to HashSands, buyers of Hash Vault deposit payments in exchange for VaultTokens that represent the ownership of a corresponding percentage of the rewards held in the Hash Vault at the expiry.


Architecture Overview

The chart below shows the core components and their main functionalities in Alkimiya Protocol.


  • HashSands
    • Bilateral swap contract for hashpower.
  • SandsRepo
    • Short for “Sands Repository”. It is a factory smart contract that creates, maintains, and settles HashSands.
    • Locks mining rewards, until default liquidation or contract completion.
    • Maintains a list of HashSands contracts it creates.
  • Oracle
    • Fetches and stores information related to the Reward_Per_Gh/s_Per_Day Index for Liquidation Engine.
  • Liquidation Engine
    • A library of methods to perform calculations using the information from the Oracle and update the HashSands status.
    • Responsible for flagging HashSand contracts as Default or Complete.
  • LiquidationBot
    • Fetches SandsRepo addresses from TheGraph;
    • Calls Liquidation Engine to check the status of HashSands contracts in its record.


2.2.System of Smart Contract


The Sands Repository (“SandsRepo”) is a factory smart contract that defines the logic for generating and tracking HashSands. It is also the seller’s summary account. All HashSands with the same underlying asset (ETH, wBTC, etc.) is generated from the same SandsRepo. The user just needs to create a SandsRepo once before selling a new asset for the first time. While the HashSands are active, the miner will deliver rewards to the SandsRepo, where it will be held escrow until the HashSands are defaulted or completed.

SandsRepo parameters:

  • Asset: The coin reward routed into this SandsRepo.
  • Reward Due: The total amount of mining rewards owe to buyers of HashSands.
  • Reward Balance: The total amount of mining rewards in the SandsRepo.
  • Payment Accrued: The total amount of HashSand payments that the seller has earned.
  • Excess: Difference between the coin balance and Reward Due in SandsRepo.


The bilateral agreement between sellers/miners and buyers for the purchase of hashrate production. For each agreement, a new smart contract is deployed with a unique token enabling a claim to the future rewards. The seller/miner defines the following parameters:

  • Period: Length of the HashSand contract.
  • Hashrate: The range of hashpower that the seller lists in the contract for sale.
  • Unit Price: The unit price of a contract (price per Gh/s per day).
  • Payment Token: The type of payment token accepted in the HashSands

Each HashSand listing has a two-day subscription window. If enough buyers deposit an amount that’s higher than the lower bound of the hashrate range, the Liquidation Engine will mark the contract as active at the end of the subscription window.

Liquidation Engine

A library of smart contract that calculates Reward_Per_Gh/s_Per_Day Index from the on-chain oracle data and updates HashSands contracts’ status.

2.3.Oracle and Liquidation Bot


The off-chain part of the Oracle fetches information from EtherScan every day. ****Service fetches information of network hashrate + total reward for a FIXED time range (e.g., 2021-10-13 01:00 am to 2021-10-14 01:00 am). After data is fetched, the off-chain Oracle pushes the data on-chain.

The on-chain component of Oracle stores the daily data and uses it to calculate the entries for the Reward_Per_Gh/s_Per_Day Index.

Liquidation Bot

Liquidation Bot calls SandsRepo daily to check the status of the active contracts.

2.4.Reward_Per_Gh/s_Per_Day Index

 Index of mining reward per 1 Gh/s per day. The index updates once per day.

Output = Daily total Rewards / Average Network Hashrate of the day

Denominator: Average Network Hashrate

  1. Pull global network hashrate data via Etherscan API
  2. Calculate the average network hashrate on a given day

Numerator: Daily Total Rewards

  1. Pull block reward data on each day via Etherscan
  2. Sum up block rewards of every block on a given day
  3. Discount by 5% to take account of gas cost, pool fees, and luck variance. In the future, the 5% will be calcualted dynamically using historical data.



Lifecycle of a HashSand

3.1.Functions: Start a HashSands contract

First, the Seller/Miner must deploy a SandsRepo, the factory smart contract. The seller only needs to deploy a Sands Repo for each asset once. To deploy a new Sands Repo, Seller/miner calls SandsRepo Factory to create/initialize a SandsRepo contract.

SandsRepo clones the SandsRepoMaster contract using a deterministic address and initializes it. The Repo is tied to the seller/miner’s wallet.

Seller/Miner calls the SandsRepo contract to create/initialize a new HashSands contract and sets the parameters of the HashSands contract.

Prior to issuing HashSands, it is required that the SandsRepo must contain at least one day of mining rewards plus an additional 5% buffer. This is to make sure that, by the time that the contract goes live, there is more than the first day’s reward locked in to discourage the seller from defaulting as soon as the contract goes live. If there is such amount available in the SandsRepo, that amount will be locked as “Due”, and the contract will be listed.

  • SandsRepo verifies if has enough balance as excess to cover 1-day mining reward plus 5%, and locks it.
  • SandsRepo clones HashSandsMaster contract and initializes it passing the parameters.
  • SandsRepo initialize HashSands with TotalDue = 1-day Mining plus 5% and Next Due = 0.
  • SandsRepo adds the new address to Contract’s index.

Buyer calls HashSands to confirm BID with the purchase amount. After the order has been filled:

  • HashSands calculates Mint Token Amount;
  • Transfer PaymentToken from buyer to HashSands;
  • Mint new Sands Token to the buyers.

The seller interacts with the Alkimiya protocol primarily through SandsRepo. Once a contract is active. The seller must send the mining rewards to the Repo address. The seller can either update the recipient address on the mining pool they are using to the Repo address, or send the appropriate number of coins everyday.

If the balance on the Repo is higher than the Reward Due, the additional amount will be treated as Excess. The seller can withdraw the Excess anytime.

3.2.Functions: Execute HashSands Contract

Daily process:

  • Liquidation Bot fetches all SandsRepos from TheGraph.
  • SandsRepo fetches its balance.
  • SandsRepo Iterates all active HashSands in the Repository and sums up the active hashrate on the given day.
  • SandsRepo fetches each HashSands’ Due amount.
  • SandsRepo sums to get Total Due.
  • SandsRepo checks if Total Balance ≥ Total Due.
    • If not, start three passes on HashSands contract status check:
      • SandsRepo expires all the Open status contracts and releases their Locked amount.
      • SandsRepo checks all the Active status contracts and if a contract completes on the day, SandsRepo will mark as many contracts to Complete status as the balance supports.
      • SandsRepo defaults all the remaining contracts.
  • If SandsRepo passes the previous check, it fetches the output of Reward_Per_Gh/s_Per_Day index and iterates all the HashSands contracts and updates their statuses.
    • If the HashSands is in Open state, check if sold percentage ≥ Minimum Start Threshold, If yes, the contract starts today. If not, check if the contract expires.
    • If the HashSands is in Active state, set Locked Amount = Next Due, and check if the contract completes.
      • If yes, Contract End Locked Amount = Locked Amount, Next Due = 0
      • If no, set Next Due = Locked Amount + (Reward_Per_Gh/s_Per_Day Index * Total HashRate Sold).
  • The Next Due will be used as Due in the next update cycle.
  • On the day n of an N-days HashSands contract, the seller/miner will get a portion of the payment token in the contract, the total accumulated payment token the seller/miner receives is based on this Earn Rate:Earn Rate = 80% * (n/N)^3
    Total Earn = total Payment Token * Earn Rate

Note: If the Liquidation Engine is down for days, it will run sequentially once it is back up. (eg. if it misses DAY-5 DAY-6 DAY-7, LE should trigger: DAY-5, wait for a response, run DAY-6, and so on)

3.3.Functions: Settlement

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

The seller/miner calls the redemption function from the address used to deploy the contract. The Seller/miner receives the full Payment tokens.

The holder(s) of the contract redeem the HashSands tokens to receive rewards proportional to the amount of HashSands tokens they hold. After the reward is redeemed, the tokens are burnt.

Detailed Settlement process:

Buyer calls redeem (hashsands)

  • HashSands checks if the contract has ended;
  • HashSands calculates buyers redeem value;
  • HashSands calls SandsRepo to send the reward to the buyer;
  • SandsRepo sends reward to buyer address;
  • HashSands updates Reward Locked in the contract subtracting the reward sent to the buyer
  • HashSands burns tokens;

Miner calls redeem (HashSands)

  • HashSands checks if contract ended;
  • Hashsands transfers Payment token to Miner.

Settlement sequence diagram

At any given time, the seller/miner can withdraw Excess from the SandsRepo. Although encouraged as a buffer for daily hashrate variance, there is no requirement to lock Excess on SandsRepo.

Miner withdraws Excess (SandsRepo)

  • SandsRepo calculates the excess (using the Due from each SandsRepo);
    • Fetch TotalDue of each Active HashSands;
    • Excess = Balance – Total Due
  • SandsRepo sends the excess to the seller/miner.

3.4.Functions: Default

If the seller/miner fails to deliver the reward amount corresponding to the contractual hashrate into the smart contract, Liquidation Engine will mark all the contracts in the SandsRepo as default. This enables ‘cross-collateralization” of all active contracts from the seller, therefore significantly reducing the seller/miner’s incentive to default.

The HashSands token holders receive any accrued reward 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 seller/miner.

Detailed default process:

Buyer calls default (HashSands)

  • Hashsands checks if the contract is on default;
  • Hashsands calculates buyers Payment tokens return and reward redeem;
  • HashSands sends Payment tokens to buyer
  • HashSands calls SandsRepo to withdraw the proper reward
  • SandsRepo sends reward to buyer
  • HashSands updates Reward Locked in the contract subtracting the reward sent to the buyer
  • HashSands burns tokens

Seller/Miner calls Default (HashSands)

  • Hashsands checks if the contract is on default;
  • HashSands calculates the seller/miner’s Payment tokens owed.
  • HashSands sends Payment tokens to seller/miner.

Default sequence diagram




amountDueAtContractEndAmount of reward that is due when the contract ends (completes or defaults)HashSands
owedNextUpdateAmount of reward that is due the next day Liquidation Engine runsHashSands
amountLockedAmount of reward that is locked in the contractHashSands
contractPeriodThe duration of the contractHashSands
dayOfDefaultThe day the contract defaultsHashSands
deployTimeThe timestamp when the contract is createdHashSands
endDayThe day the contract endsHashSands
hashrateThe hashrate listed in contract for saleHashSands
isMinerDefaultPayoutCompleteA flag that miner gets the payment from the contract when it's in default stateHashSands
lastUpdatedDayThe last day the contract gets updated by Liquidation EngineHashSands
minimumStartThresholdThe minimum percentage of the contract sold to start the contractHashSands
paymentTokenThe token seller chooses as the payment for the contractHashSands
reservedPriceThe listed price of the conractHashSands
sandsRepoSands Repo address that the contract belongs to HashSands
sellerSeller wallet idHashSands
startDayThe day the contract startsHashSands
statusThe status of the contract (Open, Active, Expired, Defaulted, Finished, Redeemed)HashSands
totalPaymentTotal payment when the contract startsHashSands
totalSoldTotal hashrate sold in the contractHashSands
deployerThe deployer address of the repo (Alkimiya)SandsRepo
hashSandsMasterThe HashSands Master address for deploy a new HashSands under the repoSandsRepo
lastSettledDayThe last day Liquidation Engine runs and updates all the HashSands under the repoSandsRepo
oracleAddressAlkimiya On-Chain Oracle addressSandsRepo
ownerThe owner address of the repoSandsRepo
registryA KeyValue pair of HashSands address and boolean to track if a HashSands contract is registered to the repoSandsRepo
indexThe mapping of updated timestamp and Alkimiya IndexOracle
nameThe name of the OracleOracle
lastReferenceDayThe Last day on which the Oracle gets updateOracle

4.2.Public Methods

initializeInitialize the parameters of the HashSands contractHashSands
decimalsReturns the decimals of HashSands TokenHashSands
confirmBidThe HashSands contract confirms the successful bid from a buyerHashSands
minerRedeemTransfer all payment token to miner when the contract completesHashSands
buyerRedeemTransfer the reward to buyer when contract completesHashSands
executeDefaultBuyerBuyer calls when contract defaultsHashSands
executeDefaultMinerMiner calls when contract defaultsHashSands
buyerRefundBuyer calls to get refund from the contractHashSands
isHashrateThresholdExceededCheck if the HashSands sells the minimum percentage to startHashSands
calculateHaircutReturn the haircut value based on the day the contract defaultsHashSands
initializeInitialize the parameters of the Sands RepoSandsRepo
getBalanceGet the total balance of the Sands RepoSandsRepo
getAvailableBalanceGet the available balance of the Sands Repo (Total balance minus the locked amount)SandsRepo
withdrawExcessRewardThe owner of the Sands Repo withdraws the excess rewardSandsRepo
transferRewardToBuyerTransfer the Reward to Buyer walletSandsRepo
getRewardTokenAddressReturn the address of the reward tokenSandsRepo
createHashSandContractCreate a HashSands contractSandsRepo
getTotalAmountLockedReturn the total locked amount of rewardSandsRepo
getTotalAmountOwedNextUpdateReturn the total reward amount that is due for next oracle updateSandsRepo
triggerUpdateUpdate all the HashSands contracts under the Sands RepoSandsRepo
getNetworkRewardAndHashrateReturn Basis Reward Index of the daySandsRepo
updateIndexUpdate Alkimiya IndexOracle
getReturn Alkimiya Index of the given dayOracle
isDayIndexedCheck if Alkimiya Index is updated on a given dayOracle
getLastIndexedDayGet the last day the Oracle gets updatedOracle


DeployedEvent emitted when the HashSands contract is deployedHashSands
BidConfirmedEvent emitted when the bid to HashSands is confirmedHashSands
CollateralConfirmedEvent emitted when the colateral is confired (obseleted)HashSands
RewardArrivedEvent emitted when the reward transfered to HashSandsHashSands
RedeemEvent emitted when redeem is confirmedHashSands
DefaultEvent emitted when the contract is in default stateHashSands
RefundEvent emitted when the refund of the HashSands is issuedHashSands
UnsoldCollateralClaimedEvent emitted when miner collets unsold collateral from the HashSands contract (obseleted)HashSands
UpdatedOfferEvent emitted when the HashSands contract's parameters are updatedHashSands