SIP-8: Retroactive funding
Last updated
Last updated
This proposal suggests for the protocol’s governance to adopt and enact a retroactive funding initiative. Retroactive funding is a mechanism that provides financial support to previously executed activities, decisions or initiatives, after they have taken place. This is arguably an advantageous approach compared to the more traditional, forward-looking funding approaches, structures and initiatives employed by other protocols and DAOs, which typically request support for initiatives prior to their execution and deployment (https://gov.uniswap.org/t/temperature-check-create-the-uniswap-foundation/17358, https://snapshot.org/#/hectordao.eth/proposal/0xebd59bf0de0e4f92adb0705cf8269524dd573a0d7083caa5e758243f82d167c3)
In the context of a protocol that aims and strives to be autonomously governed and enables its tokenholders to vote on what should and should not be retroactively funded, there are presumably several advantages to employing such approach.
Encourages participation: By retroactively funding projects, the protocol incentivizes individuals and organizations to participate in initiatives that align with the protocol’s goals and vision. This helps to foster a culture of engagement and collaboration, leading to a more vibrant and active community.
Supports experimentation: Retroactive funding allows for experimentation and innovation. Contributors can take risks and try new approaches, knowing that if their efforts are successful, they will be rewarded. This creates a more dynamic and forward-looking environment, encouraging new ideas and developments.
Increases efficiency: Retroactive funding reduces the time and resources required for up-front planning and fundraising. Contributors can start working on a project without having to first secure funding, allowing them to move quickly and efficiently.
Enhances accountability: By retroactively funding activities that have already taken place, the protocol can ensure that the funds are being used for their intended purpose, and that contributors are held accountable for their actions. This helps to build trust and confidence in the protocol.
Promotes transparency: The governance process for retroactive funding provides a transparent and democratic mechanism for decision-making. This allows the community to evaluate proposals, monitor progress, and hold contributors accountable, ensuring that funds are being used effectively and efficiently.
In conclusion, retroactive funding can play an important role in supporting a decentralized protocol that uses governance to make decisions. By encouraging participation, supporting experimentation, increasing efficiency, enhancing accountability, and promoting transparency, retroactive funding can help to create a more dynamic and successful protocol. The merits and use of retroactive funding have been explored and endorsed by the industry’s titans such as Aave (https://app.aave.com/governance/proposal/98/), Vitalik Buterin (https://vitalik.ca/general/2021/11/16/retro1.html), Optimism (https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) and others.
This proposal details and outlines the efforts, initiatives and integral features that the core team and its companies have designed, executed and delivered to the protocol over the last 14 months and proposes a retribution to the core team and its companies in the form of retroactive funding. The source of funding to facilitate the proposed retroactive funding is not any form of raise or private sale but the funds, specifically the equivalent of 9030k DAI, that have been generated by the smart contracts (+core team) and the protocol’s native token selling and have been previously relocated with the use of a cryptocurrency mixer.
The retroactively retributed activities include but are not limited to:
The Samurai protocol and its underlying thesis, vision and mission has consistently pivoted and evolved over time. The community consensus has signalled and relatively settled on its preference for the protocol’s increased focus on developing and nurturing a growing ecosystem of various utilities and consumer-facing features and services, which is the approach and direction that the protocol’s related development increasingly adopted to better attempt to achieve a state of product market fit. Besides continuously refining tokenomic models, conducting migrations, adjusting emissions, tax mechanisms to turning all nodes into NFTs, there has been a significant and considerable development and incubation of the protocol’s own, cutting-edge products and service
For protocol related data: https://dune.com/samuraifi/protocol
The development of Node RPCs entailed heavy employment of DevOps and Backend engineering to achieve the provision on 3 different blockchains.
Firstly, the DevOps part includes the usage of DigitalOcean droplets as a cloud infrastructure provider. This required an expertise in unix systems to properly, yet securely set up a gateway to support thousands of RPC endpoints. The solution was interfaced with a reverse proxy and with the help of Nginx. Lastly, the endpoints were provided on Avalanche's C-Chain, Polygon, and of course Fantom Opera.
One of the issues encountered during the setup was authorization. The node RPCs should ideally be made available only to node holders, however, it proved to be a challenging task to generate an RPC URL with endpoints such that they would be difficult to guess and remain static to node holders. The solution, which was found to be suitable was made using Universally Unique Identifiers (UUID) which were pre-computed from hashes using the wallet address and node names as unique seed inputs. This guaranteed, that given a specific node name and a wallet address, the UUID output would always statically remain the same. Furthermore, by using a UUID endpoint it became significantly more difficult to guess other node holders' RPC endpoints as opposed to using a simple incremental index.
Arguably, the pre-computed UUID could be guessed through trial and error, however, the odds are approx. "1 in 2.71 quintillion" and therefore infinitesimal and of no concern. Hence, the RPC endpoints are unique to node holders and their specific nodes and such was the reason for taking an additional albeit extensive step in development to ensure that through a combination of mathematics and engineering, we would deliver a secure, scalable, yet smart solution with pleasant user experience.
The Samurai Lottery was developed using a series of solidity smart contracts on top of the OpenZeppelin and Hardhat stack. One aspect of achieving the results on Samurai Lottery was concerned with the integration of the existing ERC721 upgradeable contract - Honour Nodes. By adding functions to both, the NFT contract and the newly created a Samurai Lottery contract, it enabled the development process to take gas fees optimisation into account as the number of steps could be significantly reduced.
The developed contract itself is also upgradeable using OpenZeppelin's standards, and thus it is composed or a ProxyAdmin contract, TransferUpgradeableProxy contract, and finally the implementation contract itself which hosts the business logic necessary for facilitation of the Samurai Lottery. Additionally, unit tests were written using mocha, chai, chaiAsPromised, and the local Hardhat network to ensure that a high standard of development was applied and that many edge cases were being considered and tested against.
Finally, the frontend ReactJS application was adjusted and the relevant UI components were made with Tailwind and TypeScript to accommodate for the new changes and despite the input validation already being processed on the ends of the smart contracts, the client application also verified the ownership of Honour Nodes NFTs in order to fail fast before extending the calls to the Fantom blockchain. Lastly, the contract ABI and address were statically bundled with the client build to be loaded into the ethersjs library.
The development involved a combination of web 2.0 and web 3.0 technologies, and as such, stacks such as NodeJS, NestJS, ExpressJS, Railway, and Solidity were utilised to develop the AI proposition.
The unique aspect of this solution lies in the delegation of the xHNR token transfer. The crucial aspect of combining web 2.0 and web 3.0 worlds is atomicity of the operations - i.e., once the tokens are received as payment, the AI must generate and return output. The risk of not returning output upon transfer succession is amplified when the process is detached (user signs the transaction, NodeJS backend listens and waits for receival and then outputs). Hence, a more streamlined and efficient solution, was to delegate all the tasks to the NodeJS server written using NestJS to produce an injectable service (through inversion of control) which can wrap both operations, the token transfer and the generation, into a single function which ensures that either both actions pass or none will. Hence, a smart contract in Solidity was produced to become an allowances delegate for users to individually authorize, and subsequently, the backend calls the contract in order to transfer the allowed number of xHNR tokens.
The backend application was subsequently deployed to Railway with an established CI/CD pipeline in order to provision a simple deployment stack between staging and production. This was a push to extend more technological stacks in order to diversify as many components as possible to achieve the highest possible uptime as it is the core belief and foundation of blockchain powered applications.
The Vaults smart contract was developed in parallel with vexHNR and prototyped numerous times to ensure that it will reliably store the deposited nodes and tokens for their specified number of blocks. Significant part of the development was spent on unit testing in mocha, chai, Hardhat, and lastly security as the resulting contract is completely immutable once the feature reaches production.
A key decision lied in the architecture of this feature and the fact that the previous development experiences have led the planning procedure to split the vexHNR and Vaults contracts into their own respective contracts instead of coding everything into a single contract. This allows the Q&A step to properly test the individual contracts independently of each other and more frequently.
Lastly, the frontend application was developed in ReactJS, Tailwindcss, and TypeScript. The application was statically exported and deployed to Fleek on a custom subdomain where it is hosted on the underlying IPFS technology to maximise the decentralised nature of dApps.
Samurai Levels is a unique gamified experience which consists of a smart contract, heavy content creation for the players, and a responsive web user interface.
The Solidity smart contract has features for tracking XP levels and streaks which in turn, using the latter, can amplify the rewards. It takes block time into its account when performing calculations and state level updates for the streaks in a mapping of players.
The gamified experience was released with a set of web 3.0 related questions with varying difficulty levels. The content is a long set of questions which were written by the core development and knowledge base team with critical information double checking.
The UI was created using the standardised ReactJS, Tailwindcss, and TypeScript stack which has infrastructure based on Fleek and IPFS. Subsequent improvements to the user experience and small bug fixes were made and released in with respect to some feedback from community members. The CI/CD utilisation and build process on Fleek has allowed the patches to be deployed hastily.
Samurai Zen consists of a Solidity smart contract which contains features for Single Side Staking using the xHNR token and its LP tokens from SpookySwap. The calculations, careful planning steps, as well as the drawed inspiration from other protocols has allowed the development process to produce a feature, which is not only highly secure (contains an emergency withdrawal function) but also lead to the complex Multichain expansion across many other chains.
The Samurai Zen contract has proven to work well on Samurai's home chain FTM. Therefore, the decision was made for the smart contract to be redeployed on ETH, MATIC, BSC, and AVAX chains along with their respective wxHNR tokens which are emitted as rewards. However, as the only liquidity pool for xHNR is available on Fantom, the need for a custom solution was met with MultichainReceiver and MultichainSender contracts. These contracts, in essence, are a very minimised, yet robust, versions of other bridging technologies. The goal was to implement a mechanism which would allow users on opposing ETH, MATIC, BSC, or AVAX chains with their wxHNR tokens to be able to bridge them back to Fantom and receive xHNR. The solution was further implemented using a NodeJS backend written using the NestJS framework. This allowed the microservice on the backend to expand further with a scheduled CRON job which continually synchronises a PostgreSQL database to queue up tasks. The PSQL database is interfaced through NestJS using TypeORM which takes care of queries, write transactions as well as migration files to ensure that the synchronisation cannot be corrupted by development mistakes.
Hence, the most complex aspect is synchronisation of emitted events from MultichainReceivers on opposing chains to later trigger MultichainSender on Fantom to schedule the bridging actions from wxHNR to xHNR. Therefore, the NodeJS server could be understood as a synchronisation middle man between the opposing chains and Fantom to facilitate these transfers. Lastly, the server has infrastructure (along with the PostgreSQL database) hosted on Railway and emits a log of events to Railway as well.
Enact the initiative Transfer assets