Create and Initialize a Farming Contract
At the heart of Covenant farming architecture is the Farming Factory, which is encoded with the standard logic of the model farming contract. Hosts use the Factory to clone and customize the model to create their own contracts.
Covenant Farming v1.0 contracts can contain multiple 'Generation 1' Free Farming setups and Locked Farming setups. Farming v1.0 supports the AMM Aggregator so that setups can be created using all AMMs supported by the AMM Aggregator such as Uniswap v2, Sushiswap, Mooniswap, Balancer.
Hosting
Any DFO, DAO, dApp, individual wallet or customized smart contract can host Covenant farming contracts. The flexible design of the contracts makes it easy for hosts to set rules for distributing rewards to farmers (from a reserve or by minting), while preventing hosts from touching farmer tokens or manipulating rewards for Locked positions. This secures farmers from exploitation.
A host has the power to control the extension linked to the hosted farming contract, allowing them to call specific functions. For example, they can:
set a new host
update the treasury
address
update setups
deactivate setups
Create a Farming Contract
Hosts use the deploy
function to have the Factory clone the model (which, as mentioned, contains the standard logic):
When the Factory does this, it calls the initialize function for the farming contract, passing the encoded data as a data parameter.
The init
function works as follow:
extension
-> theaddress
of the deployed extension to be linked to the contractextensionInitData
-> the encoded initialize extension data (available if aninit
extension function is provided). The default extension's init data contains three parameters: a boolean value representing if the reward token is minted (true
) or from reserve (false
); the host address; and the treasuryaddress
.orchestrator
-> theaddress
of the Item OrchestratorrewardTokenAddress
-> theaddress
of the reward token of the contract. Each contract has one.farmingSetupInfoBytes
-> ABI-encoded data of the contract's setups, which can be created directly during the initialization phase.
The extension (whether default or custom) must be deployed before deploying the farming contract through the Factory's deploy
function. This allows the deployed extension to be linked to the Farming contract through the Farming contract init
function. As noted above, the deployed extension doesn't need to have been initialized before this (and thus an init
function is not provided), but can be done directly through the contract's init
function, passing the extensionInitData
in the payload
.
If the extension has an init
function, it will be called, otherwise not:
The init
function creates the contract reference Item collection by calling the createNative
method using the Item Orchestrator. So, each contract has its own native Item collection. This collection is used to manage farm tokens related to the liquidity management of locked setups:
If the farmingSetupInfoBytes
parameter was passed in init
function, the _setOrAddFarmingSetupInfo
function is called internally to create all the passed setups:
Otherwise setups can be created directly using the setFarmingSetups
function (look at the Add New Farming Setups to a Contract section to see how to customize setups and create new ones).
Send Reward Tokens to the Extension
The extension must receive at least enough tokens needed to reward every setup created for the contract. If not, the setups will be correctly created within the contract, but cannot be activated.
If any reward tokens are from a reserve, it is best practice to deploy the contract and the extension and then immediately send to the extension the minimum amount of reward tokens to activate all setups.
If the host is a wallet or similar, simply send the required amount of reward tokens manually via a transfer function (or simply transfer the tokens to the extension address using a provider such as Metamask).
If the host is a DFO, DAO or other types of organization, you must use the appropriate procedure to transfer the tokens. For example, if the host is a DFO, make a proposal to install in it the manageFarming
microservice (only the first time, not if you create more contracts in the future), and enable the extension in the DFO StateHolder
(this must be done every time). This will authorize you to retrieve the required amount of reward tokens from the DFO's treasury to be sent to the farming contract's extension:
After the extension has received the tokens, the host does not need to then manually transfer them to the farming contract. This will happen automatically when the setup(s) are activated.
See the Activate/Deactivate section for more details.
Last updated