Sandblizzard is an ambitious project to allow anyone to attach bounties to whatever object that can be completed. The first version will focus on bounties attached to issues on github.
The User Experience
From the screenshot below you can see the UX.
By appending $<token_name>:<token_amount>$ to the end of a github issue a new bounty will be created. Instead of forcing users to use a separate website to manage and create bounties we allow users to create them where they do work.
After the issue is solved the owner just have to type the solvers and they will instantly receive their share of the bounty.
Motivation
An important part of the Sandblizzard bounty contract is to able to escrow funds. The action is triggered when one of the relayers indicates that there has been issued a bounty. The bounty contract serves another purpose as well, namely to store data about the bounty and domain.
1. Program State
Domain
The domain is what to be observed by the relayers. If a user wants a domain indexed they need to register it with the smart contract.
The domain state contains the information:
- Owner (Pubkey): The owner of the domain. This is the one who created the domain in the first place and therefore have the access rights to disable the domain.
- Active (bool): Whether or not the domain should be indexed by the relayers.
- Domain (DomainIdentifier): This is a struct keeping information about the domain to be indexed
The data in DomainIdentifier is
- Platform<string>: which platform or service being used to issue bounties. Examples are Github, AirTable, Jira etc
- Domain<string>: this is typically organizations such as Sandblizzard.
- Sub domain<string>: this could be team or sub team inside a sub domain
- Domain type<string>: is the type of the domain. This could be issues, pull requests, tasks etc.
- URL<option<String>>: the url that points to the domain to be indexed. This could be sandblizzard/rewards_v1/issues. The parameter is optional because it can be built from the other arguments.
In the case of the Sandblizzard rewards issue board the params would be
- Platform: github
- Domain: sandblizzard
- Sub domain: rewards-v1 (the repository)
- Domain type: issues
- URL: sandblizzard/rewards-v1/issues
With this information, any relayer can read the domain from the solana blockchain and relay information. Of course, this requires that the relayer is added to the Sandblizzard mesh of relayers.
Bounty
The bounty holds data about the created bounty. The fields necessary are
- Owner<Pubkey>: This is the one who created the bounty, and also the one who is allowed to complete it.
- Mint<Pubkey>: Mint of the bounty amount. Note: the mint need to match an existing bounty denomination on completion.
- State<Enum>: The state of the bounty: Created or Completed
- Escrow<Pubkey>: Public key of the account holding the bounty while the task is being solved.
- Domain<Pubkey>: Public key of the domain where the bounty is issued.
- Bounty_Amount<u64>: The issued reward in the mint.
- completed_by: Option<Vec<Pubkey>>: The users who completed the bounty. This is populated when the bounty is completed.
Relayer
Relayer in this context is pretty similar to the same term used for bridge relayers. The relayer is responsible to observe and take action accordingly.
In the case for the Sandblizzard bounty system it’s main role is to observe domains and report if there are changes to the bounties.
As a reward, the relayer receives parts of the bounty.
Denomination
Similar to how DeFi protocols allow various tokens to be traded we would also like to enable as many SPL tokens to be used as rewards. Since we aren’t that sensitive to volatility in the tokens we will from the outset support the addition of any token.
One of the key ideas behind Sandblizzard is to allow anyone to create rewards in any token they wish. Therefore, we will allow anyone to create denominations.
The denomination accounts are used in the creation of bounties and are independent of the domain.
The fields are
- mint<Pubkey>: The mint to be used to denominate bounties in.
- active<bool>: Whether the denomination is active.
- fee_collector<Pubkey>: The protocol fee collector.
2. Endpoints ( instructions )
- Initialize: Initializes the protocol
- Add_relayer: Allows the owner of the protocol to add a relayer
- Remove_relayer: Allows the relayer or the owner to deactivate the relayer
- Add_bounty_denomination: Allow more bounty denomination
- Deactivate_bounty_denomination: Deactivate a bounty denomination
- Create_domain: Create a new domain to be indexed by the relayers
- Deactivate_domain: Deactivate a domain
- Create_bounty: Create a bounty associated with a domain
- Complete_bounty: Complete a bounty and distributed the rewards. If there are no solvers then the bounty will go back to the creator.
Conclusion
We plan to release our beta program soon. If you think you qualify then please create a pull request against
https://github.com/sandblizzard/beta-users
This will allow you to become one of the first users to mint your NFT and take part in the future of internet bounties.
