Methodology

In order to calculate each user’s entitlement in CRSS, we needed to find a way to gather the full data on each type and amount of value owned by each user in every possible location.

For this purpose Compensation Methodology was divided into 4 structural components based on the location of funds involved.

Presale, User Wallet Balances, User Staking and Post-Exploit Swaps

Timeframes for Compensation Components

COMPONENT	TIMEFRAMES
Presale	All values held in presale at the time of the final calculations
Wallets	All values held in wallet one block before the first attack (14465247 )
Staking	All values held in staking at the time of the final calculations
Post Exploit Swaps	All buys involving CRSS from 18 Jan 2022 06:08:05 AM UTC to 18 Jan 2022 23:59:59PM UTC, all sells recorded up until the final calculations day

Technical Approach

1. Presale

Round 1: 0xAd3f5A4526fbEd82A865d1BaeF14153488f86487

Round 2: 0x3DC2b7E5dc5274C2d603342E73D1d0A9DE96796A

The deployed smart contracts on BSC contained all the necessary information to extract the correct amounts of user funds inside their view functions.

• Each contract contained an array of all involved user addresses stored and publicly accessible

• Each contract contained a view function called “userDetail” which takes an address as an input and outputs following info for each user :

depositTime, uint256

$totalRewardAmount, uint256 ⇒ represents total CRSS bought in presale$

$withdrawAmount, uint256 ⇒ represents total CRSS withdrawn from presale$

$depositAmount, uint256 ⇒ represents total BUSD value payed in presale$

• To calculate remaining value for each user inside both smart contracts was as simple as deducting withdrawAmount from totalRewardAmount

2. User Wallets

User historical BEP20 token balances do not get stored directly on the blockchain, for this reason there are generally two ways to get such values. Apart from recreating these values by gathering transfer logs and BEP20 token transfer history, some services also store this data directly.

We decided to fetch this data directly from BSC API service, which had an API request for fetching historical balances of addresses in their Pro API plans.

We ran this API call 12 times for each address (to account for all 12 tokens in scope for wallet compensation) for block before the first attack 14465247 to get wallet values for each user

We calculated total CRSS wallet compensation by first converting all LP token wallet holdings to CRSS using the prices for CRSS and LP tokens from block 14465247. Then we simply added token amounts of CRSSv1, CRSSv11 and XCRSS on top of that to get the total wallet compensation for each user

3. CRSS Staking in Masterchef

Part 3.1 contains the current implementation used to determine total amounts of all tokens locked in MC smart contract for staking and LP farms block before exploit (BBE). This is the only approach used to gather user staking and farming entitlement.

Part 3.2 Is the old approach for getting CRSS staking entitlement, can be used to test since it gathers the same CRSS amounts but in a slightly different way and with use of information stored in Masterchef smart contract

3.1 Main implementation

In this approach we reconstruct user token amounts held in farms and staking pool by gathering all transaction logs and BEP20 token transfers between the block of creation for Masterchef smart contract 0x70873211CB64c1D4EC027Ea63A399A7d07c4085Band BBE.

Within all token transfers gathered there was a total of 11 different tokens identified, they are listed in the Compensation Scheme document.

Transfers were filtered by token address and separated into outgoing and ingoing transfers based on MC contract being a “to” or “from” address

Ingoing and outgoing token transfers which sent one of 11 tokens in scope to or from MC were filtered with previously gathered and extracted transaction log hashes with corresponding function topic0s (listed inside the script) for withdraw, deposit (includes enterStaking()) and emergency withdrawal function calls.

This resulted in a list of all deposits and withdrawals to MC from contract creation to BBE. Deposits were added and withdrawals deducted for every different token of each user to derive the Total staking value BBE.

3.2 Deprecated

(older code, irrelevant in getting the actual results, just serves as testing )

This part was done simply by reading stored information on BSC blockchain from deployed Masterchef contract . All staking rewards accrued post-exploit are excluded.

1. We collect data about staked CRSS amounts locked inside MC contract by using Web3 to read from deployed smart contract’s userInfo(0,address) view function. The first parameter is CRSS staking PID, which is always 0, and the second is the wallet address you want the locked balance value returned for.

2. The getSmartContractCompenensation.js script ran the view function once for each of 2398 addresses, ordered and stored TotalStakingValue for each user.

3. Lastly, checkMasterchefStaking.js script was run to exclude all addresses that staked after the attack since there were dozens of millions of CRSS staked, when in contrast, less then 0.5mil was staked before the exploit.

TotalStakingValue = TotalCRSStaked - CRSSStakedAfterAttack

Adjust Post-Exploit Staking Deposits & Withdrawals

This was a daunting task requiring both transfer logs and BEP token transfer historical data. This data was filtered several times, as detailed in the Compensation Methodology. In order to get all historical CRSS transfers using MC contract, post-exploit, we called enterStaking() and deposit(PID0) functions. These transfers were then traced back to addresses that sent them, in order to calculate each user’s deposits post-exploit. The same logic was used to calculate post-exploit withdrawals from MC contract.

We also had to account for users that found a way to exploit MC contract, and withdraw CRSS they didn’t own. Each address is followed by the biggest exploit hash, every hash included whitelisted transfers, and every hash had input value of 0 CRSS to withdraw with huge amounts being sent from MC to exploiter.. This was manually cross-checked with their balance pre-exploit in order to identify the malicious transactions. Post-exploit staking withdrawals for users on this list will not be added to overall staking entitlement.

https://github.com/crosswise-finance/crosswise-snapshot/blob/master/scripts/stakingAttackers.js

Lastly, amounts deposited post-exploit, were deducted from TotalStakingValue, all qualifying withdrawals were added to TotalStakingValue .

ADDRESSES	602
TOTAL CRSS OWED	931719.3710246222

3.2.1 Get Masterchef Smart Contract Data

We collect information about staked CRSS values locked inside Masterchef contract by using Web3 to read from deployed smart contract’s userInfo(0,address) view function, first parameter being CRSS staking PID, which is always 0, and the second being the address you want locked balance value returned from

The getSmartContractCompenensation.js script ran the view function once for each of 2398 addresses, ordered and stored TotalStakingValue for each user

checkMasterchefStaking.js script was run to exclude all addresses that staked after the attack since there were dozens of millions of CRSS staked, when in contrast, less then 0.5mil was staked before

TotalStakingValue = TotalCRSSStaked - CRSSStakedAfterAttack

We have to account for all after-attack staking deposits because both hackers and numerous exploiters managed to deposit enormous amounts of illegitimate CRSS, this phenomenon best explained by stating that without removing after-attack deposits, total staking value is around 94mil CRSS.

3.2.2 Check Masterchef Staking

1. Figuring out which users staked after the attack was accomplished by gathering all transfer logs and BEP20 token transfers for Masterchef smart contract using Moralis API.

2. Transfer logs were collected separately for deposits, withdrawals and emergency withdrawals, using the respective functionalities topic identifier (all enterStaking() and deposit() function for PID 0 have the same topic0, withdrawal has a different topic0, and so does emergency withdraw), and after filtering all transaction hashes were extracted into separate json files

3. BEP20 token transfers were then filtered by token type transferred (always CRSS) and receiving address (for CRSS deposits its always Masterchef) or sender address (for CRSS withdrawals its always Masterchef)

4. Filtered BEP20 token transfers were filtered again, this time with the extracted transfer log hashes, to exclude all non-staking related CRSS transfers

5. When the filtered BEP20 transfer logs for Masterchef were only showing enterStaking() and deposit() for PID 0 function calls, for every one of those calls one block after the attack, those values were then organized and calculated into a separate json showing the value of CRSS deposited by each user after the first attack

6. The same process, with a bit of adjustment, is done to gather post-exploit staking withdrawal amounts for each user that emitted a withdrawal event

Lastly, amounts deposited by each user, after the attack, were deducted from their TotalStakingValue and qualifying withdrawals were added to TotalStakingValue.

4. Post-Exploit Swaps

We gathered all buys between first block after attack and last minute of 18th Jan at 23:59:59PM.

Sells were gathered from the first block to the day of official Compensation launch. The script was run to aggregate and calculate this information.

The exact information on where the data was gathered and how a user might gather the same exact data will be disclosed at the day of official compensation release, this is for security reasons, you will be able to verify everything and reproduce the same results.