Blog:
Humming Human - a collaboration with Hummingbot
We are delighted to collaborate with Hummingbot to build Humming Human, a project to support the creation of a public infrastructure that can be used to verify and reward on-chain activity on DEXs and other DeFi platforms.
Hummingbot is an open-source project that allows users to arbitrage price differences between exchanges – both centralized and decentralized – while providing overall market liquidity.
The Humming Human project utilizes the HUMAN Protocol Recording Oracle layer to allow anyone to earn tokens for providing volume and or liquidity to given platforms. While the Recording Oracle operates off-chain, it will feed its information to power on-chain smart contracts. The project will result in the creation of decentralized reward pools.
We believe that transparent on-chain reward systems like Humming Human will power the future of on-chain work, for both humans and bots.
Humming Human will allow any DEX to crowdsource verified, on-chain liquidity and trading volume from a decentralized set of market participants.
To breakdown the specifics, Humming Human aims to:
● Use a HUMAN Recording Oracle to verify the on-chain trading volume and liquidity provided by a certain wallet address for a specific pool on a DEX on an EVM-compatible blockchain
● Allow a ‘funder’ to fund token reward pools held in the smart contract
● Enable wallet addresses that have provided verified volume and liquidity over a certain timespan to request and withdraw compensation from the reward pool
The HUMAN Grants committee will vote on allocating HMT tokens to incentivize developers to build this project. Hummingbot will propose a governance proposal to allocate HBOT to do the same. Together, our respective communities can collaborate to build out this technology, which has two main pieces:
● A payouts contract that holds deposits of reward tokens and allocates them to addresses that provide verifiable DEX activity
● An oracle contract and off-chain service that verifies DEX activity for the payouts contract
● Description
○ Allows a funder to fund a campaign for a given trading pair on a DEX over a certain period. This will create an escrow contract on the human protocol of the particular liquidity campaign.
● Parameters:
○ start_block: starting block
○ end_block: ending block
○ exchange: address of exchange contract
○ tokenA: first token in trading pair
○ tokenB: second token in trading pair
○ type: “volume” or “liquidity”
○ msg.value: ETH or ERC-20 tokens allocated as reward
● Logic
○ Deposits tokens in smart contract and instantiates campaign with a new campaign_id
○ Returns campaign_id if successful
● Description
○ Enable a wallet that has provided volume and liquidity to a certain DEX to request compensation from the reward pool. This alerts the record oracle to start indexing transactions on this address and recording any liquidity activity.
● Parameters
○ msg.sender: calling wallet address
○ campaign_id: id of campaign issuing rew]ards
○ start_block: starting block
○ end_block: ending block
○ exchange: address of exchange contract
○ tokenA: first token in trading pair
○ tokenB: second token in trading pair
○ type: “volume” or “liquidity”
● Logic
○ Check if campaign_id exists
○ Call verify method on oracle contract to retrieve user activity
○ Move amount of tokens from reward pool into account that user can extract from
● Description
○ Returns on-chain activity for a given address in a certain trading pair on a DEX. This can be used by the recording and reputation oracle to track how successful a given liquidity provider was at tracking the campaign.
● Parameters
○ msg.sender: calling wallet address
○ start_block: starting block
○ end_block: ending block
○ exchange: address of exchange contract
○ tokenA: first token in trading pair
○ tokenB: second token in trading pair
○ type: “volume” or “liquidity”
● Logic
○ If type == volume, return quantity of tokenA and tokenB swapped by msg.sender on exchange from start_block to end_block
○ If type == liquidity, return avg quantity of tokenA and tokenB added to pool by msg.sender over each block from start_block to end_block