SIP-17: Expand ‘Settlement & Release’ initiative

Motivation

This proposal suggests for the protocol to expand the existing ‘Settlement & Release” initiative (https://snapshot.org/#/samuraifi.eth/proposal/0x9af7bf478a1495864d8d1a7c543b539d35bfd14082b43072f1d2a3b0bebd7b6b). The assumption underlying the proposal and the thesis behind the expansion of the “Settlement & Release” initiative is that it shall effectively allow and enable the protocol to operate more efficiently in the context of the dynamically, rapidly and continuously evolving regulatory landscape while employing a reasonable and considerate approach towards its users.

In the context of the continuous efforts to ensure that the protocol operates in compliance with its established policies and Terms of Service and the constituent frontend geolocation-based restrictions and blockers, this proposal shall only be applicable and eligible to previously undetected protocol users from restricted areas with negative Redeemable Amounts (which were determined based on the trades, engagement, and interactions of the users with the protocol’s products and services).

The existing list of restricted areas (Burma / Myanmar, Cuba, Iran, Sudan, Syria, the Western Balkans, Belarus, Canada, Côte d'Ivoire, Democratic Republic of the Congo, Iraq, Lebanon, Liberia, Libya, Netherlands, North Korea, Russia, United Arab Emirates, United States, certain sanctioned areas of Ukraine, Somalia, Venezuela, Yemen, or Zimbabwe) shall be expanded and additionally include the following: United Kingdom, Hong Kong, China, Saudi Arabia, Qatar, and Singapore.

The eligible users shall be able to claim an FTM equivalent of the “Redeemable Amount” specifically computed for their wallet(s).

The Redeemable Amount shall be computed utilising the following methodology and rationale: Firstly, the list of Node holders shall be collected. The list shall not resort to a simple solution of taking into account the current snapshot and determining who the node holders are but rather traverse the entire history of the protocol from KTNA V1, V2, HNR to xHNR. At each step, to the best extent possible, the information shall be gathered from Snapshots, DEX data using Bitquery, or old migration files. For each of these wallet addresses, their transaction history shall be analysed against the protocol’s contract addresses and scraped for function signatures that contain "createNodeWithTokens" or "createNode". The approximate time of node creation shall also be noted. If the nodes were attained in KTNA V1, but migrated over in V2, then they shall not be considered as an additional node, but rather, shall be considered to be the same node that is currently present in V2 but deprecated in V1. This shall be done to avoid unfair duplications in the dataset and to only consider node creations, which were originated from the users and not created by the core team.

Once the raw data is collected, it shall pass to the second stage - post-processing. As a result of the protocol’s initial code inheritance, the original codebase contained security flaws and was consequently exploited. The exploiters utilised the "createNode" function signature instead of "createNodeWithTokens". Given the collected, associated function signatures from before, these wallets shall be filtered out. These wallets shall be simply removed from the entire dataset, regardless of the wallet’s other activity, to enforce a no-tolerance policy towards exploiters.

In the next stage, Bitquery shall be utilised again to build the appropriate graphql query. The query shall fetch all the trades made against KTNA, KTNA V2, HNR, and xHNR for a given wallet address. This shall return an array of all trades made by the wallet and shall be followed by a simple reduce algorithm to sum up all the trades. If the trade was conducted for the purposes of acquiring a node, it shall be converted to a negative number (e.g. 256 to -256). However, if the trade was conducted for the purposes of a sell using the protocol’s native token, it shall remain as a positive number. The reduce algorithm shall then sum up all the trades, and compute a single net “Redeemable Amount” number. The initiative shall not take into account any TofuNFT-related activity.

The proposal shall only revolve and focus on conducting the “Settlement & Release” initiative with users and wallets whose “Redeemable Amounts” are negative. If the total Redeemable Amount is positive or zero (likely due to a simple NFT transfer post pivot migration), the user shall not be eligible to receive an FTM denominated “Redeemable Amount”. In order for the users to be able to claim the “Redeemable Amount”, the users shall sign the relevant Settlement & Release agreement and dispose of their Samurai NFT Nodes to the protocol’s smart contracts. The Samurai NFT Nodes attained through the initiative shall be burned at a later date.

Upon the successful verification of eligibility and completion of enrolment for the collection of the “Redeemable Amount”, the appropriate total amount of “Redeemable Amounts” denominated in FTM shall be transferred from the Samurai Governance Vault to the smart contract devoted to the Settlement & Release initiative and shall be consequently transferred to the respective users. The Samurai Governance Vault shall also transfer relevant amounts of FTM to cover the gas fees associated with the FTM transfers.

The snapshot period shall remain identical to the original SIP-16 in order to avoid data conflicts.

The first batch of FTM transfers of the “Redeemable Amounts” shall be conducted 7 days after the potential approval of this proposal.

Other FTM transfers of the “Redeemable Amounts” for users who enroll at a later date shall be conducted arbitrarily.

Specification

Transfer the appropriate amounts (to be determined based on continuous enrolment) of Fantom tokens from Samurai Governance Vault to Samurai Release smart contract

Conduct the initiative and distribute the appropriate and relevant amounts of FTM (based on “Redeemable Amounts”), using the methodology outlined above

Transfer the collected Samurai NFT Nodes to the burn address

The proposed Solidity code / smart contracts

https://gateway.pinata.cloud/ipfs/QmTgGhboKEdjJn5qpV5bpqpVyFBQLn6E3VVYQmhiVQ92at