๐
๐
๐
๐
SpaceSwap
Searchโฆ
Shadow Staking/Farming Technology
Shadow Farming is a unique development that is going to revolutionize the whole DeFi farming sphere. โ
This is a brand new way to stake LP tokens. All tokens are kept by the user, which makes the staking process more secure and transparent. Moreover, thereโs no need to send tokens back and forth, making this product almost gasless. โAll you need to do is go to the official SpaceSwap site, choose the pool, proceed to Uniswap, add liquidity to the corresponding pool and receive the LP tokens in your wallet. โThen you just need to go back to SpaceSwap and activate the pool. No need to send your LP tokens to SpaceSwap! The system automatically reads the information from your wallet. โThis minimizes the number of transactions and steps needed at the start of the mining process. โ
โโAbstract โ
Shadow Farming is a Layer 2 instrument for farming projects and earning rewards for LP tokens, without the need to send them to a smart contract. The purpose of this innovation is to minimize usersโ commision expenses and lower their risks by keeping the LP tokens on their accounts.
Conceptually, the product is currently divided into 3 parts: โ
- Smart contracts
- Back-end
- Front-end
โ
Smart contracts
โAt the level of the smart contracts, a number of actions are processed, such as:
โ
- compensations
- maintaining a list of users
- calculating the amount of compensation sent to each user
- maintaining an active pools list and their allocation of points
- maintaining Epoch lists and their compensations
- interacting with the MILK2 smart contract
โWorking with SC keys
โSmart contracts and the back-end contain information about specially allocated back-end addresses that have the right to sign transactions โ the signature function is only used when the harvest method is applied and the user withdraws their reward tokens. This system guarantees the reliability of the data regarding funds owed to the user, based on the information relating to the availability, quantity and history of changes in the balance of tokens. The data referred to here only concerns LP-tokens on the ERC-20 and BEP-20 standards, which the back-end constantly synchronizes with the contract and is where all complex mathematical calculations are processed.
โMethods of working with keys:
- signi(id) โ the signature of the message itself
- amount โ contains the reward amount to be sent to a user
- lastBlockNumber โ contains the block number of withdrawal method previously called. If the value in the smart contract repository doesnโt reconcile with the lastBlockNumber, then the transaction is declined
- currentBlockNumber โ contains the number of the block with a userโs reward calculation on it. If the withdrawal method is successful, it is saved in the smart contract repository
- bytes32 signi - RSA (id, [address userAddress, uint256 amount, uint256 lastBlockNumber, uint256 currentBlock]) โ a userโs address is used for identification. If the wallet address pending withdrawal doesnโt reconcile with userAddress, the transaction is declined. โ
While the withdrawal method is being processed, the smart contract checks the message through a trusted wallet. It also tests the userAddress parameter. The latter has to match with the userโs number calling for withdrawal. โcurrentBlockNumber has to be smaller than the current block and the value in the compensation history repository and the userAddress must correspond with lastBlockNumber. If these conditions are fulfilled, then the smart contract sends the rewards to the user, adding the amount to the general userโs payout. It also changes lastBlockNumber for currentBlockNumber in the compensation history repository. โ
Withdraw function use for registration of new users
โโWhen a new user is registered, the corresponding withdrawal method is processed (with the following parameters in the message):
- userAddress โ the address of a registered user
- amount with 0 value
- lastBlockNumber with 0 value or Null (the default value in the compensation repository for new addresses)
- currentBlockNumber โ the value of the block on the server side โ
Such a request is easily detected by the โlastBlockNumber == Null valueโ, as after the first implementation of this function, it must be inserted into the current block value while the operation is being processed. Moreover, information about the new user is included in all the necessary repositories. It is necessary to use the current block instead of currentBlockNumber, which must be taken into account. And as long as the amount is 0, no token payouts will be made. โThe information is also included in the userโs repository and the number of registered users is increased by 1.
โ
getLastBlock(address)
โโThis function is used to get the block number that contains the last withdrawal method requested by a user. If a user hasnโt been registered, the method returns 0.
โgetTotalRevards()
โThis returns the amount of rewards paid to a userโs address.
โGetPoolsCount
โโThe number of pools entered in the smart contract.
โGetPool
โโThe method used for getting full information about the pool โ weight, address of LP token and block.
{
token: โ0xโฆ.โ,
block: 1109912,
weight: 100,
}
โ
GetMultiplier(from, to)
โOnly the getะกurrentMultiplier () method is significant for the contract. All additional calculations and history of changes are stored at the back-end.
โ
Formula for computing the function
getInterval(a, b) {
return a > b ? a - b : 0;
}
max(a, b) {
return a > b ? a : b;
} min(a, b) {
return a < b ? a : b;
}
getMultiplier(from, to) {
return getInterval(min(t, p[1]), max(f, p[0])) * m[0] +
getInterval(min(t, p[2]), max(f, p[1])) * m[1] +
getInterval(min(t, p[3]), max(f, p[2])) * m[2] +
getInterval(min(t, p[4]), max(f, p[3])) * m[3] +
getInterval(max(t, p[4]), max(f, p[4])) * m[4]
}
GetCurrentMultiplier
Getter for getting a multiplication.
An implementation example:
getCurrentMultiplier() {
const n = CURRENT_BLOCK_NUMBER;
if (n < p[0]) {
return 0;
}
if (n < p[1]) {
return m[0];
}
if (n < p[2]) {
return m[1];
}
if (n < p[3]) {
return m[2];
}
if (n < p[4]) {
return m[3];
}
if (n > p[4]) {
return m[4];
}
}
// We can develop implementation, just as in the previous function.
// Kind of iterative, however, weโll keep this variation for simplicity and visibility. โ
โ
GetUsersCount
โโShows the number of registered users.
โ
GetUser(_id)
โShows a userโs address through their ID in the list of users.
โ
Back-end
โโThe back-end processes the signature of the messages sent to a smart contract and the calculation of all the rewards for users.
โ
Message signing
Only userAddress is visible โ the ETH address of a user.
โ
The server identifies the ETH address and addresses using the getLastBlock smart contract method. Thus, it identifies the block number from which to start the reward payout. If it gets 0 or Null as an answer, then no calculation is needed. It is enough to sign the message consisting of (userAddress, 0, 0, 0) which will initiate a userโs registration in the smart contract after sending.
โCalculation of rewards
โThere are many variants possible, from taking snapshots once in N blocks to analyzing concrete addresses. โRegardless of the implementation, the calculation method will be the same. The pool payout amount for a user to a definite โN block depends on the following parameters:
โ
Smart contract parameters:
- pool.allocationPoints or the weight of the pool โ this is responsible for the amount of tokens per block that will be distributed to a definite pool
- totalAllocationPoints or the total weight of all pools (stored in a smart contract and is calculated โon the windโ from the list of pools in a smart contract)
- user.totalRewards โ the total amount of all a userโs withdrawals
- multiplier
โIPFS repository parameters:
- pool.lastUpdateBlock โ the number of the last renewal pool block
- pool.lpSupply โ the total value of LP tokens in a pool
- pool.accPerShare โ the estimated cost of the share in a pool
- user.amount โ the amount of LP tokens in a userโs wallet
- user.rewardDebt โ the number of the calculated but not yet paid rewards
- user.accLoss โ the amount of already paid rewards based on the loss of profit (the tokens that a user could have earned if they took part in the pool from the very beginning).
In any N pool (N >= pool.lastRewardBlock), the reward amount for a user is calculated the following way:
pendingReward = user.rewardDebt - user.accLoss + user.amount * accPerSharewhere accPerShare = pool.accPerShare + multiplier * pool.allocationPoints / totalAllocationPoints / pool.lpSupply
// N >= pool.lastRewardBlock
multiplier = (N - pool.lastRewardBlock) * tokensPerBlock // calculated on the SC side
If a deposit was made and the LP tokens were withdrawn:
pool.lastUpadateBlock = blockNumber
pool.accPerShare = accPerShare
user.rewardDebt += pendingReward
user.amount += tx.amount
user.accLoss = user.amount * pool.accPerShare
pool.lpSupply += tx.amount
โDuring the withdrawal of the reward, the same procedure is followed, except for the renewal of a userโs data. โ
A message is sent with amount = user.rewardDebt + pendingReward โ
user.accLoss += pendingReward + user.rewardDebt user.rewardDebt = 0;
โ
IPFS (coming soon)
โ
IPFS stores all the changes within the contents of each pool: usersโ registrations, LP token movements through registered users and the reward withdrawals.
Changes are fixed by snapshots of the poolsโ state with added information about a definite user that triggers this change.
โ
Examples of data stored in IPFS blocks:
โโBlock number - the number of the block that the change happened on โ
txHash - the hash of the transaction that caused the change โ
poolSize - the number of LP tokens in the pool โ
accPerShare - the storage rate of the rewards for a share in a pool โ
userAddress - the address of the user that caused the change โ
amount - the amount of LP tokens a user has โ
rewardDebt - the payout debt of a user โ
accLoss - the storage rate of lost income and withdrawals made
Last modified 29d ago
Copy link