Completing the issue description and arriving at a conclusion is the deliverable of this issue.
Design - sBTC Signers Update the Emily API
This ticket holds the design of the Emily sidecar and how it fits into sBTC-v1. Specifically, how the sBTC signers themselves would keep the Emily API up to date.
1. Summary
The Emily API needs to receive updates from some binary that has access to the Stacks Node. The sBTC signers already have access to the stacks node and will consume updates from an event observer. The alternative is to have a separate event observer with a different stacks node update the Emily API, but this seems to make less sense because it would require more nodes to be deployed and introduces a new binary that is important to maintaining the system.
2. Context & Purpose
Relevant Research Discussions
External Resources
3. Design
3.1 Proposed Component Design
3.1.1 Design Diagram
3.1.2 Considerations & Alternatives
3.2 Areas of Ambiguity
Closing Checklist
[ ] The design proposed in this issue is clearly documented in the description of this ticket.
[ ] Everyone necessary has reviewed the resolution and agrees with the proposal.
[ ] This ticket has or links all the information necessary to familiarize a contributor with the design decision, why it was made, and how it'll be included.
AshtonStephens
commented
5 hours ago
Completing the issue description and arriving at a conclusion is the deliverable of this issue.
Design - sBTC Signers Update the Emily API
This ticket holds the design of the Emily sidecar and how it fits into sBTC-v1. Specifically, how the sBTC signers themselves would keep the Emily API up to date.
1. Summary
The Emily API needs to receive updates from some binary that has access to the Stacks Node. The sBTC signers already have access to the stacks node and will consume updates from an event observer. The alternative is to have a separate event observer with a different stacks node update the Emily API, but this seems to make less sense because it would require more nodes to be deployed and introduces a new binary that is important to maintaining the system.
2. Context & Purpose
Relevant Research Discussions
External Resources
3. Design
3.1 Proposed Component Design
3.1.1 Design Diagram
3.1.2 Considerations & Alternatives
3.2 Areas of Ambiguity
Closing Checklist