CB-23Q2-02.1 : Decentralized Staking Pool #844
Replies: 11 comments 11 replies
-
|
There is an open source web app by hiro for stacking pools: https://github.com/hirosystems/btcweb3 There is a smart contract for self service stacking pools, that decentralizes all pool operations but the reward payout: https://github.com/friedger/clarity-stacking-pools |
Beta Was this translation helpful? Give feedback.
-
|
@friedger this is awesome. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Congrats on being awarded this Critical Bounty @BowTiedDeployer This discussion thread should be used for all payment requests for your grant. Please follow these steps:
Your CB fee of $45k will be paid out in (5) $9k payments at the following milestones:
Work with @Macxim |
Beta Was this translation helpful? Give feedback.
-
|
Congrats to @Macxim and @BowTiedDeployer How will this be different to the existing decentralized stacking pool "Fast pool"? It is not clear where/how the money will be spent. Which backend? lol |
Beta Was this translation helpful? Give feedback.
-
|
Milestones in order of implementation:
|
Beta Was this translation helpful? Give feedback.
-
|
Congrats @BowTiedDeployer and @Macxim |
Beta Was this translation helpful? Give feedback.
-
|
Milestone 1 - Smart Contract completed
@will-at-stacks |
Beta Was this translation helpful? Give feedback.
-
|
Not sure how to best provide feedback. Here are some questions and comments:
|
Beta Was this translation helpful? Give feedback.
-
|
From the user perspective, it might be better to have the reward distribution in a separate contract and for the self-service pool to use the same code as fast pool and sBTC mini. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback!
There will be a read-only called from the Front End which will display to the users the amount of liquid stx reserved in the SC
✅
✅
At the moment the user joins the pool he had allowed the SC so all calls afterwards have it by default
Distributing rewards will be able to be claimed by any user, whether in pool or not, taking into account the weights of the stacking participants and the block reward. When the weights are being calculated, they are stored in a map having as a key the reward cycle and the value weight * 1 million (in order not to lose stx for dividing units).
✅
✅
❓We added tests for the weighted balances. What should tests for the half-cycle limits include? |
Beta Was this translation helpful? Give feedback.
-
We are trying to check the reward distribution using integration testing. We are fetching the rewards using this: export const getBlockRewards = async (
network: StacksNetwork,
stacker: string,
burnHeight: number
) => {
const supplyCall = await callReadOnlyFunction({
contractAddress: Accounts.DEPLOYER.stxAddress,
contractName: "main",
functionName: "get-block-rewards",
functionArgs: [uintCV(burnHeight)],
senderAddress: Accounts.DEPLOYER.stxAddress,
network: network,
});
const json = cvToJSON(supplyCall);
console.log(
`Block ${burnHeight} pox addr 1`,
json.value.value.value.addrs.value[0] //.value.hashbytes
);
console.log(
`Block ${burnHeight} pox addr 2`,
json.value.value.value.addrs.value[1] //.value.hashbytes
);
return json;
};This call returns a reward, but the pox addresses who won it seem to be void, even if we have stacked funds for the interrogated blocks: Block 133 pox addr 1 {
type: '(tuple (hashbytes (buff 20)) (version (buff 1)))',
value: {
hashbytes: {
type: '(buff 20)',
value: '0x0000000000000000000000000000000000000000'
},
version: { type: '(buff 1)', value: '0x00' }
}
}
Block 133 pox addr 2 {
type: '(tuple (hashbytes (buff 20)) (version (buff 1)))',
value: {
hashbytes: {
type: '(buff 20)',
value: '0x0000000000000000000000000000000000000000'
},
version: { type: '(buff 1)', value: '0x00' }
}
}@friedger can we check the reward distribution using integration testing? Is the pox address given inside the SC taken into account or it has to be specified to a config related to the integration process? |
Beta Was this translation helpful? Give feedback.
-
Regarding splitting into 2 contracts
Not feasible, because we are using the delegate-stx function to update balances. On the one hand, this would mean we have to write another delegate-stx function inside the balances contract or to make balances-SC calls from the contract containing the stacking functions which is not what we are searching for. On the other hand, If we move the delegate-stx function to the balances contract along with the private functions called by it, It would come out that is no need to split them.
Not feasible, because we want to let the user see directly the pool SC. Implementing a contract which basically calls functions from the other SC is not what we are looking for. |
Beta Was this translation helpful? Give feedback.
-
|
Update: We are approximately 40% done with everything. Next major steps: |
Beta Was this translation helpful? Give feedback.
-
|
Can you make use of lockstacks.com? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for asking. We've looked at the possible flow, the UX differs because of the need to instantiate balance when joining the pool and having the need to claim rewards for a specific block in order to share the rewards across the participants. This results in a need of a list with the blocks won by the liquidity provider's Bitcoin address and a tracking of the claimed ones. Overall there are several differences that result in the need of a very specific interface. Here are the main functionalities placed on a rudimentary front end design and this is the user flow |
Beta Was this translation helpful? Give feedback.
-
|
Showing won blocks and more details of miners is part of the roadmap of lockstacks.com I don't see why the functionality could not be integrated into the site. |
Beta Was this translation helpful? Give feedback.
-
|
Milestone 4 completed - Bridge STX <-> BTC with the main incentive for miners and stackers
Gitbook |
Beta Was this translation helpful? Give feedback.
-
|
Milestone 3 completed - Front End
Gitbook |
Beta Was this translation helpful? Give feedback.
-
|
Is this a good description of the outcome? The main flow is that a liquidity provider locks a certain amount of stx in a smart contract, let's say 100k STX. It should be an estimate of the rewards for the next cycle. Then pool members extend their stacking knowing that there will be up to 100k of STX in rewards. The distribution happens by submitting each bitcoin block that was a reward slot for the pool to the reward-vault contract. With that, stackers can get their share immediately when the pool received a reward using a price oracle for btc/stx minus a 5% fee that is transferred to the liquidity provider at the same time. At the end of the cycle all remaining stx from the reward vault can withdrawn by the liquidity providerand the liquidity provider keeps the btc rewards. If the reward vault was emptied by the reward distribution before the last reward slot, then the liquidity provider made an additional profit. |
Beta Was this translation helpful? Give feedback.
-
|
In the docs there is still pox-2 referenced. Do you have already some instructions how to test? |
Beta Was this translation helpful? Give feedback.
-
|
We are updating it to pox-3. |
Beta Was this translation helpful? Give feedback.
-
Introduction:
sBTC is a SIP-010 fungible token on the Stacks blockchain that can be used in DeFi protocols, NFT marketplaces, DAOs, governance, and several other use-cases. The sBTC Bridge is a trustless two-way mechanism that allows users to wrap and unwrap BTC as sBTC. The consensus mechanism relies on validation from users that are currently stacking STX tokens. Also known as Stackers.
These added responsibilities related to transaction signing for Stackers could result in centralization risks should too many Stackers delegate their signing responsibilities to centralized Stacking Pool Operators. In order to counter this risk, Decentralized Stacking Pools must be prioritized.
Critical Bounty Mission Statement:
The purpose of this Critical Bounty is to support the development of trustless Decentralized Stacking Pools.
An interesting, complement to this bounty is the exploration of using the Decentralized Stacking Pool system delivered to add liquidity to Decentralized Mining Pools (in the form of BTC) and/or bridges (in the form of xBTC and/or sBTC) via the rehypothecation of BTC rewards earned via Stacking.
Functionality / Deliverables (shall include, but not be limited to):
Required Knowledge / Skills:
References:
Critical Bounty Fee:
Reviewers / Advisors:
Igor Sylvester, Core Engineering Lead, Trust Machines
Jude Nelson, Research Scientist, Stacks Foundation
Tycho Onnasch, General Manager, Trust Machines
Friedger Müffke
Andre Serrano, sBTC Resident and sBTC Go To Market Working Group Lead
Jesse Wiley, Integration and Security Lead, Stacks Foundation
Kenny Rogers, Developer Advocate, Stacks Foundation
Will Corcoran, Grants Lead, Stacks Foundation
Additional Comments:
Recipient will be expected to attend sBTC Core Engineering Working Group calls while the bounty is in development and provide weekly updates.
APPLY HERE
NOTES ABOUT CRITICAL BOUNTIES:
If you have thoughts, questions, or comments on the rough outline for this Critical Bounty above, please comments below.
Please note, all 2023 Q2 Critical Bounties that have funding approved for them will be moved to the Issues page (here) on Tuesday 03/21/2023.
Some procedural items to keep in mind with 2023 Q2 Critical Bounties:
Beta Was this translation helpful? Give feedback.
All reactions