Completing the issue description and arriving at a conclusion is the deliverable of this issue.
Design - sBTC Operation Clarity Contract Fees
This ticket holds the design for paying for sBTC operation clarity contract call fees and how it fits into sBTC-v1.
This ticket addresses how the fees of the protocol level Clarity contracts will be covered.
This ticket is NOT about how users will make contract calls to manipulate their sBTC after they have deposited into the system.
This ticket motivates the existence of the Sponsor API: #49
1. Summary
The protocol level deposit and withdrawal clarity contracts will be sponsored by an address that already has STX. This decision is based off the complexity of other approaches, and the fact that sBTC-v1 is not scoped to include any changes to stacks-core.
2. Context & Purpose
In subsequent releases of sBTC the Stacks Signers will maintain sBTC operations and can force Stacks miners to include the sBTC contract calls for no fee, but in sBTC-v1 the sBTC Bootstrap Signers will have to call the clarity contracts like any other user; this means they'll need to pay fees.
How are sBTC operation contract call fees paid, and by whom?
The deposit and withdrawal clarity contracts should be paid for by a benevolent entity, likely the Stack Foundation. There's no exchanging of sensitive information in sponsoring a transaction, so the benevolence of this entity is not required, just that it is willing to sponsor the transaction.
To achieve this the initial bootstrap launch of sBTC should be released in tandem with an API that receives clarity contract calls to sponsor and returns the signature necessary to pay sponsor the transaction. This API call would require that the API backend has access to a the private key stacks address with the necessary funds. Given the previous design decision on the Emily API to use AWS the API can use Secrets Manager to maintain the private key.
3.1.1 Design Diagram
3.1.2 Considerations & Alternatives
These transactions must have an outside sponsor, so there are two alternatives:
Have the initiator pay for the contract calls
This means sBTC users would need to separately have STX
Have the sBTC Bootstrap Signers pay for the API calls
This additional payment is unacceptable because the sBTC Bootstrap Signers are not inherently incentivized to run the sBTC Bootstrap Signers; doing this would make running an sBTC Bootstrap Signer is an aggressive net lot
Both of these options put the burden of owning or paying STX to people who otherwise shouldn't be.
Completing the issue description and arriving at a conclusion is the deliverable of this issue.
Design - sBTC Operation Clarity Contract Fees
This ticket holds the design for paying for sBTC operation clarity contract call fees and how it fits into sBTC-v1.
This ticket motivates the existence of the Sponsor API: #49
1. Summary
The protocol level deposit and withdrawal clarity contracts will be sponsored by an address that already has STX. This decision is based off the complexity of other approaches, and the fact that sBTC-v1 is not scoped to include any changes to
stacks-core.2. Context & Purpose
In subsequent releases of sBTC the Stacks Signers will maintain sBTC operations and can force Stacks miners to include the sBTC contract calls for no fee, but in sBTC-v1 the sBTC Bootstrap Signers will have to call the clarity contracts like any other user; this means they'll need to pay fees.
How are sBTC operation contract call fees paid, and by whom?
Relevant Discussions
38
42
External Resources
3. Design
3.1 Proposed Component Design
The deposit and withdrawal clarity contracts should be paid for by a benevolent entity, likely the Stack Foundation. There's no exchanging of sensitive information in sponsoring a transaction, so the benevolence of this entity is not required, just that it is willing to sponsor the transaction.
To achieve this the initial bootstrap launch of sBTC should be released in tandem with an API that receives clarity contract calls to sponsor and returns the signature necessary to pay sponsor the transaction. This API call would require that the API backend has access to a the private key stacks address with the necessary funds. Given the previous design decision on the Emily API to use AWS the API can use
Secrets Managerto maintain the private key.3.1.1 Design Diagram
3.1.2 Considerations & Alternatives
These transactions must have an outside sponsor, so there are two alternatives:
Both of these options put the burden of owning or paying STX to people who otherwise shouldn't be.
3.2 Areas of Ambiguity