[Research]: Deposit API Service (formerly Revealer API)

[AshtonStephens]

Research - Deposit API Service (formerly Revealer API)

This ticket holds the research relating to the sBTC revealer API service and how it impacts sBTC-v1.

Details here: #1

1. Summary

This discussion finalized the need for an external API, referred to as "Signer API", for allowing deposits in sBTC. The implementation details have not been concluded yet.

2. Context & Relevance

The need for a two-phase commit-reveal scheme for sBTC transactions arose to accommodate users to peg-in their BTC from custodial wallets. In the designs and documents that followed this decision, the "Revealer" component acts as an intermediary service for its API to be called by external user-facing applications to accept deposit requests and for stackers/signers to poll for pending addresses and tapscript data.
This discussion revisited this component to redefine and clarify its necessity/purpose for sBTC V1.

3. Research

3.1 Proposed Research Conclusions

1. For sBTC V1, we want to proceed with an API-only approach for accepting deposits so this service is definitely needed.

2. To not confuse it with previous commit-reveal discussions, we call this the "Signer API".

3. We have different options for the design/implementation aspect of this service:
   3.1. Having a hosted service maintained by a non-consensus/centralized party
   Pros:

   • Easily manageable, we can ensure availability

   Cons:

   • It's centralized, it's not tied to Stacks chain

   3.2. Having the ability to register a Signer API on the Stacks chain
   Pros:

   • It's not centralized and tied to Stacks

   Cons:

   • Extra contract call fees

The general agreement is that we don't want the signers to expose public endpoints so we want the external facing API to be separate from the signer binary.

3.2 External Resources

3.3 Areas of Ambiguity

---

Closing Checklist

• The takeaway from this issue is clearly documented in the description of this ticket.
• Everyone necessary has reviewed the resolution and agrees with the takeaways.
• This ticket has or links all the information necessary to familiarize a contributor with the topic and how it was resolved.

[hstove]

I think it's really important to prioritize not having the signer binary be publicly reachable. Even though we'll almost certainly need the signer to expose some HTTP endpoint, we do not have to have the signer's IP be publicly known. It just adds too much security risk.

I understand the pushback of a third-party service being potentially seen as "more centralization", but it's functionally the same as a signer developing their own proxy and then making that publicly known.

[AshtonStephens]

It sounds like it could make sense to have some external coordinator makes more sense for sBTC-v1. As opposed to the coordinator being sent around to the different signers it could be a single entity.

Scrapped this per #37

[8marz8]

To help conclude this topic, I'll mention the discussed points and my potentially inaccurate assumptions here again:
(Hoping a visible pros and cons list can help us choose)

If we only have the Deposit API:

+ We can avoid extra contract calls - faster and no fees
+ We can have the Deposit API to fulfill the coordinator role for deposits (Note: this won't satisfy the coordinator need for withdrawals so I'm not sure if this would solve ALL coordinator issues) -- N/A per #37
+ Although this requires additional development efforts, this component can be used for revealing deposits for Burnchain unilateral support in V2
- Another new component that we'd need to manage and develop
- Centralized
- Less on-chain visibility (only mint call will be visible on-chain - but not the initial deposit request, or deposit-accept/reject steps)

If we only support deposits through contract calls:

+ Decentralized
+ More on-chain visibility
+ Consistent sBTC interaction for users between withdrawal and deposits
+ No need to develop and maintain a new service/component
- Contract call overhead - latency and fees
- For supporting unilateral transactions in V2, I think we'd still need the API, so we'll need to revisit this again later (as it was originally called the Revealer API - I am not 100% sure about this)

Any other strong opinions for not having the API and only going with making deposits through contract calls (similar to withdrawal)? My impression was that we really want to avoid the latency/cost.

UPDATE: I'm leaning more towards the contract route now given that maybe we could reuse more of sBTC mini. Additionally, I think the API can be added anytime later, or developed asynchronously but it doesn't have to be the initial promise to users for how to interact with sBTC for deposits.

[AshtonStephens]

UPDATE: I'm leaning more towards the contract route now given that maybe we could reuse more of sBTC mini. Additionally, I think the API can be added anytime later, or developed asynchronously but it doesn't have to be the initial promise to users for how to interact with sBTC for deposits.

That makes a lot of sense to me as a promise. Though I'm losing track of what sBTC ops come from where.

• Withdrawal (maybe) Bitcoin + Clarity: Handling Bitcoin forks in sBTC v1 #12 + [Research]: Withdrawal Script #17 ?
• Deposit (maybe) Bitcoin + Clarity: (this conversation) ?

[8marz8]

• Deposit (maybe) Bitcoin + Clarity: (this conversation) ?

For Deposit, the contract call approach was mentioned in this discussion (Deposit -> proof of deposit -> first point) and was part of this initial diagram (left flow from user to sbtc contract)

[8marz8]

We discussed how having access to stx before making a deposit (for the contract call route) could be a downer for users. Some sponsorship model from the past was brought up. New discussion made: #38
Maybe this could help us decide on the final ingress route for deposits

[hstove]

It's not clear to me what the advantage of using contract calls for revealing deposits is. It's not more censorship resistant (at least in terms of getting your deposit finalized), as it's still up to the signers to approve each deposit.

From my perspective, the overhead of requiring two transactions (one on BTC and one on Stacks) is a huge downside. Especially if we require proving your deposit on Stacks - that means you have to wait 2 Bitcoin blocks just to get your deposit "pending" (one block to confirm the BTC tx, then 1 block to prove tx inclusion on Stacks).

[8marz8]

It's not clear to me what the advantage of using contract calls for revealing deposits is. It's not more censorship resistant (at least in terms of getting your deposit finalized), as it's still up to the signers to approve each deposit.

Since the extra fee and wait overhead is a bigger "con" from the user experience, then maybe it's safe to conclude this ticket with the "Deposit API" route.

[AshtonStephens]

Gained consensus for the Deposit API option.

Next step is to design the Deposit API calls and API call flows.