Initial CBTC BTC Implementation #4443
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #DS-990
Description
Adds a new CBTC Bitcoin Proof of Reserves adapter that queries Bitcoin blockchain UTXOs directly to verify BTC reserves across configured vault addresses.
Changes
@chainlink/dlc-cbtc-btc-por-adapterpackageSteps to Test
Build the adapter:
Run unit tests:
Start the adapter locally:
Query the reserves endpoint:
Verify the response returns total reserves in satoshis:
{ "result": 301089400, "data": { "result": 301089400 }, "statusCode": 200 }Quality Assurance
If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant
infra-k8sconfiguration file.If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant
adapter-secretsconfiguration file.If a new adapter was made, or a new endpoint was added, update the
test-payload.jsonfile with relevant requests.The branch naming follows git flow (
feature/x,chore/x,release/x,hotfix/x,fix/x) or is created from Jira.This is related to a maximum of one Jira story or GitHub issue.
Types are safe (avoid TypeScript/TSLint features like any and disable, instead use more specific types).
All code changes have 100% unit and integration test coverage. If testing is not applicable or too difficult to justify doing, the reasoning should be documented explicitly in the PR.