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: Silica and Hash Vaults.


Silica 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, Silica 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 Silica, 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 Silica @ 2,000 USDT (N < 10). Every day 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 Basis Reward 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 Silica that contain additional payout logic. In the most simple terms, HashVault can be viewed as a portfolio of Silica. It is an umbrella smart contract that holds all the Silica 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 Silica, 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.


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


2.2.System of Smart Contract

Silica Account

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

Silica Account parameters:

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


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 Silica 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 Silica

Each Silica 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 contracts that calculates Basis Reward Index from the on-chain oracle data and updates Silica 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 Basis Reward Index.

Liquidation Bot

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

2.4.Basis Reward 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 Silica

3.1.Functions: Start a Silica contract

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

Silica Account clones the SilicaAccountMaster contract using a deterministic address and initializes it. The Account is tied to the seller/miner’s wallet.

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

Prior to issuing Silica, it is required that the Silica Account 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 Silica Account, that amount will be locked as “Due”, and the contract will be listed.

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

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

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

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

If the balance on the Account 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 Silica Contract

Daily process:

  • Liquidation Bot fetches all Silica Account from TheGraph.
  • Silica Account fetches its balance.
  • Silica Account Iterates all active Silica in the Account and sums up the active hashrate on the given day.
  • Silica Account fetches each Silica’s Due amount.
  • Silica Account sums to get Total Due.
  • Silica Account checks if Total Balance ≥ Total Due.
    • If not, start three passes on Silica contract status check:
      • Silica Account expires all the Open status contracts and releases their Locked amount.
      • Silica Account checks all the Active status contracts and if a contract completes on the day, Silica Account will mark as many contracts to Complete status as the balance supports.
      • Silica Account defaults all the remaining contracts.
  • If Silica Account passes the previous check, it fetches the output of the Basis Reward index and iterates all the Silica contracts, and updates their statuses.
    • If the Silica 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 Silica 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 + (Basis Reward 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 Silica 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 Silica tokens to receive rewards proportional to the amount of Silica tokens they hold. After the reward is redeemed, the tokens are burnt.

Detailed Settlement process:

Buyer calls redeem (Silica)

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

Miner calls redeem (Silica)

  • Silica checks if the contract ended;
  • Silica transfers Payment token to Miner.

Miner withdraws Excess (Silica Account)

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

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

Settlement sequence diagram


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 Silica Account as default. This enables ‘cross-collateralization” of all active contracts from the seller, therefore significantly reducing the seller/miner’s incentive to default.

The Silica 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 (Silica)

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

Seller/Miner calls Default (Silica)

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

Default sequence diagram



amountDueAtContractEndAmount of reward that is due when the contract ends (completes or defaults)Silica
owedNextUpdateAmount of reward that is due the next day Liquidation Engine runsSilica
amountLockedAmount of reward that is locked in the contractSilica
contractPeriodThe duration of the contractSilica
dayOfDefaultThe day the contract defaultsSilica
deployTimeThe timestamp when the contract is createdSilica
endDayThe day the contract endsSilica
hashrateThe hashrate listed in contract for saleSilica
isMinerDefaultPayoutCompleteA flag that miner gets the payment from the contract when it's in default stateSilica
lastUpdatedDayThe last day the contract gets updated by Liquidation EngineSilica
minimumStartThresholdThe minimum percentage of the contract sold to start the contractSilica
paymentTokenThe token seller chooses as the payment for the contractSilica
reservedPriceThe listed price of the conractSilica
silicaAccountSilica Account address that the contract belongs to Silica
sellerSeller wallet idSilica
startDayThe day the contract startsSilica
statusThe status of the contract (Open, Active, Expired, Defaulted, Finished, Redeemed)Silica
totalPaymentTotal payment when the contract startsSilica
totalSoldTotal hashrate sold in the contractSilica
deployerThe deployer address of the Account (Alkimiya)Silica Account
silicaMasterThe Silica Master address for deploying a new Silica under the AccountSilica Account
lastSettledDayThe last day Liquidation Engine runs and updates all the Silica contracts under the accountSilica Account
oracleAddressAlkimiya On-Chain Oracle addressSilica Account
ownerThe owner address of the AccountSilica Account
registryA KeyValue pair of Silica contract address and boolean to track if a Silica contract is registered to the AccountSilica Account
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 Silica contractSilica
decimalsReturns the decimals of Silica TokenSilica
confirmBidThe Silica contract confirms the successful bid from a buyerSilica
minerRedeemTransfer all payment token to miner when the contract completesSilica
buyerRedeemTransfer the reward to buyer when contract completesSilica
executeDefaultBuyerBuyer calls when contract defaultsSilica
executeDefaultMinerMiner calls when contract defaultsSilica
buyerRefundBuyer calls to get refund from the contractSilica
isHashrateThresholdExceededCheck if the Silica sells the minimum percentage to startSilica
calculateHaircutReturn the haircut value based on the day the contract defaultsSilica
initializeInitialize the parameters of the Silica AccountSilica Account
getBalanceGet the total balance of the Silica AccountSilica Account
getAvailableBalanceGet the available balance of the Silica Account (Total balance minus the locked amount)Silica Account
withdrawExcessRewardThe owner of the Silica Account withdraws the excess rewardSilica Account
transferRewardToBuyerTransfer the Reward to Buyer walletSilica Account
getRewardTokenAddressReturn the address of the reward tokenSilica Account
createSilicaContractCreate a Silica contractSilica Account
getTotalAmountLockedReturn the total locked amount of rewardSilica Account
getTotalAmountOwedNextUpdateReturn the total reward amount that is due for next oracle updateSilica Account
triggerUpdateUpdate all the Silica contracts under the Silica AccountSilica Account
getNetworkRewardAndHashrateReturn Basis Reward Index of the daySilica Account
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 Silica contract is deployedSilica
BidConfirmedEvent emitted when the bid to Silica contract is confirmedSilica
CollateralConfirmedEvent emitted when the colateral is confired (obseleted)Silica
RewardArrivedEvent emitted when the reward transfered to SilicaSilica
RedeemEvent emitted when redeem is confirmedSilica
DefaultEvent emitted when the contract is in default stateSilica
RefundEvent emitted when the refund of the Silica is issuedSilica
UnsoldCollateralClaimedEvent emitted when miner collets unsold collateral from the Silica contract (obsoleted)Silica
UpdatedOfferEvent emitted when the Silicacontract's parameters are updatedSilica