├── .gitignore ├── sips ├── sip-029 │ ├── sip-029-1.pdf │ ├── sip-029-2.pdf │ ├── sip-029-4.xlsx │ └── sip-029-halving-alignment.md ├── sip-012 │ ├── SIP-012-001.ods │ └── scripts │ │ ├── README.md │ │ ├── generate-artifacts.sh │ │ ├── extract-delegates.sh │ │ └── extract-stackers.sh ├── sip-018 │ └── SIP-018-001.png ├── sip-021 │ ├── MEV-Report.pdf │ ├── nakamoto-votes.zip │ ├── tenure-change-overview.png │ ├── sortition-stacksblock-relationship.png │ ├── Weighted-Schnorr-Threshold-Signatures.pdf │ ├── FROST-Flexible-Round-Optimized-Schnorr-Threshold-Signatures.pdf │ └── miner-protocol.d2 ├── sip-015 │ └── sip015-vote-main.zip ├── sip-031 │ ├── sip031-votes-script.zip │ ├── Nomiks_Analysis_5Y_Plan_Final.pdf │ ├── blockchain_projects_50_2024_inflation_rate.pdf │ └── summary_of_benefits.md ├── sip-027 │ ├── results │ │ ├── multisig-solo-votes.csv │ │ └── multisig-pool-votes.csv │ └── scripts │ │ └── validate-and-count-votes │ │ ├── package.json │ │ └── nonStackerVotes.js ├── README.md ├── sip-019 │ └── token-metadata-update-notify.clar ├── SIP_TEMPLATE.md ├── sip-025 │ └── votes.csv ├── sip-024 │ └── sip-024-least-supertype-fix.md ├── sip-023 │ └── sip-023-emergency-fix-traits.md ├── sip-020 │ └── sip-020-bitwise-ops.md ├── sip-034 │ └── sip-034.md ├── sip-009 │ └── sip-009-nft-standard.md └── sip-008 │ └── sip-008-analysis-cost-assessment.md ├── considerations ├── README.md ├── minutes │ ├── TEMPLATE.md │ ├── technical-cab │ │ ├── 2024-07-06-sip-block-headers.md │ │ ├── 2024-11-14-sip-aligning-incentives.md │ │ ├── 2024-06-25-sip-WSTS.md │ │ ├── 2023-05-17-sip-024.md │ │ ├── 2023-05-01-sip-023.md │ │ ├── 2025-10-17-sip-034.md │ │ ├── 2024-01-31-sip-021.md │ │ ├── 2023-10-27-pr-152-153.md │ │ ├── 2025-03-05-sip-030.md │ │ ├── 2022-11-23-sip-020.md │ │ ├── 2023-04-26-sip-022.md │ │ ├── 2025-07-16-sip-031.md │ │ ├── 2022-10-27-sip-015.md │ │ ├── 2024-01-24-sip-021.md │ │ ├── 2022-11-02-sip-015.md │ │ └── 2025-10-06-sip-033.md │ ├── economic-cab │ │ ├── 2025-06-18-sip-031.md │ │ ├── 2024-02-01-sip-021.md │ │ └── 2022-10-29-sip-015.md │ └── governance-cab │ │ ├── 2024-02-02-sip-021.md │ │ ├── 2023-05-01-sip-023.md │ │ ├── 2021-11-05-sip-012.md │ │ ├── 2023-05-17-sip-024.md │ │ ├── 2022-11-17-sip-015.md │ │ ├── 2025-10-17-sip-034.md │ │ ├── 2025-06-23-sip-031.md │ │ ├── 2025-06-09-sip-031.md │ │ ├── 2022-10-31-sip-015.md │ │ ├── 2024-10-21-sip-028.md │ │ └── 2023-04-20-sip-022.md ├── ethics.md ├── diversity.md ├── TEMPLATE.md ├── steering-committee.md ├── sip-editors.md ├── technical.md ├── economics.md └── governance.md └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | *.swp 2 | .DS_Store 3 | *.orig 4 | *.rej 5 | 6 | .aider* 7 | -------------------------------------------------------------------------------- /sips/sip-029/sip-029-1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-029/sip-029-1.pdf -------------------------------------------------------------------------------- /sips/sip-029/sip-029-2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-029/sip-029-2.pdf -------------------------------------------------------------------------------- /sips/sip-012/SIP-012-001.ods: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-012/SIP-012-001.ods -------------------------------------------------------------------------------- /sips/sip-018/SIP-018-001.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-018/SIP-018-001.png -------------------------------------------------------------------------------- /sips/sip-021/MEV-Report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-021/MEV-Report.pdf -------------------------------------------------------------------------------- /sips/sip-029/sip-029-4.xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-029/sip-029-4.xlsx -------------------------------------------------------------------------------- /sips/sip-021/nakamoto-votes.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-021/nakamoto-votes.zip -------------------------------------------------------------------------------- /sips/sip-015/sip015-vote-main.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-015/sip015-vote-main.zip -------------------------------------------------------------------------------- /sips/sip-031/sip031-votes-script.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-031/sip031-votes-script.zip -------------------------------------------------------------------------------- /sips/sip-021/tenure-change-overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-021/tenure-change-overview.png -------------------------------------------------------------------------------- /sips/sip-031/Nomiks_Analysis_5Y_Plan_Final.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-031/Nomiks_Analysis_5Y_Plan_Final.pdf -------------------------------------------------------------------------------- /sips/sip-021/sortition-stacksblock-relationship.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-021/sortition-stacksblock-relationship.png -------------------------------------------------------------------------------- /sips/sip-021/Weighted-Schnorr-Threshold-Signatures.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-021/Weighted-Schnorr-Threshold-Signatures.pdf -------------------------------------------------------------------------------- /sips/sip-031/blockchain_projects_50_2024_inflation_rate.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-031/blockchain_projects_50_2024_inflation_rate.pdf -------------------------------------------------------------------------------- /sips/sip-027/results/multisig-solo-votes.csv: -------------------------------------------------------------------------------- 1 | voter,txid,for,power 2 | SP3573HMB9SPCTMT85YS85KEPYCX33E6MZGQ5QB2A,0x0bd70b5b1c95c87790644beedaa1b0141aed4e1f8a154f075771049d74bce1e1,true,3449000000000 -------------------------------------------------------------------------------- /sips/sip-021/FROST-Flexible-Round-Optimized-Schnorr-Threshold-Signatures.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/stacksgov/sips/HEAD/sips/sip-021/FROST-Flexible-Round-Optimized-Schnorr-Threshold-Signatures.pdf -------------------------------------------------------------------------------- /sips/README.md: -------------------------------------------------------------------------------- 1 | Stacks Improvement Proposals 2 | ============================ 3 | 4 | Each directory here contains a Stacks Improvement Proposal as well as all 5 | supplementary materials. 6 | 7 | New SIPs may be submitted via pull request, but please make sure they adhere to 8 | the standards described in 9 | [SIP-000](./sip-000/sip-000-stacks-improvement-proposal-process.md). 10 | -------------------------------------------------------------------------------- /sips/sip-027/scripts/validate-and-count-votes/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "validate-and-count-votes", 3 | "version": "1.0.0", 4 | "main": "index.js", 5 | "type": "module", 6 | "scripts": { 7 | "start": "node index.js" 8 | }, 9 | "keywords": [], 10 | "author": "", 11 | "license": "ISC", 12 | "dependencies": { 13 | "@stacks/stacking": "^6.15.0", 14 | "@stacks/transactions": "^6.15.0", 15 | "axios": "^1.7.2", 16 | "dotenv": "^16.4.5" 17 | } 18 | } 19 | -------------------------------------------------------------------------------- /sips/sip-021/miner-protocol.d2: -------------------------------------------------------------------------------- 1 | shape: sequence_diagram 2 | 3 | bitcoin: Bitcoin 4 | miner: Miner 5 | stackers: Stackers 6 | 7 | Sortition / Tenure Election : { 8 | miner -> bitcoin: send block-commit 9 | bitcoin."sortition" 10 | bitcoin -> miner: miner observes sortition result 11 | } 12 | 13 | Tenured Miner Loop: { 14 | miner."mine Stacks block" 15 | miner -> stackers: block to StackerDB 16 | stackers -> stackers: StackerDB notification 17 | stackers -> stackers: Stackers validate Block 18 | stackers -> stackers: Stackers sign block 19 | stackers -> miner: Ack 20 | } 21 | 22 | -------------------------------------------------------------------------------- /considerations/README.md: -------------------------------------------------------------------------------- 1 | # Consideration Advisory Boards 2 | 3 | This directory lists the contact information, members, and other details for the Consideration Advisory Boards (CABs) that are part of the Stacks Improvement Proposal (SIP) process. 4 | 5 | Per [SIP-000](../sips/sip-000/sip-000-stacks-improvement-proposal-process.md), these boards vote to advance a SIP from Accepted to Recommended status once it has been reviewed by the board's domain experts. 6 | 7 | _If this CAB interests you and you wish to join the effort, please reach out to @jennymith and @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 8 | -------------------------------------------------------------------------------- /considerations/minutes/TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # INSERT_NAME CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** 6 | 7 | **Recorded:** 8 | 9 | **Date:** Month Day, Year 10 | 11 | **Time:** 24hr time in UTC 12 | 13 | **Attendees:** 14 | 15 | - Full Name 16 | 17 | **Topic(s):** 18 | 19 | - List of topics to be discussed 20 | 21 | **Materials**: 22 | 23 | - List of supporting materials 24 | 25 | ## Meeting Notes 26 | 27 | - List of general meeting notes 28 | 29 | ## Action Items 30 | 31 | - List of action items 32 | - Note markdown format below: 33 | - [ ] open task 34 | - [x] completed task 35 | 36 | ## Vote Outcome(s) 37 | 38 | - List of voting outcomes per CAB member 39 | -------------------------------------------------------------------------------- /considerations/ethics.md: -------------------------------------------------------------------------------- 1 | # Consideration for Ethics SIPs 2 | 3 | Chairperson: Jude Nelson 4 | 5 | Members: 6 | 7 | - Jude Nelson 8 | - Juliet Oberding 9 | 10 | Discussions-to: https://github.com/stacksgov/sips 11 | 12 | Created-by: SIP-000 13 | 14 | ## About 15 | 16 | This consideration advisory board is a place-holder for advancing SIPs from Recommended status. 17 | 18 | Until there are at least three members of this board who are not on the steering committee, it shall be run by the steering committee. 19 | 20 | _If this CAB interests you and you wish to join the effort, please reach out to @jennymith and @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 21 | -------------------------------------------------------------------------------- /considerations/diversity.md: -------------------------------------------------------------------------------- 1 | # Consideration for Diversity SIPs 2 | 3 | Chairperson: Jude Nelson 4 | 5 | Members: 6 | 7 | - Jude Nelson 8 | - Hero Gamer 9 | 10 | Discussions-to: https://github.com/stacksgov/sips 11 | 12 | Created-by: SIP-000 13 | 14 | ## About 15 | 16 | This consideration advisory board is a place-holder for advancing SIPs from Recommended status. 17 | 18 | Until there are at least three members of this board who are not on the steering committee, it shall be run by the steering committee. 19 | 20 | _If this CAB interests you and you wish to join the effort, please reach out to @jennymith and @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 21 | -------------------------------------------------------------------------------- /sips/sip-012/scripts/README.md: -------------------------------------------------------------------------------- 1 | # SIP 012 Vote Tabulation Script 2 | 3 | The main script is `count-votes.sh`. It will count up the votes for/against SIP 012 for a given reward cycle. See `count-votes.sh` for detailed usage information. 4 | 5 | Sample run: 6 | 7 | ``` 8 | $ cat stackers-19.json delegating.json | ./count-votes.sh /tmp/tally-19 4933b0b002a854a9ca7305166238d17be018ce54e415530540aa7e620e9cd86d 705850 9 | {"yes":"10194020608227","no":"0"} 10 | $ cat stackers-20.json delegating.json | ./count-votes.sh /tmp/tally-20 7ae943351df455aab1aa69ce7ba6606f937ebab5f34322c982227cd9e0322176 707951 11 | {"yes":"77064706545373","no":"0"} 12 | ``` 13 | 14 | To generate the artifacts `stackers-19.json`, `stackers-20.json`, and `delegating.json` from a Stacks node's debug log file, run the following: 15 | 16 | ``` 17 | $ ./generate-artifacts.sh /path/to/node/log.txt 18 | ``` 19 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2024-07-06-sip-block-headers.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - July 1st, 2024 12 | 13 | **Time:** 14 | 15 | **Attendees:** 16 | 17 | - 18 | 19 | **Topic(s):** 20 | 21 | - Vote on SIP: Update for get-block-info 22 | 23 | **Materials**: 24 | 25 | - [SIP: Update for get-block-info](https://github.com/stacksgov/sips/pull/178) 26 | 27 | ## 2024-01-31 Meeting Notes 28 | 29 | - 30 | 31 | ### Vote Outcome 32 | 33 | Quorum is reached with 6 eligible CAB members voting on the SIP. 34 | 35 | | Name | Vote | 36 | | ------------ | ------- | 37 | | Dan Trevino | yes | 38 | | Aaron B | yes | 39 | | Mike Cohen | yes | 40 | | Vlad | yes | 41 | | 0xdima95 | yes | 42 | | Jesse Wiley | yes | 43 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2024-11-14-sip-aligning-incentives.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - November 14th, 2024 12 | 13 | **Time:** 14 | 15 | **Attendees:** 16 | 17 | - **Topic(s):** 18 | 19 | - Vote on SIP: Bootstrapping sBTC Liquidity and Nakamoto Signer Incentives 20 | 21 | **Materials**: 22 | 23 | - [SIP-029: Preserving Economic Incentives During Stacks Network Upgrades](https://github.com/stacksgov/sips/pull/196) 24 | 25 | ## 2024-01-31 Meeting Notes 26 | 27 | - 28 | 29 | ### Vote Outcome 30 | 31 | Quorum is reached with 9 eligible CAB members voting on the SIP. 32 | 33 | | Name | Vote | 34 | | ---------------- | ---- | 35 | | Aaron Blankstein | yes | 36 | | Ashton Stephens | yes | 37 | | Brice Dobry | yes | 38 | | j2p2 | yes | 39 | | Friedger | no | 40 | | Jesse Wiley | - | 41 | | Mike Cohen | yes | 42 | | 0xdima | yes | 43 | | setzeus | yes | 44 | | Vlad | yes | 45 | -------------------------------------------------------------------------------- /sips/sip-019/token-metadata-update-notify.clar: -------------------------------------------------------------------------------- 1 | ;; token-metadata-update-notify 2 | ;; 3 | ;; Use this contract to notify token metadata indexers that an NFT or FT needs its metadata 4 | ;; refreshed. 5 | 6 | (use-trait nft-trait 'SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait.nft-trait) 7 | (use-trait ft-trait 'SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard.sip-010-trait) 8 | 9 | ;; Refresh the metadata for one or more NFTs from a specific contract. 10 | (define-public (nft-metadata-update-notify (contract ) (token-ids (list 100 uint))) 11 | (ok (print 12 | { 13 | notification: "token-metadata-update", 14 | payload: { 15 | contract-id: contract, 16 | token-class: "nft", 17 | token-ids: token-ids 18 | } 19 | }))) 20 | 21 | ;; Refresh the metadata for a FT from a specific contract 22 | (define-public (ft-metadata-update-notify (contract )) 23 | (ok (print 24 | { 25 | notification: "token-metadata-update", 26 | payload: { 27 | contract-id: contract, 28 | token-class: "ft" 29 | } 30 | }))) 31 | -------------------------------------------------------------------------------- /sips/sip-012/scripts/generate-artifacts.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # NOTE: not tested. Reconstructed from bash history. 4 | 5 | LOGFILE="$1" 6 | if [ -z "$LOGFILE" ]; then 7 | echo >&2 "Usage: $0 NODE-LOGFILE.out" 8 | exit 1 9 | fi 10 | 11 | # get PoX lockup and delegate-stack-stx events 12 | grep -F '[chains-coordinator] PoX lock ' "$LOGFILE" > ./pox-lock.out 13 | grep -F 'Handle special-case contract-call' "$LOGFILE" | grep 'delegate-stack-stx' > ./delegate-pox-lock.out 14 | 15 | # extract log entries to JSON stacker records 16 | ./extract-stackers.sh 19 < ./pox-lock.out > stackers-19-raw.json 17 | ./extract-stackers.sh 20 < ./pox-lock.out > stackers-20.json 18 | 19 | # consider stackers that only stacked in 19, not 20 20 | echo -n "" > stackers-19.json 21 | while read -r json; do 22 | addr="$(echo "$json" | jq -r -c '.address')" 23 | if ! grep -F "$addr" stackers-20.json >/dev/null; then 24 | echo "$json" >> stackers-19.json 25 | fi 26 | done < ./stackers-19-raw.json 27 | 28 | # extract log entries to JSON delegate records 29 | ./extract-delegates.sh < ./delegate-pox-lock.out | sort | uniq > delegating.json 30 | -------------------------------------------------------------------------------- /considerations/minutes/economic-cab/2025-06-18-sip-031.md: -------------------------------------------------------------------------------- 1 | # Economics CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Telegram (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - June 18th, 2025 12 | 13 | **Time:** n/a 14 | 15 | **Attendees:** 16 | 17 | - Hadan Esperidiao 18 | - Leeor Shimron 19 | - Xan Ditkoff 20 | - Pieter Aerts 21 | - mattyTokenomics (MattySTX) 22 | 23 | **Topic(s):** 24 | 25 | - [SIP-031: Five-Year Stacks Growth Emissions](https://github.com/stacksgov/sips/pulls) 26 | 27 | ## Meeting Notes 28 | 29 | The Economics CAB reviewed and voted on SIP-031. 30 | 31 | CAB voted on three options presented by the Chairperson MattySTX: 32 | 33 | 1. Approve with no prerequisites 34 | 35 | 2. Conditionally approve (approve pending certain prerequisites being met - please specify) 36 | 37 | 3. Reject (please explain why) 38 | 39 | ## Vote Outcome(s) 40 | 41 | | Name | Vote | 42 | | --------------- | ------- | 43 | | Hadan Esperidiao| yes (1) | 44 | | Leeor Shimron | yes (1) | 45 | | Xan Ditkoff | yes (1) | 46 | | Pieter Aerts | yes (1) | 47 | | mattyTokenomics | yes (1) | 48 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2024-06-25-sip-WSTS.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - Jun 25, 2024 12 | 13 | **Time:** 14 | 15 | **Attendees:** 16 | 17 | - Brice Dobry 18 | - Aaron Blankstein 19 | - Dan Trevino 20 | - Friedger 21 | - Jesse Wiley 22 | - Jesus Najera 23 | - Mike Cohen (chairperson) 24 | - Vlad 25 | - 0xdima 26 | 27 | **Topic(s):** 28 | 29 | - Vote on SIP-025: Iterating towards WSTS 30 | 31 | **Materials**: 32 | 33 | - [SIP-025: Iterating towards WSTS](https://github.com/stacksgov/sips/pull/183) 34 | 35 | ## 2024-01-31 Meeting Notes 36 | 37 | - 38 | 39 | ### Vote Outcome 40 | 41 | Quorum is reached with 9 of 9 eligible CAB members voting on the SIP. 42 | 43 | | Name | Vote | 44 | | ------------ | ------- | 45 | | Brice Dobry | yes | 46 | | Dan Trevino | yes | 47 | | Friedger | abstain | 48 | | Jesus Najera | yes | 49 | | Mike Cohen | abstain | 50 | | Vlad | yes | 51 | | 0xdima | yes | 52 | | Jesus Najera | yes | 53 | | Jesse Wiley | yes | 54 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2023-05-17-sip-024.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - May 17, 2023 12 | 13 | **Time:** n/a 14 | 15 | **Attendees:** 16 | 17 | - Brice Dobry (chairperson) 18 | - Dan Trevino 19 | - Jamil Dhanani 20 | - Jesse Wiley 21 | - Mike Cohen 22 | 23 | **Topic(s):** 24 | 25 | - [SIP-024: Emergency Fix to Data Validation and Serialization Behavior](https://github.com/stacksgov/sips/pull/141) 26 | 27 | **Materials**: 28 | 29 | - [SIP - Catastrophic blockchain failures and recovery](https://github.com/stacksgov/sips/pull/10) 30 | 31 | ## 2023-05-17 Meeting Notes 32 | 33 | There was very little discussion required for this SIP. Five CAB members voted 34 | unanimously to approve SIP-024, 0 rejected, and 0 abstained. 35 | 36 | ## Vote Outcome(s) 37 | 38 | | Name | Vote | 39 | | ------------- | ---- | 40 | | Dan Trevino | 👍 | 41 | | Brice Dobry | 👍 | 42 | | Mike Cohen | 👍 | 43 | | Jamil Dhanani | 👍 | 44 | | Jesse Wiley | 👍 | 45 | 46 | The Technical CAB approves SIP-024 with 5 yes votes. 47 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2024-02-02-sip-021.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - January 18, 2024 12 | - February 1st, 2024 13 | - February 2nd, 2024 14 | 15 | **Time:** n/a 16 | 17 | **Attendees:** 18 | 19 | - Jason Schrader 20 | - Harold Davis 21 | - Zero.btc 22 | - Orlando Cosme 23 | - Juliet Oberding 24 | 25 | **Topic(s):** 26 | 27 | - [SIP-021: Fast and Reliable Blocks through PoX-assisted Block Propagation](https://github.com/stacksgov/sips/pull/155) 28 | 29 | **Materials**: 30 | 31 | - [Direct link to SIP text](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) 32 | 33 | ## Meeting Notes 34 | 35 | The governance CAB reviewed and discussed SIP-021 and the supporting materials, and approves SIP-021. 36 | 37 | ## Vote Outcome(s) 38 | 39 | Quorum is reached with 4 of 5 eligible CAB members voting on the SIP. 40 | 41 | | Name | Vote | 42 | | --------------- | ------- | 43 | | Jason Schrader | yes | 44 | | Harold Davis | yes | 45 | | Zero Authority | yes | 46 | | Orlando Cosme | abstain | 47 | | Juliet Oberding | yes | 48 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2023-05-01-sip-023.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - May 1, 2023 12 | 13 | **Time:** n/a 14 | 15 | **Attendees:** 16 | 17 | - Jason Schrader 18 | - Harold Davis 19 | - Zero.btc 20 | - Orlando Cosme 21 | - Juliet Oberding 22 | 23 | **Topic(s):** 24 | 25 | - [SIP-023: Emergency Fix to Trait Invocation Behavior](https://github.com/stacksgov/sips/pull/131) 26 | 27 | **Materials**: 28 | 29 | - [SIP - Catastrophic blockchain failures and recovery](https://github.com/stacksgov/sips/pull/10) 30 | - [Stacks Forum: Issue passing trait arguments in epoch 2.2](https://forum.stacks.org/t/issue-passing-trait-arguments-in-epoch-2-2/14938) 31 | 32 | ## 2023-05-01 Meeting Notes 33 | 34 | The governance CAB discussed SIP-023 and the supporting materials, and concluded that this hard fork is necessary to support the ecosystem. 35 | 36 | ## Vote Outcome(s) 37 | 38 | | Name | Vote 5/1 | 39 | | --------------- | -------- | 40 | | Jason Schrader | yes | 41 | | Harold Davis | yes | 42 | | Zero Authority | yes | 43 | | Orlando Cosme | yes | 44 | | Juliet Oberding | yes | 45 | 46 | The Governance CAB unanimously approves SIP-023 with 5 yes votes. 47 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2023-05-01-sip-023.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - May 1, 2023 12 | 13 | **Time:** n/a 14 | 15 | **Attendees:** 16 | 17 | - Brice Dobry (abstain) 18 | - Dan Trevino 19 | - Daniel Fritsche (abstain) 20 | - Jamil Dhanani 21 | - Jesse Wiley 22 | - Mike Cohen (abstain) 23 | - Terje Norderhaug 24 | - Thomas Osmonson 25 | 26 | **Topic(s):** 27 | 28 | - [SIP-023: Emergency Fix to Trait Invocation Behavior](https://github.com/stacksgov/sips/pull/131) 29 | 30 | **Materials**: 31 | 32 | - [SIP - Catastrophic blockchain failures and recovery](https://github.com/stacksgov/sips/pull/10) 33 | - [Stacks Forum: Issue passing trait arguments in epoch 2.2](https://forum.stacks.org/t/issue-passing-trait-arguments-in-epoch-2-2/14938) 34 | 35 | ## 2023-05-01 Meeting Notes 36 | 37 | The Technical CAB discussed SIP-023 and the supporting materials, and concluded that this hard fork is necessary to support the ecosystem. 38 | 39 | ## Vote Outcome(s) 40 | 41 | | Name | Vote | 42 | | --------------- | ---- | 43 | | Jamil Dhanani | 👍 | 44 | | Dan Trevino | 👍 | 45 | | Jesse Wiley | 👍 | 46 | | Thomas Osmonson | 👍 | 47 | 48 | The Technical CAB approves SIP-023 with 4 yes votes, where 3 members abstained. 49 | 50 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2025-10-17-sip-034.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - Oct 17th, 2025 12 | 13 | **Time:** n/a 14 | 15 | **Attendees:** 16 | 17 | - Aaron Blankstein 18 | - Brice Dobry 19 | - j2p2 20 | - Friedger 21 | - Radu 22 | - Setzeus 23 | 24 | **Topic(s):** 25 | 26 | - [SIP-034: Dimension-Specific Tenure Extend Variants](https://github.com/stacksgov/sips/pull/236) 27 | 28 | **Materials**: 29 | 30 | - [SIP-034: Dimension-Specific Tenure Extend Variants](https://github.com/stacksgov/sips/pull/236) 31 | - [Reference implementation](https://github.com/stacks-network/stacks-core/pull/6609) 32 | 33 | ## 2025-10-15 Meeting Notes 34 | 35 | Note: This vote was urgently needed to ensure it can proceed together with 36 | SIP-033. The current chair, Jesse Wiley, is unavailable for this vote, so Brice 37 | Dobry is acting chair for this vote. 38 | 39 | The Technical CAB reviewed SIP-034 and the supporting materials, and concluded 40 | that this change is necessary to support the ecosystem. 41 | 42 | ## Vote Outcome(s) 43 | 44 | | Name | Vote | 45 | | ---------------- | ------- | 46 | | Aaron Blankstein | abstain | 47 | | Brice Dobry | yes | 48 | | Friedger | yes | 49 | | j2p2 | yes | 50 | | Setzeus | yes | 51 | | Radu | yes | 52 | 53 | _Note_ Aaron Blankstein is the author of SIP-034, as such he abstained from 54 | voting. 55 | 56 | The Technical CAB approves SIP-034 with 5 yes votes and 1 abstention by the 57 | author. 58 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2021-11-05-sip-012.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Online 6 | 7 | **Recorded:** No 8 | 9 | **Date:** November 5, 2021 10 | 11 | **Time:** 4:00pm - 5:00pm UTC 12 | 13 | **Attendees:** 14 | 15 | - Jason Schrader 16 | - Harold Davis 17 | - Juliet Oberding 18 | 19 | **Topic(s):** 20 | 21 | - [SIP-012: Burn Height Selection for a Network Upgrade to Introduce New Cost-Limits](https://github.com/stacksgov/sips/pull/41) 22 | 23 | **Materials:** None 24 | 25 | ## Meeting Notes 26 | 27 | In review of SIP-012, the governance CAB would like to acknowledge that: 28 | 29 | - we agree the method used for SIP-012 to bypass SIP-006 with a new voting procedure is sufficient for this SIP, and that it should not supersede SIP-006 or set a precedent for a new voting procedure without a separate SIP. 30 | - we agree that while the voting procedure will likely include parties that represent large stakeholder groups, e.g. stacking pools or exchanges, the rationale for the voting procedure and requirement for a supermajority of "yes" votes to activate sufficiently represents the majority of stakeholder groups. 31 | - we recognize that, at the time of writing, the vote for SIP-012 includes 23 votes in support representing 62,556,630 STX, with 0 votes against according to the [voting website](https://sip012.xyz/). 32 | - we agree that reducing congestion positively impacts everyone that's involved in the network: community members, STX holders/investors, builders, and miners, providing room for future network growth. 33 | 34 | The governance CAB unanimously approves SIP-012. 35 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2023-05-17-sip-024.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - May 15, 2023 12 | - May 16, 2023 13 | - May 17, 2023 14 | 15 | **Time:** n/a 16 | 17 | **Attendees:** 18 | 19 | - Jason Schrader 20 | - Harold Davis 21 | - Zero.btc 22 | - Orlando Cosme 23 | - Juliet Oberding 24 | 25 | **Topic(s):** 26 | 27 | - [SIP-024: Emergency Fix to Data Validation and Serialization Behavior](https://github.com/stacksgov/sips/pull/141) 28 | 29 | **Materials**: 30 | 31 | - [SIP - Catastrophic blockchain failures and recovery](https://github.com/stacksgov/sips/pull/10) 32 | 33 | ## 2023-05-16 Meeting Notes 34 | 35 | The governance CAB reviewed and discussed SIP-024 and the supporting materials, and concluded that this SIP should be included in the upcoming hard fork. 36 | 37 | The SIP addresses an issue already resolved by a patch that invalidates transactions, and fixing the issue in the hard fork will benefit both miners and network participants as defined in the SIP. 38 | 39 | In addition, delaying this fix until the next hard fork could be detrimental to the network and its participants should the bug be exploited further. 40 | 41 | ## Vote Outcome(s) 42 | 43 | | Name | Vote 5/16 and 5/17 | 44 | | --------------- | ------------------ | 45 | | Jason Schrader | yes | 46 | | Harold Davis | yes | 47 | | Zero Authority | yes | 48 | | Orlando Cosme | yes | 49 | | Juliet Oberding | yes | 50 | 51 | The Governance CAB unanimously approves SIP-024 with 5 yes votes. 52 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2022-11-17-sip-015.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** November 15, 2022 - November 17, 2022 10 | 11 | **Time:** n/a 12 | 13 | **Attendees:** 14 | 15 | - Jason Schrader 16 | - Harold Davis 17 | - Zero.btc 18 | - Orlando Cosme 19 | - Juliet Oberding 20 | 21 | **Topics:** 22 | 23 | - [SIP-020: Bitwise Operations in Clarity](https://github.com/stacksgov/sips/pull/106) 24 | 25 | **Materials**: None 26 | 27 | ## Meeting Notes 28 | 29 | - text outlining SIP-020, it's origin, and implementation were added to the group chat 30 | - a list of questions were provided based on what's in-scope for this CAB: 31 | - do we accept this additional feature alongside the new functions introduced in Clarity 2, from the perspective all would rely on the SIP-015 vote passing? 32 | - do we approve even though this was added after voting started for SIP-015? 33 | - do we think approving this would set the wrong precedent for including last minute changes? (they do happen, after all!) 34 | - do we think the community needs this badly enough to warrant the "rider" SIP? 35 | - the general consensus was that adding SIP-020 would be non-controversial, and provide features that are useful and helpful 36 | 37 | ## Vote Outcome(s) 38 | 39 | - Jason Schrader: yes, _see note_ 40 | - Harold Davis: yes 41 | - Zero Authority: yes 42 | - Orlando Cosme: yes 43 | - Juliet Oberding: yes 44 | 45 | _note:_ the Governance CAB would like to request that future additions dependent on another SIP's activation are included before any voting is performed. 46 | 47 | The Governance CAB unanimously approves SIP-020. 48 | -------------------------------------------------------------------------------- /considerations/minutes/economic-cab/2024-02-01-sip-021.md: -------------------------------------------------------------------------------- 1 | # Economics CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Telegram (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - January 20, 2024 12 | - February 1st, 2024 13 | 14 | **Time:** n/a 15 | 16 | **Attendees:** 17 | 18 | - Chiente Hsu 19 | - Xan Ditkoff 20 | - Pieter Aerts 21 | - mattyTokenomics (MattySTX) 22 | 23 | **Topic(s):** 24 | 25 | - [SIP-021: Fast and Reliable Blocks through PoX-assisted Block Propagation](https://github.com/stacksgov/sips/pull/155) 26 | 27 | **Materials**: 28 | 29 | - [Direct link to SIP text](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) 30 | 31 | ## Meeting Notes 32 | 33 | The Economics CAB reviewed and discussed SIP-021 and the supporting materials, including concerns around MEV and reorg attacks on Stacks and Bitcoin itself which are incentivized due to the SIP's lack of an enshrined transaction replay mechanism which would help to ensure that in the event of a BTC fork STX txs would be re-mined in their original mined order. 34 | 35 | As a result of these concerns, the CAB voted on three options: 36 | 37 | A. Deny SIP in current form (no vote) 38 | B. Approve SIP with the caveat that the Economics CAB will vote 'no' on any and all future SIPs until a sufficient transaction replay mechanism is enshrined - the sole exception being SIPs which address critical bugs impacting chain liveness or security (yes vote) 39 | C. Approve SIP outright (yes vote) 40 | 41 | ## Vote Outcome(s) 42 | 43 | | Name | Vote | 44 | | --------------- | ------- | 45 | | Chiente Hsu | yes (C) | 46 | | Xan Ditkoff | yes (B) | 47 | | Pieter Aerts | yes (B) | 48 | | mattyTokenomics | yes (B) | 49 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2024-01-31-sip-021.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - January 31, 2024 12 | 13 | **Time:** 2024/01/31, 13:00 - 2024/02/01, 1:00 UTC 14 | 15 | **Attendees:** 16 | 17 | - Brice Dobry (chairperson) 18 | - Aaron Blankstein 19 | - Dan Trevino 20 | - Friedger 21 | - Jesse Wiley 22 | - Jesus Najera 23 | - Mike Cohen 24 | - Vlad 25 | - 0xdima 26 | 27 | **Topic(s):** 28 | 29 | - Vote on the Nakamoto SIP 30 | 31 | **Materials**: 32 | 33 | - [PR #155: Nakamoto v1](https://github.com/stacksgov/sips/pull/155) 34 | 35 | ## 2024-01-31 Meeting Notes 36 | 37 | It was decided in advance that Aaron, Jesse, and Brice would recuse themselves 38 | from the vote, as they were heavily involved in the writing of the SIP. 39 | 40 | Friedger brought up multiple discussion points during the voting period. 41 | Concerns about changes to the pox-4 implementation that were not correctly 42 | matching the SIP were discussed. These concerns were addressed with PR #169, 43 | authored by Jesus Najera, commited by Brice Dobry, and approved by Friedger. 44 | Friedger mentioned wanting to understand how a chain split would work, but it 45 | was decided that this was out of scope for the SIP. It was also mentioned that 46 | the change from pox-4 to pox-5 can happen during a tenure of the current miner, 47 | so that is not a problem. The emergency strategy if PoX does not activate was 48 | discussed, and it was decided that an emergency SIP would be needed in that 49 | case. 50 | 51 | ### Vote Outcome 52 | 53 | Quorum is reached with 5 of 6 eligible CAB members voting on the SIP. 54 | 55 | | Name | Vote | 56 | | ------------ | ------- | 57 | | Dan Trevino | yes | 58 | | Friedger | abstain | 59 | | Jesus Najera | yes | 60 | | Mike Cohen | yes | 61 | | Vlad | yes | 62 | | 0xdima | yes | 63 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2025-10-17-sip-034.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - October 15, 2025 12 | - October 16, 2025 13 | - October 17, 2025 14 | 15 | **Attendees:** 16 | 17 | - Juliet Oberding 18 | - Harold Davis 19 | - Stephen Perrino 20 | - Zero.btc 21 | - Jason Schrader 22 | 23 | **Topic(s):** 24 | 25 | - [SIP-034: Dimension-Specific Tenure Extend Variants](https://github.com/stacksgov/sips/pull/236) 26 | 27 | **Materials**: 28 | 29 | - [SIP-020: Bitwise Operations in Clarity](https://github.com/stacksgov/sips/blob/main/sips/sip-020/sip-020-bitwise-ops.md#activation) 30 | - [Governance CAB Minutes for SIP-020](https://github.com/stacksgov/sips/blob/main/considerations/minutes/governance-cab/2022-11-17-sip-015.md) 31 | 32 | ## Meeting Notes 33 | 34 | The governance CAB was requested to review SIP-034 as a rider to SIP-033. Items discussed: 35 | 36 | - SIP-034 is summarized as an "under-the-hood" performance improvement that helps with a major use case behind SIP-033 37 | - last time a rider was introduced was SIP-020 Bitwise Ops on SIP-015 Stacks 2.1 38 | - following SIP-020 approval the Governance CAB requested any riders be known before the vote 39 | - we agree sufficient notice was given for this rider and that it follows the same activation pattern 40 | - we still recommend the technical CAB makes an updated review and activation is contingent upon their approval 41 | 42 | ## Vote Outcome(s) 43 | 44 | Quorum is reached with 5 of 6 eligible CAB members voting on the SIP. 45 | 46 | | Name | Vote | 47 | | --------------- | ------- | 48 | | Jason Schrader | yes | 49 | | Juliet Oberding | yes | 50 | | Harold Davis | yes | 51 | | Zero Authority | yes | 52 | | Stephen Perrino | yes | 53 | | Orlando Cosme | abstain | 54 | 55 | The governance CAB would like to note that we received no response from Orlando Cosme. -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2025-06-23-sip-031.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - June 18, 2025 12 | - June 23, 2025 13 | - June 24, 2025 14 | 15 | **Attendees:** 16 | 17 | - Juliet Oberding 18 | - Harold Davis 19 | - Stephen Perrino 20 | - Zero.btc 21 | - Jason Schrader 22 | 23 | **Materials:** 24 | 25 | - [SIP-031 Pull Request](https://github.com/stacksgov/sips/pull/214) and [Related Text](https://github.com/stacksgov/sips/blob/cuevasm-patch-1/sips/sip-031/sip-031.md) 26 | - [SIP-031 Sessions: Appointment Committee](https://forum.stacks.org/t/session-1-prep-material-sip-031-appointments-committee/18141) 27 | - [SIP-031: Introducing the Appointments Committee](https://stacks.org/sip31-appointments-committee) 28 | - [SIP-031 Community Vote Window and Instructions](https://stacks.org/sip31-voting-timeline) 29 | 30 | ## 2025-06-18 Meeting Notes 31 | 32 | Several resources were shared within our group and members attended community discussions hosted by the SIP authors and other ecosystem entities to mark the open questions above as resolved. 33 | 34 | ## 2025-06-23 Meeting Notes 35 | 36 | The governance CAB held a a check-in on votes from the participating members. 37 | 38 | Jason Schrader announced his selection for the Appointments Committee and offered to abstain. 39 | 40 | The other governance CAB members expressed this is not a conflict of interest and Jason should vote. 41 | 42 | ## 2025-06-24 Meeting Notes 43 | 44 | Final votes are gathered and finalized. 45 | 46 | ## Vote Outcome(s) 47 | 48 | Quorum is reached with 5 of 6 eligible CAB members voting on the SIP. 49 | 50 | | Name | Vote | 51 | | --------------- | ------- | 52 | | Jason Schrader | yes | 53 | | Juliet Oberding | yes | 54 | | Harold Davis | yes | 55 | | Zero Authority | yes | 56 | | Stephen Perrino | yes | 57 | | Orlando Cosme | abstain | 58 | 59 | The governance CAB would like to note that we were unable to reach Orlando Cosme throughout the SIP-031 review and voting process. 60 | -------------------------------------------------------------------------------- /considerations/TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # Consideration Advisory Board Template 2 | 3 | The template below serves as a starting point for creating a new CAB or updating existing details. 4 | 5 | **Inactive CAB** 6 | 7 | If a CAB is not active yet, it will have only two sections: 8 | 9 | - the main section describing the members 10 | - an about section explaining the placeholder status 11 | - example: [Diversity CAB](diversity.md) 12 | 13 | **Active CAB** 14 | 15 | If a CAB is active, it starts with the member information section, directly below the CAB title. 16 | 17 | --- 18 | 19 | Chairperson: Name 20 | 21 | Members: 22 | 23 | - Name 1 24 | - Name 2 25 | - Name 3 26 | 27 | Discussions-to: https://github.com/stacksgov/sips 28 | 29 | Created-by: SIP-000 30 | 31 | ## Biographies 32 | 33 | Short descriptions of each member's background and experience. 34 | 35 | --- 36 | 37 | **Name 1**: Details 38 | 39 | **Name 2**: Details 40 | 41 | **Name 3**: Details 42 | 43 | ## About this CAB 44 | 45 | A description of the general considerations of the CAB, generally in one paragraph. 46 | 47 | ## Considerations 48 | 49 | ### In-scope 50 | 51 | The following items would be considered in-scope for this CAB: 52 | 53 | 1. First item 54 | 2. Second item 55 | 3. Third item 56 | 57 | ### Out-of-scope 58 | 59 | The following items would be considered out-of-scope for this CAB: 60 | 61 | 1. First item 62 | 2. Second item 63 | 3. Third item 64 | 65 | ### Questions for SIP Review 66 | 67 | 1. Question/Prompt 1 68 | 2. Question/Prompt 2 69 | 3. Question/Prompt 3 70 | 71 | ## Bylaws 72 | 73 | We choose to adopt the bylaws Steering Committee member @jcnelson set out in this doc: https://gist.github.com/jcnelson/3fcc635ede20ce98d1eae60941eb127a 74 | 75 | Starting from those bylaws, this CAB will continue to evaluate what works, what doesn't work, and use the feedback and lessons learned to improve the process and increase involvement along the way. 76 | 77 | --- 78 | 79 | _If this CAB interests you and you wish to join the effort, please reach out to @jennymith and @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 80 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2025-06-09-sip-031.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Zoom 6 | 7 | **Recorded:** No 8 | 9 | **Date:** June 9, 2025 10 | 11 | **Time:** 3:30pm PST 12 | 13 | **Attendees:** 14 | 15 | - Juliet Oberding 16 | - Harold Davis 17 | - Stephen Perrino 18 | - Jason Schrader 19 | 20 | **Topic(s):** 21 | 22 | - Initial discussion and review of [SIP-031: Fueling Stacks Builders & Growth](https://forum.stacks.org/t/draft-fueling-stacks-builders-growth-meet-sip-031/18060) 23 | 24 | **Materials:** 25 | 26 | - [original SIP-031 forum post](https://forum.stacks.org/t/draft-fueling-stacks-builders-growth-meet-sip-031/18060) 27 | - [SIP-031 new draft update](https://forum.stacks.org/t/sip-31-1-a-new-draft-arrives/18130) 28 | - [SIP-031 Sessions: Appointment Committee](https://forum.stacks.org/t/session-1-prep-material-sip-031-appointments-committee/18141) 29 | - [Latest living doc of SIP-031 draft](https://docs.google.com/document/d/1u8CM14p_tbNO4vh1Ih5ZDl57ZYJnIHTvUTKS0_rorFc/edit?pli=1&tab=t.0#heading=h.6yrfqheg92a5) 30 | 31 | ## 2025-06-09 Meeting Notes 32 | 33 | The Governance CAB met to review SIP-031. The group supports the proposal's goal of accelerating ecosystem growth and focused on key areas where more detail would strengthen community support. 34 | 35 | Key points discussed: 36 | 37 | - The proposed Treasury and Appointments Committees are seen as a positive step. 38 | - More clarity is needed on operational details for these new committees, including selection and voting processes. 39 | - The group agrees that strong, ongoing community oversight will be important for the new entities. 40 | - Ensuring meaningful community representation on the new committees is considered essential. 41 | - The CAB appreciates that the Endowment will not vote its STX and discussed how to best align the treasury's influence with community priorities. 42 | 43 | The CAB has the following questions for the SIP authors to help clarify the proposal for the community: 44 | 45 | - What are the Treasury Committee's internal decision-making and voting rules? 46 | - What are the plans for ongoing community engagement and feedback after the SIP passes? 47 | - Can the roles of 'keyholder' versus 'rotating' members be further defined? 48 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2023-10-27-pr-152-153.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - October 27, 2023 12 | 13 | **Time:** 8:00am - 3:30pm EDT 14 | 15 | **Attendees:** 16 | 17 | - Brice Dobry (chairperson) 18 | - Aaron Blankstein 19 | - Dan Trevino 20 | - Jesse Wiley 21 | - Jesus Najera 22 | - Mike Cohen 23 | 24 | **Topic(s):** 25 | 26 | - Proposal: Non-Sequential Multisig 27 | - Proposal: Clarity DeFi Vault 28 | 29 | **Materials**: 30 | 31 | - [PR #152: Non-Sequential Multisig](https://github.com/stacksgov/sips/pull/152) 32 | - [PR #153: Clarity DeFi Vault](https://github.com/stacksgov/sips/pull/153) 33 | 34 | ## 2023-10-27 Meeting Notes 35 | 36 | Quorum is reached with 6 of 9 members participating in the discussion. 37 | 38 | ### PR #152 39 | 40 | Several CAB members made minor comments on the PR, fixing grammatical errors and typos. No major concerns were identified, other than the missing activation, which has been added. After the vote, the author corrected the minor items pointed out by this CAB and added the "Additional Recommendations" section, which he felt was useful for clarification. The CAB did not object to this addition. 41 | 42 | #### Vote Outcome(s) 43 | 44 | | Name | Vote | 45 | | ---------------- | ---- | 46 | | Aaron Blankstein | 👍 | 47 | | Brice Dobry | 👍 | 48 | | Dan Trevino | 👍 | 49 | | Jesse Wiley | 👍 | 50 | | Jesus Najera | 👍 | 51 | | Mike Cohen | 👍 | 52 | 53 | The Technical CAB approves PR #152 with 6 yes votes. 54 | 55 | ### PR #153 56 | 57 | Aaron started the discussion on this PR, pointing out several technical errors, missing information, or unclear wording in the text. The rest of the CAB agreed with this assessment and feels that these are fixable errors, so we would like to revisit this vote after these items are addressed. 58 | 59 | #### Vote Outcome(s) 60 | 61 | | Name | Vote | 62 | | ---------------- | ---- | 63 | | Aaron Blankstein | ♻️ | 64 | | Brice Dobry | ♻️ | 65 | | Dan Trevino | ♻️ | 66 | | Jesse Wiley | ♻️ | 67 | | Jesus Najera | ♻️ | 68 | | Mike Cohen | ♻️ | 69 | 70 | The Technical CAB votes to revisit PR #153 after the items pointed out in the PR have been addressed. 71 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2025-03-05-sip-030.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - March 5, 2025 12 | 13 | **Time:** 2025/03/05, 14:00 - 2025/03/05, 23:00 UTC 14 | 15 | **Attendees:** 16 | - j2p2 (chairperson) 17 | - Aaron Blankstein 18 | - Ashton Stephens 19 | - Brice Dobry 20 | - Friedger 21 | - Jesse Wiley 22 | - Mike Cohen 23 | - Setzeus 24 | - Vlad 25 | - 0xdima 26 | 27 | **Topic(s):** 28 | 29 | - Vote on SIP-030 30 | 31 | **Materials**: 32 | 33 | - [SIP-030: Wallet RPC Standards](https://github.com/stacksgov/sips/pull/166) 34 | 35 | ## 2025-03-05 Meeting Notes 36 | 37 | The technical CAB discussed SIP-030 and its implications for the Stacks ecosystem. The SIP proposes standardized RPC interfaces for wallet applications to improve interoperability between wallets and dApps in the Stacks ecosystem. 38 | 39 | Several CAB members raised questions about implementation details and security considerations. Aaron and Jesse provided clarification on authentication mechanisms and how the proposed standards would enhance user experience while maintaining security. 40 | 41 | Friedger expressed concerns about the increased complexity for wallet developers but acknowledged the benefits of standardization. These concerns were addressed by pointing to the reference implementations and developer tooling that would be provided alongside the SIP. 42 | 43 | The CAB members agreed that standardized wallet RPC interfaces would benefit the ecosystem by enabling more consistent user experiences across different wallets and dApps, reducing fragmentation, and lowering the barrier to entry for new wallet developers. 44 | 45 | ## Vote Outcome 46 | 47 | Quorum is reached with 10 of 10 eligible CAB members voting on the SIP. Vote options were ✅ (yes), 🚫 (no), or 🤷 (no preference). 48 | 49 | | Name | Vote | 50 | | ---------------- | ---- | 51 | | Aaron Blankstein | ✅ | 52 | | Ashton Stephens | ✅ | 53 | | Brice Dobry | ✅ | 54 | | Friedger | ✅ | 55 | | j2p2 | ✅ | 56 | | Jesse Wiley | ✅ | 57 | | Mike Cohen | 🤷 | 58 | | Setzeus | 🤷 | 59 | | Vlad | ✅ | 60 | | 0xdima | ✅ | 61 | 62 | The Technical CAB approves SIP-030 with 8 yes votes and 2 no preference votes. 63 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2022-10-31-sip-015.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Zoom 6 | 7 | **Recorded:** Yes (Link TBD) 8 | 9 | **Date:** October 31, 2022 10 | 11 | **Time:** 15:00 - 16:00 UTC 12 | 13 | **Attendees:** 14 | 15 | - Jason Schrader 16 | - Harold Davis 17 | - Zero.btc 18 | - Orlando Cosme 19 | 20 | **Topics:** 21 | 22 | - [SIP-015: Stacks Upgrade of Proof-of-Transfer and Clarity](https://github.com/stacksgov/sips/pull/95) 23 | 24 | **Materials**: None 25 | 26 | ## Meeting Notes 27 | 28 | - quick intros for the attendees 29 | - reviewed SIP-012 CAB minutes as an example 30 | - reviewed governance CAB charter and requirements 31 | - reviewed SIP-015 full text, in backwards order 32 | - Activation: overall in agreement with all three voting methods 33 | - more accessible than SIP-012 voting method 34 | - adequately represents stakeholders with fair thresholds 35 | - Block Validation: overall in agreement with proposed additions/changes 36 | - no disagreement over paying tx fee before processing 37 | - no disagreement over alternative coinbase recipients, and reviewed how this could enable decentralized mining pools via payouts to smart contracts 38 | - no disagreement over smart contract versioning 39 | - Clarity: given the technical nature of this section, it was agreed upon by the CAB that the fixes and new features are designed to benefit various stakeholders including but not limited to developers, partnerships, and end users 40 | - Stacking: overall in agreement with proposed additions/changes 41 | - we want to ensure that stacking pools are adequately represented in this process, and able to communicate the upcoming changes very clearly to users 42 | - we want to ensure that exchanges are properly addressed in the voting process, and agree with the limit set forth in Method 3 using the reward cycle minimum 43 | 44 | ## Action Items 45 | 46 | - [ ] reach out to pool operators and confirm sentiment 47 | - [ ] can Stackers utilizing an Exchange product, e.g. Okcoin Earn, participate in the vote? 48 | - [ ] can Exchanges vote as a solo stacker given they stack on behalf of their participants? 49 | 50 | ## Vote Outcome(s) 51 | 52 | - Jason Schrader: yes 53 | - Harold Davis: yes 54 | - Zero Authority: yes 55 | - Orlando Cosme: yes 56 | - Juliet Oberding: yes 57 | 58 | Juliet Oberding was not able to attend the meeting, but reviewed the content asynchronously and provided her vote through our Discord group. 59 | 60 | The Governance CAB unanimously approves SIP-015. 61 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2024-10-21-sip-028.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Zoom 6 | 7 | **Recorded:** No 8 | 9 | **Date:** October 21, 2024 10 | 11 | **Time:** 9:00am PST 12 | 13 | **Attendees:** 14 | 15 | - Juliet Oberding 16 | - Harold Davis 17 | - Jason Schrader 18 | 19 | **Topic(s):** 20 | 21 | - [SIP-028: Signer Criteria for sBTC, A Decentralized and Programmable Asset Backed 1:1 with BTC](https://github.com/stacksgov/sips/pull/186) 22 | 23 | **Materials:** 24 | 25 | - [Direct link to SIP text](https://github.com/andrerserrano/sips/blob/main/sips/sip-028/sip-028-sbtc_peg.md) 26 | - [Selection of sBTC signer set](https://github.com/stacks-network/sbtc/discussions/624) 27 | 28 | ## 2024-10-21 Meeting Notes 29 | 30 | The governance CAB reviewed and discussed SIP-028, focusing on the eligibility and selection process for sBTC signers, based on the [established criteria](https://github.com/stacksgov/sips/blob/main/considerations/governance.md) set for our CAB. Key points discussed: 31 | 32 | - sBTC signers represent a new type of stakeholder in the Stacks ecosystem. 33 | - sBTC signer selection is open and transparent, outlined both in the SIP and supporting GitHub discussion on how the current signer set was selected, who is involved, and why they were selected. 34 | - SIP-028 builds on the work completed in SIP-021, addressing the transition between Epoch 2.5 and Epoch 3.0 where sBTC signers will be responsible for block production on the Stacks blockchain. 35 | - Additional SIPs will be proposed following this one which further outline the implementation for sBTC. 36 | 37 | Before completing a vote on SIP-028, the governance CAB would like to clarify the following open questions: 38 | 39 | - SIP-021 mentioned transaction replay on Stacks forks would be handled after the SIP was ratified. Does the implementation of SIP-028 and sBTC signers affect this process at all? 40 | - SIP-028 mentions "sBTC can be activated on the Stacks network without requiring a separate hard fork." Who will be required to review subsequent SIPs as the sBTC implementation evolves? 41 | - What is the process for updating the sBTC signer set following this SIP? 42 | - What protection mechanisms are implemented should the 70% quorum of sBTC signers not arrive at consensus? 43 | 44 | ## Vote Outcome(s) 45 | 46 | Quorum is reached with 4 of 5 eligible CAB members voting on the SIP. 47 | 48 | | Name | Vote | 49 | | --------------- | ------- | 50 | | Jason Schrader | pending | 51 | | Harold Davis | pending | 52 | | Zero Authority | pending | 53 | | Orlando Cosme | pending | 54 | | Juliet Oberding | pending | 55 | -------------------------------------------------------------------------------- /sips/sip-012/scripts/extract-delegates.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | ############################################################ 4 | # Script to extract all STX addresses that are delegating. 5 | # 6 | # Usage: ./extract-delegates.sh REWARD-CYCLE < DEBUG-LOG-FILE 7 | ############################################################ 8 | 9 | set -oue pipefail 10 | 11 | FIRST_BLOCK=666050 12 | REWARD_CYCLE_LENGTH=2100 13 | 14 | # DEBG [1635816373.424732] [src/vm/functions/special.rs:81] [chains-coordinator] Handle special-case contract-call to QualifiedContractIdentifier { issuer: StandardPrincipalData(SP000000000000000000002Q6VF78), name: ContractName("pox") } delegate-stack-stx (which returned Response(ResponseData { committed: false, data: Int(3) })) 15 | # DEBG [1635816373.394132] [src/vm/functions/special.rs:81] [chains-coordinator] Handle special-case contract-call to QualifiedContractIdentifier { issuer: StandardPrincipalData(SP000000000000000000002Q6VF78), name: ContractName("pox") } delegate-stack-stx (which returned Response(ResponseData { committed: true, data: Tuple(TupleData { type_signature: TupleTypeSignature { "lock-amount": uint, "stacker": principal, "unlock-burn-height": uint,}, data_map: {ClarityName("lock-amount"): UInt(6000000000000), ClarityName("stacker"): Principal(Standard(StandardPrincipalData(SP2G4JFB3WWBWPVGEDNBTMEVJB6DNDR468G0S03AX))), ClarityName("unlock-burn-height"): UInt(680750)} }) })) 16 | # 17 | # becomes 18 | # 19 | # "" 20 | # {"address": "SP2G4JFB3WWBWPVGEDNBTMEVJB6DNDR468G0S03AX", "delegating": "1", "until": "680750"} 21 | extract_delegate() { 22 | # stdin: a DEBUG-level logfile 23 | # stdout: JSON describing each PoX lock event 24 | gawk ' 25 | { 26 | addr_field = ""; 27 | for (i = 38; i <= NF; i++) { 28 | if ($i != "") { 29 | addr_field = addr_field " " $i 30 | } 31 | } 32 | found = 0 33 | address = "" 34 | is_contract = match(addr_field, /QualifiedContractIdentifier \{ issuer: StandardPrincipalData\(([^)]+)\), name: ContractName\("([^"]+)"\)/, parts) 35 | if (is_contract) { 36 | address = parts[1] "." parts[2] 37 | found = 1 38 | } 39 | else { 40 | is_standard = match(addr_field, /Standard\(StandardPrincipalData\(([^)]+)\)\)/, parts) 41 | if (is_standard) { 42 | address = parts[1] 43 | found = 1 44 | } 45 | } 46 | 47 | found_lock_height = match(addr_field, /ClarityName\("unlock-burn-height"\): UInt\(([0-9]+)\)/, parts) 48 | if (found && found_lock_height) { 49 | printf "{\"address\":\"" address "\",\"type\":\"delegation\",\"until\":\"" parts[1] "\"}\n" 50 | } 51 | } 52 | ' 53 | } 54 | 55 | grep 'Handle special-case contract-call' | grep 'delegate-stack-stx' | grep 'committed: true' | extract_delegate 56 | -------------------------------------------------------------------------------- /considerations/steering-committee.md: -------------------------------------------------------------------------------- 1 | # Consideration for Steering Committee 2 | 3 | Members: 4 | 5 | - Gina Abrams 6 | - Jude Nelson 7 | - Marvin Janssen 8 | 9 | 10 | Discussions-to: https://github.com/stacksgov/sips 11 | 12 | Created-by: SIP-000 13 | 14 | 15 | 16 | ## Biographies 17 | 18 | **Gina Abrams**: Gina is Chief of Staff at Trust Machines, a company building the largest ecosystem of applications on Bitcoin. She has spent the past 5 years working with teams that contributed open-source infrastructure for the Stacks programming layer for Bitcoin, running a number of growth, partnership, and operations focused campaigns. She serves on the Stacks SIP Steering Committee and hosts a monthly Stacker Chat YouTube series with Muneeb and Bitcoin builders. 19 | 20 | **Jude Nelson**: Jude Nelson joined the Stacks ecosystem in 2015, attracted to the unique capabilities of blockchains beyond simply minting cryptocurrencies. A distributed systems PhD, his work has touched many of the Stacks blockchain and core developments. 21 | 22 | **Marvin Janssen**: Marvin has worked on projects related to digital identities, DeFi, and blockchain integration for various players in the crypto space. He co-founded Ryder, working to make next generation crypto hardware a reality. 23 | 24 | ## About this Steering Committee 25 | 26 | The overarching duty of the Steering Committee (SC) is to oversee the evolution of the Stacks blockchain’s design, operation, and governance, in a way that is technically sound and feasible, according to the rules and procedures described in this document. The SC shall be guided by and held accountable by the greater community of users, and shall make all decisions with the advice of the relevant Consideration Advisory Boards. 27 | 28 | The SC’s role is that of a steward. The SC shall select SIPs for ratification based on how well they serve the greater good of the Stacks users. Given the nature of blockchains, the SC's particular responsibilities pertaining to upgrading the blockchain network are meant to ensure that upgrades happen in a backwards-compatible fashion if at all possible. While this means that more radical SIPs may be rejected or may spend a long amount of time in Recommended status, it also minimizes the chances of an upgrade leading to widespread disruption (the minimization of which itself serves the greater good). 29 | 30 | ## Considerations 31 | 32 | ### In-scope 33 | 34 | The following items would be considered in-scope for this SIP Editor Committee: 35 | 36 | 1. To be updated. 37 | 38 | ### Out-of-scope 39 | 40 | The following items would be considered out-of-scope for this SIP Editor Committee: 41 | 42 | 1. To be updated. 43 | 44 | ### Questions for SIP Review 45 | 46 | Questions to facilitate SIP review: 47 | 48 | 1. To be updated. 49 | 50 | _Note: above considerations subject to changes and iterations from ongoing lessons learned_ 51 | 52 | ## Bylaws 53 | 54 | 1. To be updated. 55 | 56 | --- 57 | 58 | _If this Steering Committee interests you and you wish to join the effort, please reach out to @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 59 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2022-11-23-sip-020.md: -------------------------------------------------------------------------------- 1 | 2 | # Technical CAB Minutes 3 | 4 | ## Meeting Information 5 | 6 | **Location:** Discord 7 | 8 | **Recorded:** No 9 | 10 | **Date:** November 23, 2022 11 | 12 | **Time:** Asynchronous 13 | 14 | **Attendees:** 15 | 16 | - Aaron Blankstein 17 | - Brice Dobry 18 | - Dan Trevino 19 | - Daniel Fritsche 20 | - Jamil Dhanani 21 | - Jesse Wiley 22 | - Mike Cohen 23 | - Terje Norderhaug 24 | - Thomas Osmonson 25 | 26 | **Topic(s):** 27 | 28 | - Vote on SIP-020 acceptance 29 | 30 | **Materials**: 31 | 32 | - [SIP-020 Proposal](https://github.com/obycode/sips/blob/bitwise-ops/sips/sip-020/sip-020-bitwise-ops.md) 33 | 34 | ## Meeting Notes 35 | 36 | - SIP-020 voting was opened at 23:28 UTC and closed at 06:36 UTC, using Discord reactions within our group 37 | chat 38 | - SIP author Brice Dobry abstained from vote since they submitted the PR 39 | - Multiple changes to the SIP and accompanying implementation were requested and completed. 40 | - Quorum is met and SIP is approved whether we include the authors or not (4 41 | yes, 0 no out of 8 including authors or 4 yes, 0 no out of 7 excluding 42 | authors) 43 | - [Official approval added to the PR](https://github.com/stacksgov/sips/pull/106#issuecomment-1317808369) 44 | on 16 Nov 2022, including discussed caveats and dissenting opinion 45 | 46 | - Content of the approval: As the temporary chairperson of the Technical CAB (Brice Dobry abstained since they submitted the PR), this 47 | approval indicates official approval of this SIP by the Technical CAB. 48 | 49 | While there were no dissenters who voted no, there is some additional feedback 50 | that should be shared about this specific SIP: 51 | 52 | The dissenting members of the CAB would like to share the following 53 | opinions: 54 | 55 | > The added functionality is neither commonly requested by the community 56 | > nor a blocker for contract developers. The original proposal has several 57 | > red flags indicating the addition shouldn't be a priority, admitting that 58 | > the lack of functionality is not a problem and that the solution just would 59 | > be nice to have. In the discussion, Jude shares that when it comes to the 60 | > new functions, you can implement them today with the existing operations. 61 | > We should expect submitted SIPs to make the case that there is a substantial 62 | > problem, with use cases demonstrating an actual need for a solution. 63 | 64 | > I understand the core team, for some reason, considered it highly important 65 | > that it passed. Perhaps it will benefit marketing by propping up a note 66 | > about community contribution to the Stacks 2.1 implementation. 67 | 68 | ## Action Items 69 | 70 | ## Vote Outcome(s) 71 | 72 | - Aaron Blankstein: no response 73 | - Brice Dobry: abstain (SIP author) 74 | - Dan Trevino: yes 75 | - Daniel Fritsche: no response 76 | - Jamil Dhanani: yes 77 | - Jesse Wiley: yes 78 | - Mike Cohen: no response (no available time) 79 | - Terje Norderhaug: yes 80 | - Thomas Osmonson: no response 81 | 82 | With this vote, the turnout, the quorum and majority requirements previously set 83 | were met and SIP-020 is approved. 84 | -------------------------------------------------------------------------------- /sips/sip-012/scripts/extract-stackers.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | ############################################################ 4 | # Script to extract all STX addresses that are stacking 5 | # in a particular reward cycle, given access to a node's 6 | # debug log file. 7 | # 8 | # Usage: ./extract-stackers.sh REWARD-CYCLE < DEBUG-LOG-FILE 9 | ############################################################ 10 | 11 | set -oue pipefail 12 | 13 | FIRST_BLOCK=666050 14 | REWARD_CYCLE_LENGTH=2100 15 | 16 | # DEBG [1635829849.697968] [src/chainstate/stacks/db/accounts.rs:298] [chains-coordinator] PoX lock 604260000 uSTX (new balance 6104) until burnchain block height 689150 for Standard(StandardPrincipalData(SP2WGGG8E7NVFA0W4YZ87M6R09TNJ33CEBAXB9QPB)) 17 | # DEBG [1635941010.356021] [src/chainstate/stacks/db/accounts.rs:298] [chains-coordinator] PoX lock 12622260119595 uSTX (new balance 0) until burnchain block height 714350 for Contract(QualifiedContractIdentifier { issuer: StandardPrincipalData(SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR), name: ContractName("arkadiko-stacker-v1-1") }) 18 | # 19 | # becomes 20 | # 21 | # {"type";"stacker", "locked":"604260000","until":"689150","address":"SP2WGGG8E7NVFA0W4YZ87M6R09TNJ33CEBAXB9QPB"} 22 | # {"type":"stacker", "locked":"12622260119595","until":"714350","address":"SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR.arkadiko-stacker-v1-1"} 23 | extract_stacker() { 24 | # stdin: a DEBUG-level logfile 25 | # stdout: JSON describing each PoX lock event 26 | gawk ' 27 | { 28 | num_locked = $7 29 | until = $16 30 | addr_field = ""; 31 | for (i = 18; i <= NF; i++) { 32 | if ($i != "") { 33 | addr_field = addr_field " " $i 34 | } 35 | } 36 | found = 0 37 | address = "" 38 | is_contract = match(addr_field, /QualifiedContractIdentifier \{ issuer: StandardPrincipalData\(([^)]+)\), name: ContractName\("([^"]+)"\)/, parts) 39 | if (is_contract) { 40 | address = parts[1] "." parts[2] 41 | found = 1 42 | } 43 | else { 44 | is_standard = match(addr_field, /Standard\(StandardPrincipalData\(([^)]+)\)\)/, parts) 45 | if (is_standard) { 46 | address = parts[1] 47 | found = 1 48 | } 49 | } 50 | 51 | if (found) { 52 | printf "{\"address\":\"" address "\",\"type\":\"stacker\",\"locked\":\"" num_locked "\",\"until\":\"" until "\"}\n" 53 | } 54 | } 55 | ' 56 | } 57 | 58 | block_height_to_reward_cycle() { 59 | # $1: burnchain block height 60 | # stdin: none 61 | # stdout: reward cycle 62 | local block_height="$1" 63 | echo $(( ($block_height - $FIRST_BLOCK) / $REWARD_CYCLE_LENGTH )) 64 | } 65 | 66 | stacking_in_reward_cycle() { 67 | # $1: reward cycle number 68 | # stdin: output from extract_stacker 69 | # stdout: the JSON blobs that are stacking within this reward cycle 70 | local target_reward_cycle="$1" 71 | local json="" 72 | local reward_cycle=0 73 | local first_block=0 74 | local until_ht=0 75 | 76 | while IFS= read -r json; do 77 | until_ht="$(echo "$json" | jq -rc '.until')" 78 | reward_cycle="$(block_height_to_reward_cycle "$until_ht")" 79 | 80 | # echo >&2 "Until reward cycle $reward_cycle: $json" 81 | 82 | if (( "$reward_cycle" > "$target_reward_cycle" )); then 83 | echo "$json" 84 | fi 85 | done 86 | return 0 87 | } 88 | 89 | target_reward_cycle="$1" 90 | grep ' PoX lock ' | extract_stacker | stacking_in_reward_cycle "$target_reward_cycle" 91 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2023-04-26-sip-022.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - April 26, 2023 12 | 13 | **Time:** 15:00 - 16:00 GMT-4 14 | 15 | **Attendees:** 16 | 17 | - Brice Dobry 18 | - Dan Trevino 19 | - Daniel Fritsche 20 | - Jamil Dhanani 21 | - Jesse Wiley 22 | - Mike Cohen 23 | - Terje Norderhaug 24 | - Thomas Osmonson 25 | 26 | **Topic(s):** 27 | 28 | - [SIP-022: Emergency Fix to PoX Stacking Increase](https://github.com/stacksgov/sips/pull/127) 29 | 30 | **Materials**: 31 | 32 | - [SIP-022](https://github.com/stacksgov/sips/blob/dd9f12141ca41be673a6fcb4ddf0a9c5a2e4e221/sips/sip-022/sip-022-emergency-pox-fix.md) 33 | 34 | ## 2023-04-21 Meeting Notes 35 | 36 | The technical CAB discussed SIP-022 asynchronously in a Discord group chat, then 37 | set a time, 15:00 GMT-4, for a vote on the proposed SIP. In the several days 38 | prior to this, the CAB members were encouraged to read through the document and 39 | add comments to the PR as needed. 40 | 41 | A concern was brought up about what exactly the CAB's approval of the SIP 42 | indicates. Terje wrote: 43 | 44 | > We had one job for the SIP-15 CAB review: To green-light that the implemented 45 | > improvements were ready to be safely deployed. The community trusted our 46 | > expertise and that the CABs had done their job when they voted in favor. The 47 | > purpose of the CAB process and community vote was to act as a safeguard. 48 | > Rubber-stamp theater is counter to this purpose. What is our job this time 49 | > around? What exactly does a vote in favor imply? 50 | > 51 | > a) That we approve of the approach suggested in SIP-22 52 | > 53 | > b) That we're confident in the changes in the emergency PR and greenlight the 54 | > first emergeny fork 55 | > 56 | > c) That we're confident in the new PoX3 contract and greenlight deploying the 57 | > second emergency fork 58 | 59 | Brice responded: 60 | 61 | > This CAB is not responsible for green lighting the implementation, just the 62 | > contents of the SIP. We are voting for (a) only I believe, but we can check 63 | > that with the steering committee and/or the governance CAB 64 | 65 | The 66 | [question was posed](https://discord.com/channels/621759717756370964/675389252816732166/1100842976172851312) 67 | to Steering Committee and Governance CAB members in the governance channel, and 68 | Brice's explanation was confirmed: 69 | 70 | > Brice — @Gina Ӿ Can you confirm for the Technical CAB that our voting on SIPs 71 | > is on the contents of the SIP and not on the implementation? Also 72 | > @whoabuddy.btc 👆 if the governance CAB has any clarification on that. My 73 | > belief is that the CABs are only responsible for reviewing the content of the 74 | > SIP, not its implementation, but other CAB members would like confirmation of 75 | > that. 76 | > 77 | > Hero Gamer ⚡ - cc: @jrmith @Marvin 78 | > 79 | > Gina Ӿ — Your belief is correct. The CAB reviews the content of the SIP. 80 | 81 | Aside from that, no other concerns were brought up. Jesse mentioned that there 82 | were still some minor edits being made, mostly grammar changes. Dan T. mentioned 83 | that, "the process and reasoning is sound." 84 | 85 | Six votes were made for the proposal: 86 | 87 | | Name | Vote | 88 | | --------------- | ---- | 89 | | Jamil Dhanani | 👍 | 90 | | Dan Trevino | 👍 | 91 | | Jesse Wiley | 👍 | 92 | | Thomas Osmonson | 👍 | 93 | | Mike Cohen | 👍 | 94 | | Brice Dobry | 👍 | 95 | 96 | The Technical CAB approves SIP-022 with 6 yes votes. 97 | -------------------------------------------------------------------------------- /sips/sip-027/scripts/validate-and-count-votes/nonStackerVotes.js: -------------------------------------------------------------------------------- 1 | import axios from "axios"; 2 | import { writeFileSync } from "fs"; 3 | 4 | const STX_ADDRESS = "SP3JP0N1ZXGASRJ0F7QAHWFPGTVK9T2XNXDB908Z.bde001-proposal-voting"; 5 | const MULTISIG_DAO_VOTES_FILE = 'multisig-dao-votes.csv'; 6 | 7 | async function fetchAddressTransactionsStacks(offset, address) { 8 | try { 9 | const response = await axios.get(`https://api.hiro.so/extended/v2/addresses/${address}/transactions?limit=50&offset=${offset}`); 10 | 11 | return response.data.results; 12 | } catch (error) { 13 | if (error.response) { 14 | if (error.response.status === 429) { 15 | await new Promise((resolve) => setTimeout(resolve, 10000)); 16 | return fetchAddressTransactionsStacks(offset, address); 17 | } else { 18 | console.error(`Error: ${error}`); 19 | } 20 | } else { 21 | console.error(`Error: ${error}`); 22 | } 23 | return null; 24 | } 25 | } 26 | 27 | function convertVotesToCsv(votes) { 28 | const headers = 'voter,txid,for,power\n'; 29 | const rows = votes.map(vote => 30 | `${vote.voter},${vote.txid},${vote.for},${vote.power}` 31 | ).join('\n'); 32 | 33 | return headers + rows; 34 | } 35 | 36 | async function fetchAllData() { 37 | let moreData = true; 38 | let offset = 0; 39 | 40 | let noAmount = 0; 41 | let noCount = 0; 42 | 43 | let yesAmount = 0; 44 | let yesCount = 0; 45 | 46 | let daoVotesForCsv = []; 47 | 48 | while (moreData) { 49 | const data = await fetchAddressTransactionsStacks(offset, STX_ADDRESS); 50 | 51 | if (data && data.length > 0) { 52 | for (const entry of data) { 53 | if (entry.tx.burn_block_height >= 854950 && entry.tx.burn_block_height < 857050) { 54 | if (entry.tx.tx_status == "success" && entry.tx.tx_type == "contract_call" && entry.tx.contract_call.function_name == "vote" && entry.tx.contract_call.function_args[2].repr == "'SP3JP0N1ZXGASRJ0F7QAHWFPGTVK9T2XNXDB908Z.sip-027-multisig-transactions") { 55 | if (entry.tx.contract_call.function_args[1].repr == "true") { 56 | const amount = parseInt(entry.tx.contract_call.function_args[0].repr.slice(1)); 57 | yesAmount += amount; 58 | yesCount++; 59 | daoVotesForCsv.push({ 60 | voter: entry.tx.sender_address, 61 | txid: entry.tx.tx_id, 62 | for: true, 63 | power: amount, 64 | }); 65 | } else if (entry.tx.contract_call.function_args[1].repr == "false") { 66 | const amount = parseInt(entry.tx.contract_call.function_args[0].repr.slice(1)); 67 | noAmount += amount; 68 | noCount++; 69 | daoVotesForCsv.push({ 70 | voter: entry.tx.sender_address, 71 | txid: entry.tx.tx_id, 72 | for: false, 73 | power: amount, 74 | }); 75 | } else { 76 | console.log("Wrong data:", entry.tx.contract_call); 77 | }; 78 | }; 79 | }; 80 | } 81 | offset += 50; 82 | } else { 83 | moreData = false; 84 | } 85 | } 86 | 87 | console.log("Amount against:", noAmount); 88 | console.log("Amount for:", yesAmount); 89 | console.log("Count against:", noCount); 90 | console.log("Count for:", yesCount); 91 | 92 | const daoVotesCsv = convertVotesToCsv(daoVotesForCsv); 93 | 94 | writeFileSync(MULTISIG_DAO_VOTES_FILE, daoVotesCsv); 95 | 96 | console.log('CSV files have been saved successfully.'); 97 | } 98 | 99 | fetchAllData() -------------------------------------------------------------------------------- /considerations/sip-editors.md: -------------------------------------------------------------------------------- 1 | # Consideration for SIP Editors 2 | 3 | Members: 4 | 5 | - AcrossFire 6 | - j2p2 7 | - Rafael Cárdenas 8 | - werner.btc 9 | 10 | 11 | Discussions-to: https://github.com/stacksgov/sips 12 | 13 | Created-by: SIP-000 14 | 15 | Invite tree: 16 | 17 | - HeroGamer recommended 18 | * AcrossFire 19 | * j2p2 20 | * Rafael Cárdenas 21 | * werner.btc 22 | 23 | 24 | ## Biographies 25 | 26 | **AcrossFire**: AcrossFire has experience as a DevOps engineer, Linux enthusiast, and a passionate Bitcoiner. He has experience with systems administration and enjoys automating maintenance tasks using tools like Puppet, Ansible, Docker, Kubernetes and others. He likes to bring this experience to Bitcoin by running Bitcoin and Stacks nodes and doing what he can to optimize the experience. 27 | 28 | **j2p2**: Computer Engineer, Clarity Developer. Won First and Second place in Clarity Course Cohort #2 Hackathon. Before joining the Stacks ecosystem, worked 18+ years building software for wireless communication systems products. 29 | 30 | **Rafael Cárdenas**: Rafael is a Staff Software Engineer at Hiro, focused on building and maintaining Hiro’s API infrastructure which includes the Stacks Blockchain API, Ordinals API, Token Metadata API and others, all of which power dozens of apps and wallets built on Stacks and Bitcoin. Rafael has also been an active member and contributor of the Stacks ecosystem since 2021, involved with the development of the core blockchain through the SIP process and participating as a reviewer at the Stacks Accelerator. 31 | 32 | **werner.btc**: Since 2021, Werner has been an active Stacks community member and helper. As an artist, tester, and jack of many traits, my contributions are rooted in a passion for supporting the Stacks ecosystem. Werner is dedicated to working towards a more equitable, open internet that is inherently safe through the adoption of Bitcoin technology. 33 | 34 | ## About this SIP Editor Committee 35 | 36 | The role of a SIP Editor is to identify SIPs in the Draft status and help transition them to Accepted status. A SIP editor must be able to vet a SIP to ensure that it is well-formed, that it follows the ratification workflow faithfully, and that it does not overlap with any already-Accepted SIPs or SIPs that have since become Recommended or Ratified. 37 | 38 | The SIP Editors are responsible for maintaining the "inbound funnel" for SIPs from the greater Stacks community. SIP Editors ensure that all inbound SIPs are well-formed, relevant, and do not duplicate prior work (including rejected SIPs). 39 | 40 | SIP Editors should be open and welcoming towards enthusiastic users who want to help improve the greater Stacks ecosystem. As such, SIP Editors should encourage users to submit SIPs if they have good ideas that may be worth implementing. 41 | 42 | In addition, SIP Editors should respond to public requests for help from community members who want to submit a SIP. They may point them towards this document, or towards other supplemental documents and tools to help them get started. 43 | 44 | ## Considerations 45 | 46 | ### In-scope 47 | 48 | The following items would be considered in-scope for this SIP Editor Committee: 49 | 50 | 1. To be updated. 51 | 52 | ### Out-of-scope 53 | 54 | The following items would be considered out-of-scope for this SIP Editor Committee: 55 | 56 | 1. To be updated. 57 | 58 | ### Questions for SIP Review 59 | 60 | Questions to facilitate SIP review: 61 | 62 | 1. To be updated. 63 | 64 | _Note: above considerations subject to changes and iterations from ongoing lessons learned_ 65 | 66 | ## Bylaws 67 | 68 | 1. To be updated. 69 | 70 | --- 71 | 72 | _If becoming a SIP Editor interests you and you wish to join the effort, please reach out to @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 73 | -------------------------------------------------------------------------------- /sips/SIP_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # Preamble 2 | 3 | SIP Number: _This field will be updated by SIP Repo maintainers._ 4 | 5 | Title: xx 6 | 7 | Author(s): 8 | * Name < email > 9 | * Name < email > 10 | 11 | Status: Draft 12 | 13 | Consideration: Governance, Technical, Economics _(select one or multiple relevant approval committee based on the nature SIP proposed)_ 14 | 15 | Type: Consensus; Standard, Operation, Meta, Informational _(select one most relevant)_ 16 | 17 | Layer: Consensus (soft fork), Consensus (hard fork), Peer Services, API/RPC, Traits, Applications _(select one most relevant, if not applicable leave blank)_ 18 | 19 | Created: 0000-00-00 _(Year-Month-Day)_ 20 | 21 | License: BSD-2-Clause 22 | 23 | Sign-off: _This field will be updated by SIP Repo maintainers._ 24 | 25 | Discussions-To: 26 | * Link to where previous discussions took place. For example a mailing list or a Stacks Forum thread. 27 | 28 | # Abstract 29 | 30 | High-level summary of the proposed improvement. 31 | 32 | # Copyright 33 | 34 | This SIP is made available under the terms of the BSD-2-Clause license, 35 | available at https://opensource.org/licenses/BSD-2-Clause. This SIP’s copyright 36 | is held by the Stacks Open Internet Foundation. 37 | 38 | Each SIP must identify at least one acceptable license in its preamble. Source 39 | code in the SIP can be licensed differently than the text. SIPs whose reference 40 | implementation(s) touch existing reference implementation(s) must use the same 41 | license as the existing implementation(s) in order to be considered. Below is a 42 | list of recommended licenses. 43 | 44 | - BSD-2-Clause: OSI-approved BSD 2-clause license 45 | - BSD-3-Clause: OSI-approved BSD 3-clause license 46 | - CC0-1.0: Creative Commons CC0 1.0 Universal 47 | - GNU-All-Permissive: GNU All-Permissive License 48 | - GPL-2.0+: GNU General Public License (GPL), version 2 or newer 49 | - LGPL-2.1+: GNU Lesser General Public License (LGPL), version 2.1 or newer 50 | 51 | # Introduction 52 | 53 | Provide a high-level summary of the problem(s) that this SIP proposes to solve, as well as a high-level description of how the proposal solves them. This section shall emphasize its novel contributions, and briefly describe how they address the problem(s). Any motivational arguments and example problems and solutions belong in this section. 54 | 55 | # Specification 56 | 57 | Provide the detailed technical specification. It may include code snippets, diagrams, performance evaluations, and other supplemental data to justify particular design decisions. However, a copy of all external supplemental data (such as links to research papers) must be included with the SIP, and must be made available under an approved copyright license. 58 | 59 | # Related Work 60 | 61 | Summarize alternative solutions that address the same or similar problems, and briefly describe why they are not adequate solutions. This section may reference alternative solutions in other blockchain projects, in research papers from academia and industry, other open-source projects, and so on. This section must be accompanied by a bibliography of sufficient detail such that someone reading the SIP can find and evaluate the related works. 62 | 63 | # Backwards Compatibility 64 | 65 | Address any backwards-incompatiblity concerns that may arise with the implementation of this SIP, as well as describe (or reference) technical mitigations for breaking changes. This section may be left blank for non-technical SIPs. 66 | 67 | # Activation 68 | 69 | Describe the timeline, falsifiable criteria, and process for activating the SIP once it is ratified. 70 | 71 | # Reference Implementation 72 | 73 | One or more references to one or more production-quality implementations of the SIP, if applicable. This section is only informative — the SIP ratification process is independent of any engineering processes (or other processes) that would be followed to produce implementations. 74 | 75 | # References 76 | 77 | [1] 78 | 79 | [2] 80 | 81 | [3] 82 | -------------------------------------------------------------------------------- /considerations/minutes/economic-cab/2022-10-29-sip-015.md: -------------------------------------------------------------------------------- 1 | # Economic CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Google Meet 6 | 7 | **Recorded:** No 8 | 9 | **Date:** October 29, 2022 10 | 11 | **Time:** 17:00 - 18:00 UTC 12 | 13 | **Attendees:** 14 | 15 | - mattyTokenomics 16 | - Chiente 17 | - Xan 18 | - Pieter 19 | 20 | **Topic(s):** 21 | 22 | - General CAB process 23 | - SIP-015 24 | 25 | **Materials**: 26 | 27 | - [SIP-015 proposal](https://github.com/stacksgov/sips/blob/feat/sip-015/sips/sip-015/sip-015-network-upgrade.md) 28 | 29 | ## Meeting Notes 30 | 31 | - The change proposed in SIP-015 to count mining creates a _potential_ economic risk and attack vector 32 | 33 | - Specifically the change: "...the median Bitcoin spend of the miner's last six block-commits will include late block-commits." 34 | - Depending on how this is implemented, a user could potentially 'spoof' having been _attempting_ to mine a majority of the previous 6 blocks 35 | - By selectively doing this only when mining happens to be profitable, or when the miners corresponding stacking slot is up for rewards miners can abuse system 36 | 37 | - The changes proposed in SIP-015 to stacking methods (namely enabling contintual renewal and increasing of stacking) are critical primitives 38 | 39 | - As long as these changes are backwards compatible, this CAB sees no economic risks or externalities 40 | - Next steps would be to enable liquid stacking by supporting the create of an 'xSTX' token, conceptually similar to 'stETH'. Each 1 xSTX token would represent 1 stacked STX toke that accrues stacking rewards 41 | - There are several challenges specific to STX that stETH/ETH does not face, such as that STX accumulates stacking rewards in native BTC, which would need to be programatically claimed/distributed when xSTX is converted back into STX 42 | - However, it is this CAB's belief that such an xSTX token would create significant economic benefits to the overall STX ecosystem, as currently all use cases and DeFi applications for STX have to essentially compete with the opportunity cost of earning stacking yield on that STX 43 | - Being able to earning stacking yield, _and_ productively use STX at the same time (via xSTX) is the next step in stacking improvements 44 | - We propose that a working group or similar, with interested parties is formed to lay out the requirements for such an 'xSTX' token. Relevant parties include: 45 | - DeFi Protocols: 46 | - ALEX (CAB member Chiente) 47 | - Arakdiko (CAB member Pieter) 48 | - Atomic swaps (for potentially aiding is native BTC yield distribution): 49 | - Magic Bridge 50 | - lnSwap 51 | - Stacking Pools 52 | - Friedger's Pool 53 | - PlanBetter 54 | - Xverse 55 | 56 | - CAB Process itself 57 | - The Economics CAB was not formally required as a party to sign off on SIP-015 58 | - Yet we found an _economic attack motivation_ created by the SIP, that depending on _technical implementation_ may or may not be viable 59 | - The presence of such situations (in the very first CAB review no less) suggests that the overall SIP/CAB process should consider **all** CABs being required on SIPs, and those CABs required to either Approve, Disapprove, or formally indicate the SIP is not relevant to them 60 | - This would make the process more burdensome, but given the high stakes and interdependencies involved in such complex systems, may be the wiser approach 61 | 62 | ## Action Items 63 | 64 | - [x] Raise the economic risk created in SIP-015 mentioned above to core SIP authors (Jude) 65 | - [] Assemble an xSTX working group 66 | - [] Confirm with the SIP process group if the CAB process itself should default require all CABs (i.e. opt-out, not opt-in) 67 | 68 | ## Vote Outcome(s) 69 | 70 | - The board unanimously voted for the Approval of SIP-015 **pending** confirmation that the change to minining behaivor is implemented such that this potential attack can not actually be carried out in practice 71 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2025-07-16-sip-031.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - July 16, 2025 12 | 13 | **Attendees:** 14 | - j2p2 (chairperson) 15 | - brice 16 | - setzeus 17 | - AshtonPhtevenz 18 | - jw 19 | - friedger.btc 20 | - mijoco.btc 21 | - Vlad (late vote noted; excluded from tally) 22 | 23 | **Topic(s):** 24 | 25 | - Vote on SIP-031 26 | 27 | **Materials**: 28 | 29 | - SIP-031 documents in `sips/sip-031/` 30 | 31 | ## 2025-07-16 Meeting Notes 32 | 33 | The Technical CAB met to consider SIP-031. 34 | 35 | **Technical Discussion Summary** 36 | 37 | The Technical CAB reviewed the technical details and implementation plan for SIP-031 as outlined in [PR #214](https://github.com/stacksgov/sips/pull/214). The discussion focused on the following key areas: 38 | 39 | - **Boot Contract Design:** Members discussed the minimal boot contract approach, which enables the emission of new STX to a designated recipient address. The contract supports recipient rotation via a simple `update-recipient` function, allowing for signer set changes without requiring additional hard forks. The contract also includes `get-recipient` and `claim` functions for transparency and operational simplicity. 40 | 41 | - **Security and Auditability:** There was consensus on the importance of on-chain auditability for all mint and unlock events. The design ensures that every emission is accompanied by an on-chain receipt, and the logic is intentionally simple to minimize attack surface and implementation risk. 42 | 43 | - **Multisig Recipient and Governance:** The initial recipient is a 3-of-5 multisig derived from Treasury Committee pubkeys. The process for rotating signers was discussed, with agreement that the contract’s upgradability for recipient changes (without further forks) is a critical feature for operational flexibility and security. 44 | 45 | - **Emission Schedule and Economic Impact:** The emission schedule—100M STX at activation, 100M STX unlocked over 24 months, and 300M STX distributed over 60 months—was reviewed. Members discussed the inflationary impact, with modeling showing a projected ~5.75% annualized inflation rate. The group acknowledged the tradeoff between ecosystem funding and inflation, and agreed the schedule is within acceptable bounds. 46 | 47 | - **Implementation Details and Open Questions:** The CAB noted that the contract code is still to be finalized, and implementation details (such as error handling, edge cases, and integration with PoX) will require further review. There was a request for clear documentation and test coverage before mainnet deployment. 48 | 49 | - **Consensus:** No major technical objections were raised. The CAB agreed that the proposed design is sound, with appropriate safeguards and flexibility. The group recommended proceeding with implementation, subject to final code review and testing. 50 | 51 | **Summary:** The CAB’s technical review found the SIP-031 boot contract design and emission schedule to be robust, auditable, and operationally flexible, with no blocking technical issues identified in the PR discussion. 52 | 53 | ## Vote Outcome 54 | 55 | Quorum is reached with 7 of 9 eligible CAB members voting on the SIP by the final deadline (Tuesday, 8 July 2025 16:00 EST). 56 | Vote options were ✅ (yes), 🚫 (no), or 🤷 (abastain/no preference/insuficient context). 57 | 58 | | Name | Vote | 59 | | ---------------- | ---- | 60 | | Aaron Blankstein | | 61 | | Ashton Stephens | ✅ | 62 | | Brice Dobry | ✅ | 63 | | Friedger | 🤷 | 64 | | j2p2 | ✅ | 65 | | Jesse Wiley | ✅ | 66 | | Mike Cohen | 🤷 | 67 | | Setzeus | ✅ | 68 | | Vlad | ✅ | 69 | 70 | Final Tally: 71 | 72 | | Option | Count | 73 | | ------ | ----- | 74 | | ✅ Yes | 5 | 75 | | 🚫 No | 0 | 76 | | 🤷 - | 2 | 77 | 78 | Late vote: One member submitted vote after the deadline. It is recorded in these minutes for completeness but excluded from the tally. 79 | 80 | The Technical CAB *approves* SIP-031 with 5 yes and 2 no preference votes. 81 | 82 | 83 | 84 | -------------------------------------------------------------------------------- /sips/sip-025/votes.csv: -------------------------------------------------------------------------------- 1 | Please Verify Signer Key,SIP Vote Choice,Vote Hash,Signer Entity Name 2 | 034df3feda207a1cd4f31ae2b58f136a0d382d23419ef8d06569fa538202ba8aed,Yes,014959b57f14e0ac5c1e5e9544f77149508585ba7f5555445c789a17f242f562c5141636b82eb977e79ef8872e2c51a8458e4e60d0c0f974dd54466c28a5424ecd,Chorus One 3 | 02b20a0603a409270d4421d89a831e8f7b2fa7c5f2d8872d7aa94737334d10c194,Yes,014ae940f533560c03f3c035c260e08911a6c9fe0ced596cd9c8a4a381ad92104b087e9de3fa39d7f3877120681820e7bacbe0f28a6217bde66f0134da39c08c1c,luxor-stacks-signer 4 | e076e4d2e24f,Yes,017019bcba419b6c825cf54992cc28f513f58e121a6c8ef496fdb3f0056b52b6306cb33d75d9619b2172c4e5c4524a26c1e635c6c194acae0702ebdef93b165e0d,Stacking DAO 5 | 02c54d8b1ba4b7207f78f861c60f8a67433c264a11ac9b6b7773476e9f6c008e49,Yes,0128f2e99304106a322f3ea54f71fc3a9f5b9d33bf6c4565bd4efaa6ab74b4e4f25231a9a2cb773f2e1b74eddd27a40fdc2d38beb3edba4e1f05ddb9add7854996,InfStones 6 | 0215245613e31de2ec2e7f2c4facb45724be2e49d9d42abb0a5e571322593b36bf,Yes,01dcbc8aacb7777435340a1f634e36a54751f6436e341ae790a0b48fcb6a130c5a5392fc4a267df006143fbd6c38a4f163faf60f7e99a2d79794cc44f626b78d3a,Kiln* 7 | 039dc5297b92c1f6b48f4a68e180b853ff6e8188fb78422652a90b8fe14941adce,Yes,012ac5c792ee205fb359ed3062d0e52ae907a37ff1195f0aaf215902c7f9aab54979a99b2f0269264054ef9314c09375eec45c4909f6657315811d31786a6fb1e5,Kiln 8 | 02254a34747123978819f2a90506f76cb057fe3fbff6d8721a0d9cf8e9412d0e60,Yes,0024e00247214e8184631ce78f2990f269b06801e87ce88d764f3fb1f1ec0fda0c657dd028522cd8406bd1200cf3eae90f4ab517951ab816cf290806539237b061,Chorus One 9 | 03cef32afac202346ac76a28e81e77ed497c3f22ce20ac54b496950b4ef0b74b2e,Yes,01ab8beeb22bd4db2b34c90c17b313d1774fed3458808548b0c81425c9dc7ad1390234239a302e7144c07006b1dafd13616d6ca68c9fcb0962cda4dc016caaa040,Staking Defense League 10 | 03a541c1ec2cfb32da48cfadf439c9b2f27d166bbffa18a178c7a6a0d54cfa7813,Yes,01f4f9ad555cdbfcf7b1a77a3ea9291103bc936d137c2e4624ac7e80b4f31cf41e079abc3bbc79f8daaaffadaf2e6c8d49215f761db2d053ac7587a376fc4121a5,Blockdaemon 11 | 03e0df37e83e43847625a0320456cb9758050a61ce76c2c130bf50242f27ba6d54,Yes,012223040a6a808515956a509a4b44e656e6fab0f9e788c6eff14ff66274086f481ad1094f3ddd1c558f586acc31c15943ab294857bbe859987520522874e91cb1,Alum Labs 12 | 03ed732eab6b99b90315f9b58ce9c3e2d1991bc4e9cfa59841535c0ef7dbba38e0,Yes,013a514ea2da121cac2a81e5881eedcee1a2aeceb89b8a0bc539627928c3f5e8bb7f76eb82ce6c8dd229fb173087b5dfe45c57dee01e08acd62dd40dcc4a2d953a,Planbetter Pool 13 | 03fb8ad634c6cd072a5dfb0a3b237e3134cfee64b2adb8246c168bb4f6b0aa220c,Yes,01284bf5da25407e672e0bcce293c1844d4e3b287982f9f1de39ee47cbf7d406b33545eb9ca46cbbb2ec9035c5d6aefd51b16f4dd9bf77984f2f47c7d6e7b292ef, 14 | 029e1245f007bd8f76d5ce67e759acd21f8b0f2538a80713468f7524bf3fff6136,Yes,017c8aa1b486b5c5ee0a49d05ce993649696624a83293599a1ede5443f1bf8ba4d7791ccd227336b20e40804cd619ac1fb176bc6bcfcd30f1f58ca809d84b61837,Luganodes 15 | 0321129d7a3e14cce66abef68b9a3d31d998f14e9a18b09d66aa1110fc604a3b1f,Yes,0170ef0c17704a69b65440778b36aeb347860457077a07da9dd1f60698bc6d36c240d6f39181ac897d9c9d35b4d6601694187ecb14a49d66c9811363dd95204eef, 16 | 03cc1da6f6235699284987f7d3a98a950b0c693cdbed87ab33c04f61e2dfb6a177,Yes,01612e9945ec7731a40f906781076dab396508da714f641045c1dd24d009a4d1370412073a2f44ff828a4f72728df50a6370626956d4f1c6fe538595d9c316cdfb,Despread 17 | 023d6ecdc36fa1e1c6a9f116c7f13ae843001ed9d617f66f6c68cabf751bf82555,Yes,00231bfd8c638cf3f7eb9ef92cf4742e7c352c3b328c45606f1588de9a0ec8c577532326710d61e2b413014e172feb59192c5848fa4974f000b5402ad9236e1f5a,Fast Pool 18 | 024f164c6e73df283d34d7d9cc86553a82dce76045ba7dfbf4de0004f89eabb8e0,Yes,0103258e9590279cf9c6d9b711f1cb78938b6220c89ca984af7a9ac57681437c197d47d37914b67babd862160c2868990d7dcc24e822de686150087a94ccedcca9,SenseiNode 19 | 0244869db071d334ff8e5cd94956ae7b60a4abd41f83f3c9d66ab314718151d94d,Yes,00c7468ed99e8f67e3bc95ab04d4228df05b4c48a1c776996e1eaa767e432e614a0ce4f4c7a667c59d042fb1863e01f9a1a073a0bbca0db2c359e8cb6ed72cb352,Restake 20 | 0284df4505c6318a0017a7848aa0a95bf8cd3db697a89d2ec1978a027bece770ef,Yes,007efbe5ff9022e9cd8eb5f51c1b9b026392d26cc6883eaaba29c472b0e01f09436d59c4ea428fe49a059380caf9f468cc0cb90b406e32bd1885058053824d0380,Degen Lab 21 | 0303144ba518fe7a0fb56a8a7d488f950307a4330f146e1e1458fc63fb33defe96,Yes,0112b2bd6204e543ca5c88036311f62273674cf677a80db1c484c4d1ade3fd4e16219cc8fc12bcdae725d9c0afeb5cb7f0086d7d7bbf48347531a5f967b67170db, 22 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2022-10-27-sip-015.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Zoom 6 | 7 | **Recorded:** No 8 | 9 | **Date:** October 27, 2022 10 | 11 | **Time:** 20:00 - 20:45 UTC 12 | 13 | **Attendees:** 14 | 15 | - Brice Dobry (chair) 16 | - Dan Trevino 17 | - Jesse Wiley 18 | - Thomas Osmonson 19 | 20 | **Topic(s):** 21 | 22 | - CAB processes 23 | - [SIP-015: Stacks Upgrade of Proof-of-Transfer and Clarity](https://github.com/stacksgov/sips/pull/95) 24 | 25 | **Materials**: 26 | 27 | - [Google Slides](https://docs.google.com/presentation/d/1-O5kdhkjq43nZo8lu5v7ibGrQSu1K7rIBAWEoloraQc/edit#slide=id.g1783f051b1c_0_0) 28 | 29 | ## Meeting Notes 30 | 31 | - This was the first synchronous meeting of the CAB, so we started off with 32 | brief introductions of the attendees. 33 | - CAB processes 34 | - Confirmed tasks of the CAB: 35 | 1. Provide expert feedback on _Accepted_ SIPs 36 | 2. Vote to transition SIPs from _Accepted_ to _Recommended_ or _Rejected_ 37 | - How should we provide expert feedback on _Accepted_ SIPs (1)? 38 | - The members of the CAB will individually comment on the PR -- no 39 | coordination amongst the group is necessary for this step 40 | - How should we vote to transition SIPs (2)? 41 | - We will ultimately make a single decision, yes or no for each SIP. 42 | - We will require a 51% quorum of CAB members to have voted, and a 51% 43 | majority to determine the vote 44 | - As there are 9 CAB members currently, there will be a minimum of 5 45 | (`floor(9/2) + 1`) members required for a vote to count and if exactly 5 46 | vote, then the threshold is 3 (`floor(5/2) + 1`) 47 | - Vote will be asynchronous, via our Discord group chat 48 | - For the SIP-015 vote, voting will open on Monday, Oct. 31 at 11:00 UTC 49 | and close at 21:00 UTC. 50 | - The decision of the CAB will be shared via an approve/reject on the SIP's 51 | PR by the chairperson of the CAB 52 | - PR review to include comments for a majority opinion, as well as a 53 | dissenting opinion 54 | - This decision and the opinion writeups will also be recorded in the 55 | [sips repository](https://github.com/stacksgov/sips/tree/main/considerations/minutes/technical-cab) 56 | - These processes will be added to the 57 | [CAB's bylaws](https://github.com/stacksgov/sips/blob/main/considerations/technical.md#bylaws) 58 | - Discussed how code changes relate to the SIP process, and the CAB's 59 | responsiblity 60 | - The implementation / code supporting a SIP is typically a later step in 61 | the process 62 | - Evaluating the implementation of the SIP is outside the purview of this 63 | CAB (though its members are appropriate candidates for code reviews) 64 | - Discussed the need for a shared email list for the group, as well as a 65 | mechanism for scheduling meetings 66 | - Discussed an intent to setup a monthly recurring meeting for the group to 67 | sync up 68 | - Proposed Mondays, but will use some tool to help figure out best 69 | availability for the group 70 | - Additional meetings outside of this regularly scheduled meeting may be 71 | required for specific SIPs and will be scheduled ad-hoc 72 | - SIP-015 discussions 73 | - Concerns have been expressed that this SIP is too large and contains 74 | unrelated items 75 | - Members feel that the CAB should be able to vote on individual, related 76 | items, not one kitchen sink SIP 77 | - As the SIP is already implemented, it would be difficult to make a 78 | substantial change like this 79 | - Present members agreed that it is okay to not be too strict this time, but 80 | we should make strong recommendations against this for the next time (and 81 | potentially reject for this reason in the future) 82 | - Ensure that we voice our concerns about the size and scope of this SIP 83 | 84 | ## Action Items 85 | 86 | - [x] Setup mailing list 87 | - After the meeting, Jesse Wiley created technical-cab@stacks.org for us 88 | - We verified that this will work for sending calendar invites to the group as 89 | well 90 | - [ ] Setup recurring meeting (Brice) 91 | - [ ] Continue asynchronous feedback on SIP-015 PR (All) 92 | - [ ] Update CAB bylaws with discussed items 93 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2024-01-24-sip-021.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Zoom 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - January 24, 2024 12 | 13 | **Time:** 8:00pm - 9:00pm UTC 14 | 15 | **Attendees:** 16 | 17 | - Brice Dobry (chairperson) 18 | - Aaron Blankstein 19 | - Dan Trevino 20 | - Jesse Wiley 21 | - Jesus Najera 22 | - Mike Cohen 23 | - 0xdima 24 | 25 | **Topic(s):** 26 | 27 | - Discuss the Nakamoto SIP, in preparation for a vote on Friday (2024-01-26) 28 | 29 | **Materials**: 30 | 31 | - [PR #155: Nakamoto v1](https://github.com/stacksgov/sips/pull/155) 32 | 33 | ## 2024-01-24 Meeting Notes 34 | 35 | - Discuss [problem brought up by Economics CAB](https://discord.com/channels/@me/1015360202419220530/1199366545068003369) 36 | - Explain the issue 37 | - What is the scope of the problem? 38 | - 1 block reorgs on Bitcoin happen ~daily, 2 block reorgs happen ~every 2 weeks 39 | - 1 block reorg wouldn't impact the Stacks network because these are blocks that were broadcast simultaneously, and the stackers would already be picking a winner amongst themselves, so these would look as if no bitcoin block is getting processed, causing an extension of the previous miner's tenure 40 | - The 2 block reorg would look like some amount of time where there were no Stacks blocks 41 | - What would be a reasonable number of blocks to wait for confirmations after Nakamoto? 42 | - On day 1, the ordering enforcement would not be in place; would still recommend waiting the same number of bitcoin blocks 43 | - What is the max depth of bitcoin reorgs in last 10 years? 6 blocks? 44 | - Is this improved since Stacks blocks don't fork independently in Nakamoto? 45 | - Yes, this is a strict improvement 46 | - Will we see situations where we have a large number of tx in the mempool after Nakamoto? 47 | - There is how fast txs can be processed and there is demand for txs 48 | - Life with a full mempool is likely no matter what (this is a measure of success) 49 | - Clarify that the goal of the SIP is not to guarantee better than Bitcoin security, just matching it, and this is definitively an improvement over current Stacks 50 | - The throughput should be more manageable with these Nakamoto improvements 51 | - Is there any analysis of follower nodes and how this will affect time to reach tip? 52 | - Better in some ways, worse in others 53 | - Improved - networking stack improvements, way that blocks are announced on the network is changed, should be much improved 54 | - Worse - throughput is going up, so there is more to validate (more CPU and more I/O); currently, at most half is actually validating blocks and the other half is dealing with networking 55 | - Would subnets be compatible? 56 | - In theory, there is no reason that they shouldn't be compatible 57 | - In practice, they may need updates in the wire formats to match Nakamoto changes 58 | - Will there ever be a situation where you could not have enough I/O to catch up? 59 | - The network has low requirements, but, even today, a slow enough machine could have an issue 60 | - Recent blocks have been quite large and there have been quite heavy transactions, these all put a strain on nodes 61 | - Where does the 5s number come from? 62 | - It's a number that has been mentioned several places, we need some clarity on this 63 | - Common misconception that this means blocks as full as the current blocks in 5s 64 | - The throughput should not be expected to be 120x 65 | - Any mention of recovery? 66 | - The current implicit recovery mechanism is a future emergency SIP 67 | - If a recovery needs to occur because the signer set collapsed or something, the only recovery currently is an emergency hard fork 68 | - What does the process look like for a node operator? 69 | - There shouldn't be any real changes, aside from some updates to the guidance on system resources 70 | - May need to sync from genesis (or use a snapshot) 71 | - Looking at Dan's comments about clarifying the signature validation methods 72 | - Under "Stacker Signing", there is an "X%" that needs to be filled in with a real number 73 | - Aaron says that this paragraph should be reworded - it is not accurate 74 | - Empty reward slots should not effect the percentage 75 | - Aaron will comment on this 76 | - Activation criteria 77 | - Ensure that the wording is updated to allow voting from non-stackers 78 | -------------------------------------------------------------------------------- /considerations/technical.md: -------------------------------------------------------------------------------- 1 | # Consideration for Technical SIPs 2 | 3 | Chairperson: Jesse Wiley 4 | 5 | Members: 6 | 7 | - Aaron Blankstein 8 | - Brice Dobry 9 | - j2p2 10 | - Friedger 11 | - Jesse Wiley 12 | - Radu 13 | - Setzeus 14 | - Vlad 15 | 16 | Discussions-to: https://github.com/stacksgov/sips 17 | 18 | Created-by: SIP-000 19 | 20 | ## Biographies 21 | 22 | **Aaron Blankstein**: Aaron is a staff engineer at Hiro, contributing to the Stacks blockchain and Clarity. He has been working on the Stacks blockchain for 7+ years, working on Proof-of-Transfer consensus, Clarity, and other projects. 23 | 24 | **Brice Dobry**: Brice is a staff engineer at Hiro, working on Clarinet and other developer tools, and contributing to the Stacks blockchain. Coming from a background in compilers, programming languages, and analysis tools, he is passionate about helping developers build productively, efficiently and safely. 25 | 26 | **j2p2**: Computer Engineer and Clarity Developer. Won First and Second place in Clarity Course Cohort #2 Hackathon. Contributed to Stacks as a SIP editor; co-founded leos.guru, an educational platform, and chat.stacksgpt.xyz, a Q&A bot for Stacks & Bitcoin. 27 | 28 | **Friedger**: Friedger is an entredeveloper based in Europe. He contributed to the Stacks ecosystem in various forms. 29 | 30 | **Jesse Wiley**: Jesse Wiley is a seasoned DevOps expert - he makes sure all systems are running smoothly and the right security considerations have been made. 31 | 32 | **Radu**: Radu is a testing expert with several years of experience in fuzz testing. He is co-creator of Rendezvous, the first fuzzer for Clarity smart contracts, and a core contributor to the Stacks blockchain. He has been building on Stacks for 4+ years and has contributed to multiple decentralized protocols, including PoX-related, DeFi, and GameFi projects. 33 | 34 | **Setzeus**: Setzeus is the founder of StrataLabs, a Bitcoin studio that consults L1 & L2s (such as Stacks) / launched a Bitcoin development environment (BitScript). Through his work at TrustMachines he's been hacking away on sBTC & is eager to continue contributing to the Stacks community in anyway. 35 | 36 | **Vlad**: CTO and co-founder of multiple Stacks and Bitcoin based projects, including Asigna, STX20, and sOrdinals. Contributor to the multisig SIP and its implementation, as well as to the Stacks ecosystem opensource projects. 37 | 38 | ## About this CAB 39 | 40 | The technical CAB reviews SIPs related to technical implementations to the blockchain, including consensus-breaking changes. SIPs that are technical in nature and must be vetted by users with the relevant technical expertise belong in this SIP track. 41 | 42 | ## Considerations 43 | 44 | ### In-scope 45 | 46 | The following items would be considered in-scope for this CAB: 47 | 48 | 1. Changes to Clarity syntax and semantics 49 | 2. Changes to Clarity functions or keywords 50 | 3. Changes to the Stacks blockchain’s consensus mechanisms 51 | 4. Changes to the Stacks blockchain’s wire formats 52 | 5. Changes to the networking protocols in the Stacks blockchain 53 | 6. Proposed standards for Clarity contracts 54 | 55 | ### Out-of-scope 56 | 57 | The following items would be considered out-of-scope for this CAB: 58 | 59 | 1. Changes to the consensus protocol that are strictly limited to financial or economic considerations 60 | 61 | ### Questions for SIP Review 62 | 63 | 1. Are there any consensus consequences for the proposal? If so, what are they? 64 | 2. What components of the network are impacted? 65 | 3. What are the activation requirements? Can non-technical users participate in activation? 66 | 67 | _Note: above considerations subject to changes and iterations from ongoing lessons learned_ 68 | 69 | ## Process 70 | 71 | The Technical CAB can ask the SIP author(s) to present their proposal. The recommendation of the CAB is made by simple majority vote by CAB members. A minimum of 50% of CAB members must participate in the vote for a recommendation to be made to the Steering Committee. 72 | 73 | Results of votes and associated minutes (if any) are recorded [under considerations/minutes](https://github.com/stacksgov/sips/tree/main/considerations/minutes/technical-cab). 74 | 75 | The minutes include any discussion topics that came up about the SIP. Also, whenever there are opposing votes, those members have the opportunity to write a dissenting opinion which will be included in the minutes. 76 | 77 | ## Bylaws 78 | 79 | We choose to adopt the bylaws Steering Committee member @jcnelson set out in this doc: https://gist.github.com/jcnelson/3fcc635ede20ce98d1eae60941eb127a 80 | 81 | Starting from those bylaws, this CAB will continue to evaluate what works, what doesn't work, and use the feedback and lessons learned to improve the process and increase involvement along the way. 82 | 83 | --- 84 | 85 | _If this CAB interests you and you wish to join the effort, please reach out to @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 86 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Stacks Improvement Proposals (SIPs) 2 | 3 | The SIPs describe the design, implementation, and governance 4 | of the Stacks 2.0 blockchain. The SIP process 5 | ([SIP-000](./sips/sip-000/sip-000-stacks-improvement-proposal-process.md)) 6 | describes how to make a SIP and get it ratified. Anyone in the Stacks community 7 | may submit a SIP. 8 | 9 | ## SIPs in the Process of Being Activated 10 | 11 | * None 12 | 13 | ## Ratified SIPs 14 | 15 | * [SIP-000](./sips/sip-000/sip-000-stacks-improvement-proposal-process.md): The 16 | Stacks Improvement Proposal Process 17 | * [SIP-001](./sips/sip-001/sip-001-burn-election.md): Burn Election 18 | * [SIP-002](./sips/sip-002/sip-002-smart-contract-language.md): The Clarity 19 | Smart Contract Language 20 | * [SIP-003](./sips/sip-003/sip-003-peer-network.md): Stacks P2P Network 21 | * [SIP-004](./sips/sip-004/sip-004-materialized-view.md): Cryptographic 22 | Commitment to Materialized Views 23 | * [SIP-005](./sips/sip-005/sip-005-blocks-and-transactions.md): Blocks, 24 | Transactions, and Accounts 25 | * [SIP-006](./sips/sip-006/sip-006-runtime-cost-assessment.md): Clarity Cost 26 | Execution Assessment 27 | * [SIP-007](./sips/sip-007/sip-007-stacking-consensus.md): Stacking Consensus 28 | * [SIP-008](./sips/sip-008/sip-008-analysis-cost-assessment.md): Clarity Parsing 29 | and Analysis Cost Assessment 30 | * [SIP-009](./sips/sip-009/sip-009-nft-standard.md): Standard Trait Definition 31 | for Non-Fungible Tokens 32 | * [SIP-010](./sips/sip-010/sip-010-fungible-token-standard.md): Standard Trait Definition for Fungible Tokens 33 | * [SIP-012](./sips/sip-012/sip-012-cost-limits-network-upgrade.md): Burn Height Selection for a Network Upgrade to Introduce New Cost-Limits 34 | * [SIP-013](./sips/sip-013/sip-013-semi-fungible-token-standard.md): Standard Trait Definition for Semi-Fungible Tokens 35 | * [SIP-015](./sips/sip-015/sip-015-network-upgrade.md): Stacks Upgrade of Proof-of-Transfer and Clarity 36 | * [SIP-016](./sips/sip-016/sip-016-token-metadata.md): Metadata for Tokens 37 | * [SIP-018](./sips/sip-018/sip-018-signed-structured-data.md): Signed Structured Data 38 | * [SIP-019](./sips/sip-019/sip-019-token-metadata-update-notifications.md): Notifications for Token Metadata Updates 39 | * [SIP-020](./sips/sip-020/sip-020-bitwise-ops.md): Bitwise Operations in Clarity 40 | * [SIP-021](./sips/sip-021/sip-021-nakamoto.md): Nakamoto: Fast and Reliable Blocks through PoX-assisted Block Propagation 41 | * [SIP-022](./sips/sip-022/sip-022-emergency-pox-fix.md): Emergency Fix to PoX Stacking Increases 42 | * [SIP-023](./sips/sip-023/sip-023-emergency-fix-traits.md): Emergency Fix to Trait Invocation Behavior 43 | * [SIP-024](./sips/sip-024/sip-024-least-supertype-fix.md): Emergency Fix to Data Validation and Serialization Behavior 44 | * [SIP-025](./sips/sip-025/sip-025-iterating-towards-weighted-schnorr-threshold-signatures.md): Iterating Towards WSTS 45 | * [SIP-027](./sips/sip-027/sip-027-non-sequential-multisig-transactions.md): Non-sequential Multisig Transactions 46 | * [SIP-028](./sips/sip-028/sip-028-sbtc_peg.md): Signer Criteria for sBTC, A Decentralized and Programmable Asset Backed 1:1 with BTC 47 | * [SIP-029](./sips/sip-029/sip-029-halving-alignment.md): Bootstrapping sBTC Liquidity and Nakamoto Signer Incentives 48 | * [SIP-031](./sips/sip-031/sip-031.md): Five-Year Stacks Growth Emissions 49 | 50 | ## How to Get Involved 51 | 52 | There are several ways you can get involved with the SIP process: 53 | 54 | * **SIP Editor**. SIP editors help SIP authors make sure their SIPs are 55 | well-formed and follow the right process. They help get SIPs ready for deep 56 | review by advancing it them from Draft to Accepted status. If you want to become a SIP editor, 57 | open an issue with your name and email to ask to be added to the list of SIP editors. 58 | 59 | * **Joining a Consideration Advisory Board**. SIPs fall under the purview of 60 | one or more considerations, such as "technical," "economic," "governance," 61 | and so on. A full list is in the `considerations/` directory. Members of SIP 62 | consideration advisory boards use their domain expertise to give Accepted SIPs a 63 | deep read, and give the authors any/all feedback to help make the SIP workable. 64 | If you want to join a board, reach out to the board's chairperson via the 65 | listed contact information. 66 | 67 | * **Creating a Consideration Advisory Board**. Anyone can create a 68 | consideration advisory board by opening a PR to create a new 69 | consideration track, and SIP authors can opt to have you review their work by 70 | adding your consideration to the SIP's list of considerations. You are expected 71 | to vote on such SIPs in a fair and timely manner if you start a board. 72 | 73 | * **Steering Committee**. The Steering Committee organizes the consideration 74 | advisory boards and votes to advance Recommended SIPs to 75 | Activation-in-Progress status, and then to either Ratified or Rejected status. 76 | Once they are in the process of being activated, 77 | they use a SIP's Activation section to determine whether or not the Stacks 78 | ecosystem has ratified or rejected the SIP. Joining this committee requires the 79 | consent of the Stacks Foundation board. 80 | -------------------------------------------------------------------------------- /sips/sip-031/summary_of_benefits.md: -------------------------------------------------------------------------------- 1 | # Summary of Expected Benefits for SIP-31 2 | 3 | The activation of SIP-31 is expected to benefit various groups in the following ways 4 | 5 | ### Builders 6 | 7 | * Dedicated funding for growth, user acquisition 8 | * Increased marketing support for Stacks ecosystem 9 | * More ecosystem funds for broadly beneficial integrations, like bridges, oracles, stablecoins, etc. 10 | * Dedicated grants for core protocol, apps, tooling, and infrastructure development. 11 | * Access to liquidity support for early-stage Stacks-based projects 12 | * Direct incentives for user acquisition and application growth (e.g., TVL programs) 13 | * Marketing and branding resources to help amplify applications 14 | * Technical assistance and subsidized audits or security services 15 | * Faster go-to-market enablement via ecosystem-wide BizDev and GTM teams. 16 | * Predictable and open access to proposal funding via the Treasury Committee. 17 | * Confidence that Stacks is positioned to compete with top ecosystems 18 | * Higher velocity of Stacks network improvements, functionality, and releases 19 | 20 | ### Holders / Investors 21 | 22 | * Clear market signaling and transparency from forward-looking STX allocation schedules. 23 | * Improved STX market liquidity and dynamics via increased capital markets support. 24 | * Robust treasury management programs 25 | * Increased project visibility and activity, driving ecosystem growth, demand, and network functionality for STX. 26 | * Dedicated sBTC and DeFi growth efforts create new demand drivers for Stacks 27 | * Expanded developer ecosystem increases long-term value accrual potential 28 | * Predictable inflation schedule with consolidated dilution, aligned across contributors. 29 | * Puts Stacks resources more in line with other top ecosystems \- examples like Uniswap, Optimism, and Arbitrum have shown that treasuries can drive significant value. 30 | 31 | ### Users 32 | 33 | * Faster access to quality apps and DeFi protocols boasting deep liquidity 34 | * Lower onboarding friction via stablecoins, bridges, and fiat onramps. 35 | * More robust education, learn-and-earn, and UX enhancements driven by dedicated funding. 36 | * Greater network security, performance, and features through continuous core investment. 37 | * Global marketing and KOL campaigns that bring in new users and increase liquidity. 38 | * Community-aligned incentives (e.g., LP rewards, yield campaigns) directly benefit users. 39 | * New integrations that make Stacks-based products more widely available 40 | 41 | ### Key Contributors 42 | 43 | * Streamlined structure that frees the most impactful contributors to contribute to a wider scope for the project. 44 | * Eliminates structural blockers tied to legacy compliance burdens. 45 | * Consolidated ops (custody, reporting, legal) reduce overhead and friction for core teams. 46 | * Unlocks participation in marketing, token incentives, and integrations. 47 | * Freedom to focus on execution 48 | * Clarity on scope and roles across new operational entity, the Stacks Foundation, and the Stacks Endowment. 49 | * Ability to scale faster thanks to larger and more predictable budget flows. 50 | * Stronger accountability and feedback loops via SIP-driven funding renewals. 51 | * More talent attraction and retention with access to funding, stability, and runway. 52 | * Strategic resource coordination across contributors (e.g., global GTM team, sBTC rollout). 53 | * Examples like the Optimism Foundation show how consolidated treasuries empower execution. 54 | 55 | ### Key Partners (Exchanges, Custodians, Oracles, Wallets, and Other Infra Participants) 56 | 57 | * Clear points of contact thanks to consolidation for execution and technical operations. 58 | * Faster integration timelines due to a unified core team responsible for protocol upgrades, support, and testing. 59 | * Improved reliability and confidence in roadmap delivery via public commitments and long-term funding. 60 | * Dedicated support for integrations (e.g., funding for dev time, audits, or infrastructure deployment). 61 | * Expanded market activity from treasury-backed growth campaigns (e.g., new STX/sBTC listings, liquidity incentives). 62 | * Lower organizational complexity when negotiating integration, marketing, or technical agreements. 63 | * Active liquidity and incentive support to boost usage post-integration (especially valuable for exchanges and wallets). 64 | * Stronger long-term alignment between infrastructure partners and ecosystem growth priorities. 65 | * Greater brand lift as Stacks expands visibility and market cap, helping partners benefit from being early or core participants. 66 | 67 | ### Casual Holders 68 | 69 | * Clear understanding of who does what in the ecosystem and where/how to get involved 70 | * Increased token utility and use cases resulting in a stronger, more valuable ecosystem. 71 | * Higher visibility of Stacks through global marketing and product announcements. 72 | * Predictable emissions and inflation are aligned with long-term growth. 73 | * Confidence that the ecosystem is addressing past inefficiencies and growing responsibly. 74 | * Improved app and protocol quality through funded security, liquidity, and dev support. 75 | * Trust in long-term alignment from professional treasury operations and public reporting. -------------------------------------------------------------------------------- /sips/sip-024/sip-024-least-supertype-fix.md: -------------------------------------------------------------------------------- 1 | # Preamble 2 | 3 | SIP Number: 024 4 | 5 | Title: Emergency Fix to Data Validation and Serialization Behavior 6 | 7 | Authors: 8 | Aaron Blankstein , 9 | Brice Dobry , 10 | Jude Nelson , 11 | Pavitthra Pandurangan , 12 | 13 | Consideration: Technical, Governance 14 | 15 | Type: Consensus 16 | 17 | Status: Ratified 18 | 19 | Created: 11 May 2023 20 | 21 | License: BSD 2-Clause 22 | 23 | Sign-off: Jason Schrader (Governance CAB Chair), Brice Dobry (Technical CAB Chair), Jude Nelson (Steering Committee Chair) 24 | 25 | Discussions-To: https://github.com/stacksgov/sips 26 | 27 | # Abstract 28 | 29 | On 8 May 2023, a critical Denial-of-Service vulnerability manifested 30 | in the Stacks network. While the initial DoS threat was remedied 31 | through a non-consensus breaking hotfix, the underlying bug that 32 | triggered the vulnerability requires consensus changes to fix. 33 | This underlying bug has existed in the Stacks blockchain implementation 34 | since the launch of Stacks 2.0, and has the potential to impact the 35 | functionality of contracts even if they do not currently rely on the 36 | buggy behavior. 37 | 38 | This SIP proposes a **consensus-breaking change** to be included in 39 | the SIP-022 hardfork (Epoch 2.4) to remediate this negative impact. 40 | 41 | # Introduction 42 | 43 | Stacks 2.0 allows contracts to include tuple types with _extra_ fields 44 | to be included in lists with tuples with fewer fields: 45 | 46 | ```clarity 47 | (list (tuple (a 1)) (tuple (b 1) (a 1))) 48 | ``` 49 | 50 | The Clarity runtime will treat each item of this list as if it only 51 | had the field `a`, which creates an issue for the database on reads and writes. 52 | On database reads, the Clarity database checks if the found type 53 | matches the expected type, and discovers a mismatch. This mismatch 54 | led to a DoS on 8 May 2023, and was fixed by converting the node 55 | crash into a transaction invalidation. 56 | 57 | However, transaction invalidation is _not_ sufficient as a long-term 58 | solution due to the following: 59 | 60 | 1. Miners must be able to charge for these kinds of failures 61 | 2. Contracts which do not directly rely on this behavior could still 62 | receive buggy values because of the behavior (which could lead to storage failures). 63 | 64 | # Specification 65 | 66 | The proposed changes to the Epoch 2.4 hard fork will do the following: 67 | 68 | * Add a value sanitization routine which eliminates any of these extra 69 | fields from the in-memory representation of a Clarity value. 70 | * Invoke the sanitization routine on contract-call arguments and 71 | return values. 72 | * Invoke the sanitization routine on database reads. 73 | * Invoke the sanitization routine during Clarity value constructors 74 | which relied on the buggy type check behavior. 75 | 76 | This will preserve the existing type system behavior, but it will ensure 77 | that values constructed this way _match_ the expected type. 78 | 79 | # Related work 80 | The Stacks network has precedent for fixing consensus bugs through hard forks, some being released on 81 | short timelines. 82 | 83 | Other blockchains have also detected and fixed consensus critical bugs quickly. A prominent example of 84 | this happened on Bitcoin, which had a bug that would allow the minting of an arbitrary amount of BTC 85 | above the 21 million cap. A patched version was quickly released, and the network upgraded in a 86 | matter of hours. 87 | 88 | # Backwards Compatibility 89 | Everyone who runs a 2.3 node will be able to run a Stacks 2.4 node 90 | off of their existing chainstate. There are no changes to the chainstate database schemas in this SIP. 91 | 92 | Stacks 2.4 nodes will not interact with Stacks 2.3 nodes on the peer network (defined in SIP-022) 93 | after the Bitcoin block activation height of `791551`. In addition, Stacks 2.4 nodes 94 | will ignore block-commits from Stacks 2.3 nodes (as well as from nodes on prior versions). 95 | Similar changes were made for Stacks 2.05 and Stacks 2.1 to ensure that the new network 96 | cleanly separates from stragglers still following the old rules. 97 | 98 | # Activation 99 | The changes described in this SIP will ship in the same release as the changes described in SIP-022, which discusses 100 | and proposes a fix to the proof of transfer protocol. 101 | 102 | This release will ship 500 blocks prior to reward cycle 60, which is Bitcoin block height 791,551. 103 | This gives stackers ample time (~3 days) to stack through the new contract. 104 | 105 | The node software for Stacks 2.4 shall be merged to the `master` branch of the 106 | reference implementation no later than four days prior to the activation 107 | height. This means that everyone shall have at least three days to upgrade 108 | their Stacks 2.3 nodes to Stacks 2.4. This change does not require a sync from genesis. 109 | 110 | # Reference Implementation 111 | The reference implementation of this SIP can be found in the 112 | `feat/epoch-2.4-sanitize` branch of the Stacks blockchain reference implementation. It is available at 113 | https://github.com/stacks-network/stacks-blockchain. 114 | -------------------------------------------------------------------------------- /considerations/minutes/governance-cab/2023-04-20-sip-022.md: -------------------------------------------------------------------------------- 1 | # Governance CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - April 20, 2023 12 | - April 26, 2023 13 | 14 | **Time:** n/a 15 | 16 | **Attendees:** 17 | 18 | - Jason Schrader 19 | - Harold Davis 20 | - Zero.btc 21 | - Orlando Cosme 22 | - Juliet Oberding 23 | 24 | **Topic(s):** 25 | 26 | - [SIP-022: Emergency Fix to PoX Stacking Increase](https://github.com/stacksgov/sips/pull/127) 27 | 28 | **Materials**: 29 | 30 | - [SIP - Catastrophic blockchain failures and recovery](https://github.com/stacksgov/sips/pull/10) 31 | - [Stacks Forum: A bug in stacks-increase call is impacting Stacking rewards this cycle](https://forum.stacks.org/t/a-bug-in-stacks-increase-call-is-impacting-stacking-rewards-this-cycle/14867) 32 | 33 | ## 2023-04-21 Meeting Notes 34 | 35 | The governance CAB discussed SIP-022 and the supporting materials, and concluded that the SIP should be approved given the following: 36 | 37 | - the bug could cause a catastrophic failure of the Stacks blockchain 38 | - swift action is necessary to prevent the crash from happening 39 | - conducting a vote would delay the hard fork and increase the risk of failure 40 | 41 | Quoting from the draft SIP discussing [catastrophic blockchain failures and recovery](https://github.com/stacksgov/sips/blob/feat/sip011-catastrophic-failure-recovery/sips/sip-011/sip-011-catastrophic-failure-recovery.md#changing-existing-network-messages): 42 | 43 | > If the catastrophic failure can only be remedied by changing the way nodes handle an existing message, such that the change renders the node incompatible with the network (i.e. unable to effectively participate in block synchronization, relaying, and/or mining), then the bugfix will require rolling out two concurrent versions of the network that share the same chainstate for a time in order to allow people running old nodes a chance to upgrade. The deadline to upgrade (and the deadline at which the old, buggy code-paths will cease to be supported) will be enforced programmatically by new nodes, and will be measured in burnchain block heights. 44 | 45 | The proposed fix satisfies the requirements above by taking the following actions: 46 | 47 | - disable `stack-increase` for solo stackers 48 | - reset the `total-ustx` values in the `reward-cycle-pox-address-list` used to track solo stackers 49 | - set flags so the new network cannot interact with the old network, creating a clean break in chainstate 50 | - allowing for the existing Stacks 2.1 chainstate to be used in migration to Stacks 2.2 51 | - setting a burnchain (Bitcoin) block height for activation of the hard fork 52 | 53 | ## 2023-04-26 Meeting Notes 54 | 55 | Since our last meeting SIP-022 underwent several changes, summarized [in this post by Jude](https://github.com/stacksgov/sips/pull/127#issuecomment-1522230851) quoted below: 56 | 57 | > Hey everyone, the text of this SIP has changed substantially. In line with the public calls we've had about this, this SIP now proposes two hard forks -- one to disable PoX in cycle #58, and one to re-enable it via instantiating a fixed pox-3 contract in cycle #59. @whoabuddy @obycode I think your respective CABs will need to re-review this before we can advance it to Recommended. 58 | 59 | In consideration of the changes, the governance CAB discussed the following: 60 | 61 | - comments and feedback on the [SIP pull request](https://github.com/stacksgov/sips/pull/127) 62 | - comments and feedback on the [implementation of the first hard fork](https://github.com/stacks-network/stacks-blockchain/pull/3677) 63 | - updates, comments, and feedback on the [forum post on the bug](https://forum.stacks.org/t/a-bug-in-stacks-increase-call-is-impacting-stacking-rewards-this-cycle/14867) 64 | - [swimming in two pools, by Friedger](https://app.sigle.io/friedger.id/5zj_niUL0z0qBEl9HO2Ac) 65 | 66 | The governance CAB concluded that the first hard fork to disable pox-2 should be approved standing by the same reasons outlined last week: 67 | 68 | - the bug could cause a catastrophic failure of the Stacks blockchain 69 | - swift action is necessary to prevent the crash from happening 70 | - conducting a vote would delay the hard fork and increase the risk of failure 71 | - all STX will be unlocked until the new PoX implementation is ready 72 | 73 | The governance CAB also concluded that the second hard fork to enable pox-3 should be approved based on the following: 74 | 75 | - without PoX, Stackers cannot use stacked STX as a voting signal 76 | - PoX is a core function of the Stacks blockchain that should be restored 77 | - enabling PoX quickly allows the chain to return to normal operation for users 78 | - correcting and adding more delegation data will help stacking service providers 79 | 80 | ## Vote Outcome(s) 81 | 82 | Votes below reflect the original decisions made on 2023/04/21, as well as a vote for the first and second hard fork on 2023/04/26. 83 | 84 | | Name | Vote 4/21 | Vote 4/26 | 85 | | --------------- | --------- | --------- | 86 | | Jason Schrader | yes | yes / yes | 87 | | Harold Davis | yes | yes / yes | 88 | | Zero Authority | yes | abs / abs | 89 | | Orlando Cosme | yes | yes / yes | 90 | | Juliet Oberding | yes | yes / yes | 91 | 92 | The Governance CAB approves SIP-022 with 4 yes votes on both hard forks. 93 | -------------------------------------------------------------------------------- /considerations/economics.md: -------------------------------------------------------------------------------- 1 | # Consideration for Economics SIPs 2 | 3 | Chairperson: MattySTX 4 | 5 | Members: 6 | 7 | - Hadan Esperidiao 8 | - Leeor Shimron 9 | - MattySTX 10 | - Pieter Aerts 11 | - Xan Ditkoff 12 | 13 | Discussions-to: https://github.com/stacksgov/sips 14 | 15 | Created-by: SIP-000 16 | 17 | ## Biographies 18 | 19 | **Hadan Esperidiao**: Hadan Esperidiao is the BD Lead for the ALEX Lab Foundation. ALEX is the Bitcoin finance layer, seamlessly merging L1 assets with L2s capabilities and omni-chain bridging. Hadan has been with ALEX Lab for the three years; prior experience include fixed income trading at Goldman Sachs and Physics at Harvard. 20 | 21 | **Leeor Shimron**: Leeor Shimron is Head of Growth at Stacking DAO, a leading Stacks DeFi platform, and a Senior Contributor at Forbes covering crypto and blockchain. Since 2017, Leeor has held roles across business development, strategy, and partnerships at dRPC, Kraken, Fundstrat, and as Founder/CEO of NovaBlock Capital, a digital asset venture firm. 22 | 23 | **MattySTX (Chairperson)**: Matty has more than a decade of experience designing, simulating, and optimizing economic models for hedge funds and VC funded machine learning startups. He has been in crypto since 2015, and Stacks since 2017. In the Stacks ecosystem, his simulation analysis of Stacks’ economic model has helped evaluate PoX consensus mechanism improvements, he authored the first ever community contributed governance proposal for Arkadiko’s tokenomics, he publishes the quarterly ‘STX Mining Report’, and he mentors teams at the Stacks incubator. 24 | 25 | **Pieter Aerts**: Pieter is a computer scientist and core contributor at Arkadiko Finance. The birth of Decentralized Finance at the start of 2020 is what made Pieter rediscover the cryptocurrency space. Excited by the possibilities of DeFi, he came to Stacks to bootstrap a DeFi revolution by contributing to Arkadiko, an important building block on the road to a financial ecosystem on Stacks and Bitcoin. 26 | 27 | **Xan Ditkoff**: Xan became part of the Stack’s ecosystem in 2017 as an early core team member focused on growing the developer ecosystem. He now runs Daemon Technologies, a Hong Kong based company focused on community growth, project funding, and partnerships for Stack’s technology primarily in Asia. 28 | 29 | ## About this CAB 30 | 31 | The economics CAB reviews SIPs related to the blockchain's token economics. This not only includes the STX token, but also any on-chain tokens created within smart contracts. SIPs that are concerned with fundraising methods, grants, bounties, and so on also belong in this SIP track. 32 | 33 | ## Considerations 34 | 35 | ### In-scope 36 | 37 | The following items would be considered in-scope for this CAB: 38 | 39 | 1. Changes to the tokenomics of Stacks or the STX token itself 40 | 2. Changes to Stacks’ consensus mechanism - particularly with regard to the impact on miners and stackers 41 | 3. The economic impacts, and risks of economic impacts, that changes to the Stacks protocol would have on any and all parties in the Stacks ecosystem 42 | 4. The economic soundness and viability of proposed standards for fungible or non-fungible tokens issued on STX 43 | 5. Changes that put the existing economy on the Stacks chain at risk, or which may grow/shrink Stacks’ overall economic utility and activity 44 | 6. Any economic impact or risk to native Bitcoin due to Stacks’ activity 45 | 46 | ### Out-of-scope 47 | 48 | The following items would be considered out-of-scope for this CAB: 49 | 50 | 1. The security of the Stacks network itself, beyond the economic risks and impacts of its ongoing security 51 | 2. The particular tokenomics of any given project launching on Stacks 52 | 3. The technical or implementation-level aspects of changes to the tokenomics of Stacks, the STX token itself, or Stack’s consensus mechanism (though any relative economic differences in technical approaches would be in-scope for this CAB) 53 | 4. Improvements to the speed, performance, up-time, or other functioning of the Stacks network itself, other than any economic impacts or risks created by these changes 54 | 55 | ### Questions for SIP Review 56 | 57 | Questions to facilitate SIP review: 58 | 59 | 1. Which stakeholders are expected to be economically impacted, or at-risk of being economically impacted, by this SIP (ex. miners, stackers, STX holders, STX users, founders/builders, etc)? 60 | 2. What are the expected economic impacts to each of these stakeholders? 61 | 3. What are the economic and non-economic risks to each of these stakeholders? 62 | 4. Do the expected economic benefits outweigh the economic and non-economic risks for each of these stakeholders? 63 | 5. If one stakeholder would economically benefit at the expense of another stakeholder (for example increase profit to miners at cost of reducing yield to stackers), what is the expected overall economic net impact to Stacks and the Stacks ecosystem? 64 | 65 | _Note: above considerations subject to changes and iterations from ongoing lessons learned_ 66 | 67 | ## Bylaws 68 | 69 | We choose to adopt the bylaws Steering Committee member @jcnelson set out in this doc: https://gist.github.com/jcnelson/3fcc635ede20ce98d1eae60941eb127a 70 | 71 | Starting from those bylaws, this CAB will continue to evaluate what works, what doesn't work, and use the feedback and lessons learned to improve the process and increase involvement along the way. 72 | 73 | --- 74 | 75 | _If this CAB interests you and you wish to join the effort, please reach out to @jennymith and @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 76 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2022-11-02-sip-015.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord 6 | 7 | **Recorded:** No 8 | 9 | **Date:** October 31, 2022 10 | 11 | **Time:** Asynchronous 12 | 13 | **Attendees:** 14 | 15 | - Aaron Blankstein 16 | - Brice Dobry 17 | - Dan Trevino 18 | - Daniel Fritsche 19 | - Jamil Dhanani 20 | - Jesse Wiley 21 | - Mike Cohen 22 | - Terje Norderhaug 23 | - Thomas Osmonson 24 | 25 | **Topic(s):** 26 | 27 | - Vote on SIP-015 acceptance 28 | 29 | **Materials**: 30 | 31 | - [SIP-015 Proposal](https://github.com/stacksgov/sips/blob/feat/sip-015/sips/sip-015/sip-015-network-upgrade.md) 32 | 33 | ## Meeting Notes 34 | 35 | - As discussed in our [last meeting](2022-10-27.md), SIP-015 voting was opened 36 | at 11:00 UTC and closed at 21:00 UTC, using Discord reactions within our group 37 | chat 38 | - Discussed wanting to include a writeup along with the decision 39 | - Concern voiced about SIP authors voting on the SIP 40 | - Quorum is met and SIP is approved whether we include the authors or not (5 41 | yes, 1 no out of 8 including authors or 3 yes, 1 no out of 6 excluding 42 | authors) 43 | - To follow up on establishing a rule for this in the future (discuss with 44 | governance CAB?) 45 | - [Official approval added to the PR](https://github.com/stacksgov/sips/pull/95#pullrequestreview-1165435756) 46 | on 2 Nov 2022, including discussed caveats and dissenting opinion 47 | 48 | - Content of the approval: As the chairperson of the Technical CAB, this 49 | approval indicates official approval of this SIP by the Technical CAB. 50 | 51 | This approval comes with the caveat that the Technical CAB would like to see 52 | smaller SIPs that include only related changes in the future. For example, 53 | the changes to Clarity are completely unrelated to the changes in PoX. This 54 | large of a SIP is much riskier to implement all at once, and makes voting 55 | based on individual aspects of the changes much more difficult. We have 56 | decided to ignore that concern due to the circumstances surrounding SIP-015 57 | -- that it is the first to be formally reviewed by this CAB, that it has 58 | already been implemented, that it has strong support from the community to 59 | be released as soon as possible -- but this CAB may reject SIPs in the 60 | future that have this problem. 61 | 62 | The dissenting members of the CAB would like to share the following 63 | opinions: 64 | 65 | > The SIP should be re-submitted after factoring out changes to Clarity into 66 | > a separate SIP. This will allow core Stacks 2.1 improvements such as 67 | > stacking experience and block validation to be independently tested on 68 | > mainnet, so bugs in the core can be fixed before deploying the upgraded 69 | > Clarity VM. It will also give the community an opportunity to properly 70 | > consider the proposed changes to Clarity. 71 | > 72 | > I have a major concern with the run-away accidental complexity which will 73 | > follow from the technical architecture suggested in SIP-015. Unnecessary 74 | > complexity inherently increases the risk for bugs and malfunction. The new 75 | > Clarity version scheme combined with reserving the names of all native 76 | > functions will lead to an ever branching complex implementation. Per the 77 | > SIP "adding, changing, or removing a native Clarity function or native 78 | > Clarity global variable necessitates the creation of a new version of the 79 | > Clarity language, and must be treated as a breaking change." As a 80 | > consequence, there will be lots of incompatible Clarity versions to 81 | > juggle, or big-bang releases, or slow progress in native functions, or a 82 | > combination of these. Another concern is that with SIP-015 traits aren't 83 | > forward compatible: a trait defined in one version of Clarity may not be 84 | > possible to implement in a later version. For example, say a Clarity-1 85 | > contract defines a trait with a function slice: 86 | > 87 | > ``` 88 | > (define-trait my-trait 89 | > ((slice ((list 9 int) (offset int) (length int)) 90 | > (list 9 int)))) 91 | > ``` 92 | > 93 | > As slice is a native function in Clarity-2, the trait can only be 94 | > implemented in Clarity-1 contracts. Worse, the trait may not even be 95 | > possible to implement and deploy in future releases of the Stacks 96 | > blockchain. Per SIP-015: a future SIP may remove the ability to publish 97 | > new smart contracts with older versions of Clarity. 98 | > https://github.com/stacksgov/sips/pull/95#discussion_r1008931985 As 99 | > example, the compatibility issue with traits affects SIP-009 and SIP-010, 100 | > which defines traits for tokens. There will be a conflict if a future 101 | > version of Clarity introduces a native function with the same name as the 102 | > functions of these traits. For example, if a future version of Clarity 103 | > introduces a native function called transfer then SIP-009 or SIP-010 104 | > compliant smart contract cannot be implemented in this or later versions 105 | > of Clarity. 106 | 107 | ## Action Items 108 | 109 | - [ ] Discuss conflict of interest resolution when SIP author is also in a CAB 110 | voting on the SIP, with Governance CAB, and define the rules for this in 111 | the bylaws. 112 | 113 | ## Vote Outcome(s) 114 | 115 | - Aaron Blankstein: no response 116 | - Brice Dobry: yes 117 | - Dan Trevino: yes 118 | - Daniel Fritsche: yes 119 | - Jamil Dhanani: no response (yes after deadline) 120 | - Jesse Wiley: yes 121 | - Mike Cohen: abstain 122 | - Terje Norderhaug: no 123 | - Thomas Osmonson: yes 124 | 125 | With this vote, the turnout, the quorum and majority requirements previously set 126 | were met and SIP-015 is approved. 127 | -------------------------------------------------------------------------------- /considerations/governance.md: -------------------------------------------------------------------------------- 1 | # Consideration for Governance SIPs 2 | 3 | Chairperson: Jason Schrader 4 | 5 | Members: 6 | 7 | - Harold Davis 8 | - Juliet Oberding 9 | - Orlando Cosme 10 | - Zero.btc 11 | - Stephen Perrino (PeaceLoveMusic.btc) 12 | - Jason Schrader 13 | 14 | Discussions-to: https://github.com/stacksgov/sips 15 | 16 | Created-by: SIP-000 17 | 18 | ## Biographies 19 | 20 | **Harold Davis**: Started in the Blockstack ecosystem back in 2016. Became very involved with governance in 2020 with the governance working group. Established a governance residency focused on R+D of gov tooling for the Stacks Advocates & ecosystem. Specifically focused on distributed power for long term sustainability. 21 | 22 | **Juliet Oberding**: Juliet is a long time member of the Stacks community. She participated in App Mining, was an original member of the Governance working group, developed the Stacks Code of Conduct and was a resident with the Stacks Gov Lab. Her background is as a lawyer, law professor and founder of a digital health startup. Juliet is currently the founder of Lexy Lab, a startup focused on governance research. 23 | 24 | **Orlando Cosme**: Orlando first got involved in Stacks when mainnet launched. He is the co-founder & CEO of StackerDAO Labs, a startup that develops infrastructure and tools to create and manage DAOs on Stacks. He is also a lawyer and had stints as a startup/VC corporate lawyer and a securities and government enforcement litigator. Through StackerDAOs and as an attorney, he has developed both on-chain, decentralized governance structures, as well as traditional corporate governance structures. He has also worked on corporate governance disputes. 25 | 26 | **Zero.btc**: Zero has been involved with the Stacks community since the BlockStack days and he learned about Stacks during the regulated ICO. He is the co-founder of Zero Authority DAO, and he and his co-founder Hodlstx created the Cerulean Marketplace for creators and builders to offer a service and for people to pay for Web3 gigs in a trustless and permissionless way. Being a part of the governance CAB is an honor and he has spent lots of time working on governance for the DAO they have built. 27 | 28 | **Stephen Perrino (PeaceLoveMusic.btc)**: A father of seven, Realtor, and servant on my local and state government affairs committee. I strongly advocate for consent-based, permissionless exchange, decentralized networks, and the right to transact, and I’ve been a Stacks holder since early 2023 (starting with the Hiro wallet before it became Leather). The prospect of smart contracts on Bitcoin initially drew me in, and the ethos and people I’ve encountered have kept me captivated. My goal is to help shape a new paradigm where decentralized, trustless, and borderless exchange—grounded in immutability and censorship resistance—offers a better way to organize society with a focus on consent, and I see Stacks as a key part of this vision. 29 | 30 | **Jason Schrader (Chairperson)**: Stacks community member since 2019, engineer at Freehold and a core developer of the CityCoins protocol. Participated in the formation of the Stacks Governance Working Group and helps with research, tooling, and project management. An open source advocate and teacher at heart - we're all learning together! 31 | 32 | ## About this CAB 33 | 34 | The governance CAB concerns the governance of the Stacks blockchain, including the SIP process. This includes amendments to the SIP Ratification Process, as well as structural considerations such as the creation (or removal) of various committees, editorial bodies, and formally recognized special interest groups. In addition, governance SIPs may propose changes to the way by which committee members are selected. 35 | 36 | ## Considerations 37 | 38 | ### In-scope 39 | 40 | The following items would be considered in-scope for this CAB: 41 | 42 | 1. changes to the SIP process 43 | 2. changes to the way we represent blockchain stakeholders 44 | 3. changes to the code of conduct 45 | 4. changes to the way we organize Stacks chapters 46 | 5. changes to voting/decision making processes 47 | 6. changes to community representative to board 48 | 7. changes that impact community members 49 | 8. changes that impact all STX holders/investors 50 | 51 | ### Out-of-scope 52 | 53 | The following items would be considered out-of-scope for this CAB: 54 | 55 | 1. The security of the Stacks network itself, beyond the governance risks and impacts of its ongoing security. 56 | 2. The particular governance of any given project launching on Stacks 57 | 3. Improvements to the speed, performance, up-time, or other functioning of the Stacks network itself, other than any governance impacts or risks created by these changes 58 | 59 | ### Questions for SIP Review 60 | 61 | Questions to facilitate SIP review: 62 | 63 | 1. Which stakeholders' governance processes are expected to be impacted, or at-risk of being impacted, by this SIP (ex. miners, stackers, STX holders, STX users, STX builders, etc)? 64 | 2. What are the expected governance impacts to each of these parties? 65 | 3. What are the governance and non-governance risks to each of these parties? 66 | 4. Do the expected governance benefits outweigh the governance and non-governance risks for each of these parties? 67 | 5. If one party would benefit in decision making power at the expense of another party (for example increase decision making power to miners at cost of less decision making to stackers), what is the likely overall, net decision making power impact to Stacks and the Stacks ecosystem? 68 | 69 | _Note: above considerations subject to changes and iterations from ongoing lessons learned_ 70 | 71 | ## Bylaws 72 | 73 | We choose to adopt the bylaws Steering Committee member @jcnelson set out in this doc: https://gist.github.com/jcnelson/3fcc635ede20ce98d1eae60941eb127a 74 | 75 | Starting from those bylaws, this CAB will continue to evaluate what works, what doesn't work, and use the feedback and lessons learned to improve the process and increase involvement along the way. 76 | 77 | --- 78 | 79 | _If this CAB interests you and you wish to join the effort, please reach out to @jennymith and @Hero-Gamer or Steering Committee members @jcnelson and @GinaAbrams_ 80 | -------------------------------------------------------------------------------- /considerations/minutes/technical-cab/2025-10-06-sip-033.md: -------------------------------------------------------------------------------- 1 | # Technical CAB Minutes 2 | 3 | ## Meeting Information 4 | 5 | **Location:** Discord (async) 6 | 7 | **Recorded:** No 8 | 9 | **Date:** 10 | 11 | - Oct 6th, 2025 12 | 13 | **Time:** n/a 14 | 15 | **Attendees:** 16 | 17 | - Aaron Blankstein 18 | - Brice Dobry 19 | - j2p2 20 | - Friedger 21 | - Jesse Wiley 22 | - Vlad 23 | - Radu 24 | - Setzeus 25 | 26 | **Topic(s):** 27 | 28 | - [Clarity 4: high-demand new builtins](https://github.com/stacksgov/sips/pull/218) 29 | 30 | **Materials**: 31 | 32 | - [Clarity 4: high-demand new builtins](https://github.com/stacksgov/sips/pull/218) 33 | - https://forum.stacks.org/t/clarity-4-proposal-new-builtins-for-vital-ecosystem-projects/18266 34 | 35 | ## 2025-10-06 Meeting Notes 36 | 37 | The Technical CAB discussed SIP-023 and the supporting materials, and concluded that this hard fork is necessary to support the ecosystem. 38 | 39 | ### Edit 2025-10-13 40 | There was a change to the proposed functions in the SIP after the CAB vote. 41 | 42 | Noted in the chat that this seems more like an implementation detail, with the option to call for a new vote if other CAB members felt one was warranted. 43 | 44 | Sip author shared the full diff, which modified two (2) secp256r1 functions after discovering changes were required during implementation (diff shared below). 45 | 46 | 47 | tl;dr is that no re-vote is required, as no members called for one with the understanding that the changes were required, only affected 2 proposed functions (for secp256r1) and were only discovered during implementation work. 48 | 49 | 50 | From SIP author after the CAB vote: 51 | ``` 52 | I just noticed another small change I'll need to make. it seems that the secp256r1 signatures do not include a recovery byte, so I need to adjust the type sizes to remove that extra byte. Does that sound right? 53 | ``` 54 | 55 | 56 | ``` 57 | I'm going to not just be removing that byte, but removing the -recover? function since it doesn't make sense any more. Here's the patch: 58 | ``` 59 | ```diff 60 | --- a/sips/sip-clarity4/sip-clarity4.md 61 | +++ b/sips/sip-033/sip-clarity4.md 62 | @@ -72,9 +72,8 @@ write secure and composable smart contracts. Specifically, it proposes: 63 | keyword will allow developers to easily access the timestamp of the block 64 | currently being processed, enabling time-based logic and features in their 65 | smart contracts. This is especially important for DeFi applications. 66 | -5. **New secp256r1 signature primitives: `secp256r1-recover?` and 67 | - `secp256r1-verify`.** These functions provide on-chain support for the 68 | - secp256r1 curve, enabling public-key recovery from signatures and signature 69 | +5. **New secp256r1 signature primitive: `secp256r1-verify`.** This function 70 | + provides on-chain support for the secp256r1 curve, enabling signature 71 | verification for applications that use secp256r1-based keys (WebAuthn for 72 | example). 73 | 74 | @@ -457,29 +456,12 @@ that context will result in a runtime error. 75 | 76 | ## Secp256r1 Functions 77 | 78 | -Clarity 4 introduces functions for working with the secp256r1 elliptic curve, 79 | -which is widely used for cryptographic operations. These functions are: 80 | - 81 | -- `secp256r1-recover?` 82 | - 83 | - - **Input**: `(buff 32), (buff 65)` 84 | - - **Output**: `(response (buff 33) uint)` 85 | - - **Signature**: `(secp256r1-recover? message-hash signature)` 86 | - - **Description**: The `secp256r1-recover?` function recovers the public key 87 | - used to sign the message whose SHA-256 hash is `message-hash` using the 88 | - provided `signature`. If the signature does not match the message hash, it 89 | - returns `(err u1)`. If the signature is invalid or malformed, it returns 90 | - `(err u2)`. The signature is expected to be 65 bytes (64 bytes of compact 91 | - signature data plus a recovery id in the final byte). 92 | - - **Example**: 93 | - \`\`\`clarity 94 | - (secp256r1-recover? 0x033510403a646d23ee4f005061c2ca6af5da7c32c83758e8e9b6ac4cc1c2153c 95 | - 0x9608dc164b76d2e19365ffa67b48981e441d323c3109718aee245d6ac8ccd21ddadadb94303c922c0d79d131ea59a0b6ba83e1157695db01189bb4b7e9f14b7200) ;; Returns (ok 0x037a6b62e3c8b14f1b5933f5d5ab0509a8e7d95a111b8d3b264d95bfa753b00296) 96 | - \`\`\` 97 | +Clarity 4 introduces a new function to verify signatures for the secp256r1 98 | +elliptic curve, which is widely used for cryptographic operations. 99 | 100 | - `secp256r1-verify` 101 | 102 | - - **Input**: `(buff 32), (buff 64) | (buff 65), (buff 33)` 103 | + - **Input**: `(buff 32), (buff 64), (buff 33)` 104 | - **Output**: `bool` 105 | - **Signature**: `(secp256r1-verify message-hash signature public-key)` 106 | - **Description**: The `secp256r1-verify` function verifies that the provided 107 | @@ -491,9 +473,9 @@ which is widely used for cryptographic operations. These functions are: 108 | - **Example**: 109 | \`\`\`clarity 110 | (secp256r1-verify 0x033510403a646d23ee4f005061c2ca6af5da7c32c83758e8e9b6ac4cc1c2153c 111 | - 0x9608dc164b76d2e19365ffa67b48981e441d323c3109718aee245d6ac8ccd21ddadadb94303c922c0d79d131ea59a0b6ba83e1157695db01189bb4b7e9f14b7200 0x037a6b62e3c8b14f1b5933f5d5ab0509a8e7d95a111b8d3b264d95bfa753b00296) ;; Returns true 112 | + 0x9608dc164b76d2e19365ffa67b48981e441d323c3109718aee245d6ac8ccd21ddadadb94303c922c0d79d131ea59a0b6ba83e1157695db01189bb4b7e9f14b72 0x037a6b62e3c8b14f1b5933f5d5ab0509a8e7d95a111b8d3b264d95bfa753b00296) ;; Returns true 113 | (secp256r1-verify 0x0000000000000000000000000000000000000000000000000000000000000000 114 | - 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 115 | + 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 116 | 0x037a6b62e3c8b14f1b5933f5d5ab0509a8e7d95a111b8d3b264d95bfa753b00296) ;; Returns false 117 | \`\`\` 118 | ``` 119 | ## Vote Outcome(s) 120 | 121 | | Name | Vote | 122 | | ---------------- | ------- | 123 | | Aaron Blankstein | abstain | 124 | | j2p2 | yes | 125 | | Friedger | yes | 126 | | Jesse Wiley | yes | 127 | | Vlad | yes | 128 | | Radu | yes | 129 | | Setzeus | yes | 130 | 131 | _Note_ Brice Dobry is the author of SIP-033, as such no vote was tallied for him. 132 | 133 | The Technical CAB approves SIP-033 with 6 yes votes, where 1 members abstained and 1 vote was discarded due to authorship. 134 | -------------------------------------------------------------------------------- /sips/sip-023/sip-023-emergency-fix-traits.md: -------------------------------------------------------------------------------- 1 | # Preamble 2 | 3 | SIP Number: 023 4 | 5 | Title: Emergency Fix to Trait Invocation Behavior 6 | 7 | Authors: 8 | Aaron Blankstein , 9 | Brice Dobry , 10 | Jude Nelson , 11 | 12 | Consideration: Technical, Governance 13 | 14 | Type: Consensus 15 | 16 | Status: Ratified 17 | 18 | Created: 1 May 2023 19 | 20 | License: BSD 2-Clause 21 | 22 | Sign-off: Rafael Cárdenas (SIP Editor), Jesse Wiley (Acting Technical CAB Chair), Jason Schrader (Governance CAB Chair), Jude Nelson (Steering Committee Chair) 23 | 24 | Discussions-To: https://github.com/stacksgov/sips 25 | 26 | # Abstract 27 | 28 | On 1 May 2023, it was discovered that smart contracts deployed prior to Stacks 2.1 29 | that exposed public methods with 30 | trait arguments could not be invoked with previously working trait-implementing 31 | contract arguments. 32 | 33 | This bug was caused by the activation of Stacks Epoch 2.2 (https://github.com/stacksgov/sips/blob/main/sips/sip-022/sip-022-emergency-pox-fix.md). 34 | 35 | This SIP proposes an **immediate consensus-breaking change** to 36 | introduce a new Stacks epoch 2.3 that corrects this regression. 37 | 38 | **This SIP proposes a Bitcoin activation height of 788,240** 39 | 40 | # Introduction 41 | 42 | Clarity 2, introduced in Stacks 2.1, includes a new type checker and type system which 43 | impacts trait invocations. In order for existing contracts to remain 44 | compatible, their types must be _canonicalized_. In the context of traits, 45 | the type canonicalization rules implement the new trait semantics introduced in 46 | [SIP-015](./sips/sip-015/sip-015-network-upgrade.md). 47 | 48 | ## Epoch 2.2 Bug Behavior 49 | 50 | The type canonicalization method performed an exact check for the current epoch: 51 | 52 | ```rust 53 | pub fn canonicalize(&self, epoch: &StacksEpochId) -> TypeSignature { 54 | match epoch { 55 | StacksEpochId::Epoch21 => self.canonicalize_v2_1(), 56 | _ => self.clone(), 57 | } 58 | } 59 | ``` 60 | 61 | Therefore, a pre-2.1 function with trait arguments that is invoked in Stacks 2.2 62 | will fail to canonicalize its trait arguments, and abort with a 63 | runtime analysis error. Specifically: 64 | 65 | * If a miner includes a contract call transaction with trait arguments in a block, the transaction will abort with a runtime error. 66 | 67 | * If a user submits a contract call transaction with trait arguments to the 68 | mempool, it will be rejected. 69 | 70 | * A read-only contract-call with trait arguments will fail with a runtime 71 | analysis error. 72 | 73 | # Specification 74 | 75 | This hard fork will do the following: 76 | 77 | * In epoch 2.2, the current buggy behavior will be preserved. All 78 | contract-calls with trait arguments must fail with a runtime analysis error. 79 | 80 | * In epoch 2.3, the desired behavior will be restored. The trait semantics 81 | described in SIP-015 will be restored, and trait arguments in 82 | contract-calls will be treated as they were in Stacks 2.1. 83 | 84 | * Set the minimum required block-commit memo bits to `0x08`. All block-commits 85 | after the Bitcoin block activation height must have a memo value of at least 86 | `0x08`. This ensures that miners that do not upgrade from Stacks 2.2 will not 87 | be able to mine in Stacks 2.3. 88 | 89 | * Set the mainnet peer network version bits to `0x18000008`. This ensures that follower 90 | nodes that do not upgrade to Stacks 2.3 will not be able to talk to Stacks 91 | 2.3 nodes. 92 | 93 | * Set the testnet peer network version bits to `0xfacade08`. This ensures that 94 | testnet follower nodes that do not upgrade to Stacks 2.3 will not be able to 95 | talk to Stacks 2.3 nodes. 96 | 97 | The reference implementation will update the `canonicalize()` method to match on all epochs, setting 98 | the epoch 2.3 behavior to `self.canonicalize_v2_1()`, and the epoch 2.2 behavior to `self.clone()`. 99 | This will preserve the buggy 2.2 behavior during the 2.2 epoch (so that the 100 | hard fork does not require rollback), but fix the behavior after activation 101 | of the 2.3 epoch. 102 | 103 | # Related Work 104 | 105 | Several potential workarounds were explored first to try to solve this issue without a hard-fork. 106 | Unfortunately, attempts to wrap pre-2.1 contracts with 2.2 contracts can avoid the mempool rejection, 107 | but still hit the same error in the form of a runtime type-checker error. 108 | Upon further inspection into the code paths, a hard-fork option was determined to be the only viable option in this case. 109 | 110 | Consensus bugs requiring immediate attention such as this 111 | have been detected and fixed in other blockchains. In the 112 | absence of a means of gathering user comments on proposed fixes, the task of 113 | activating these bugfixes has fallen to miners, exchanges, and node runners. As 114 | long as sufficiently many participating entities upgrade, then a chain split is 115 | avoided and the fixed blockchain survives. A prominent example was Bitcoin 116 | [CVE-2010-5139](https://www.cvedetails.com/cve/CVE-2010-5139/), in which a 117 | specially-crafted Bitcoin transaction could mint arbitrarily many BTC well above 118 | the 21 million cap. The [developer 119 | response](https://bitcointalk.org/index.php?topic=823.0) was to quickly release 120 | a patched version of Bitcoin and rally enough miners and users to upgrade. In a 121 | matter of hours, the canonical Bitcoin chain ceased to include any transactions 122 | that minted too much BTC. 123 | 124 | # Backwards Compatibility 125 | 126 | There are no changes to the chainstate database schemas in this SIP. Everyone 127 | who runs a Stacks 2.2 node today will be able to run a Stacks 2.3 node off of 128 | their existing chainstates before the activation height. 129 | 130 | Stacks 2.3 nodes will not interact with Stacks 2.2 nodes on the peer 131 | network after the Bitcoin block activation height passes. In 132 | addition, Stacks 2.3 nodes will ignore block-commits from Stacks 2.2 133 | nodes. Similar changes were made for Stacks 2.05, Stacks 2.1, and 134 | Stacks 2.2 to ensure that the new network cleanly separates from 135 | stragglers still following the old rules. 136 | 137 | # Activation 138 | 139 | This SIP shall be considered Activated if the Stacks 2.3 network is live at the 140 | Bitcoin block activation height. 141 | 142 | The node software for Stacks 2.3 shall be merged to the `master` branch of the 143 | reference implementation no later than two days prior to the activation 144 | height. This means that everyone shall have at least two days to upgrade 145 | their Stacks 2.2 nodes to Stacks 2.3. 146 | 147 | # Reference Implementation 148 | 149 | The reference implementation of this SIP can be found in the 150 | `feat/2.3-traits-only-fix` branch of 151 | the Stacks blockchain reference implementation. It is available at 152 | https://github.com/stacks-network/stacks-blockchain. 153 | -------------------------------------------------------------------------------- /sips/sip-027/results/multisig-pool-votes.csv: -------------------------------------------------------------------------------- 1 | voter,txid,for,power 2 | SP2Z2CBMGWB9MQZAF5Z8X56KS69XRV3SJF4WKJ7J9,0xfcb85e802e3fb55a712589f27771b0ba06807e2dfde5bb63123dee2cc0f0d446,true,1999000000 3 | SP39ZYHN0GRAA9FBE43QGQ2HFS3PRWZGE1JCQRWYH,0x722c3009c9446f1ad01b6f542100ba359afd35033d751e691704a98bf2b6e459,true,298000000 4 | SP1NX4J8WPXR8KYVYMV2AF97Q5R6XJ8VVFSXMEDQ3,0xb22895e5ac0e2aecb8fd9ef16aa347a0836a52e2b281d271336b82c50e9a0464,true,24822000000 5 | SP2JCF3ME5QC779DQ2X1CM9S62VNJF44GC23MKQXK,0x6e490a6cdb58a6ab885927abe09300a549bac71f331e8b77decf12713cf55d47,true,279996000000 6 | SPKS1G7EQHP6FCFPFQW9S1913EAHHGHX0493F14V,0xe78ab7a0da4b986c83c25bf3d1709b793459054fa8991101f7703c2717bae279,true,62954000000 7 | SPQZ94RC1JB4YQYDD17WSH397G83RP21G8Z9CHSM,0xbb1c26ff2d339cea72eeff51ea4cc2585c35deac7af5c0d7a329381915f03f2d,true,20398000000 8 | SP760GCSGE6K8EX9EMW9QE12NY6QAPVAHFHNVZYA,0x221da41fefb27565dc682efbcc04a0e5ed3d905ec9d138ea2eaa23819512073e,true,4665000000 9 | SP26HQEB01J47QGKGSDP6XJ6Z5TCM7ZEGAB6TXQPN,0xd983591ab70d8c91aa50bd172e24f2b4613ee16a00441b73bfb008d9ae2bcecc,true,4665000000 10 | SPP74WS833MY99FXA1H2QC64RFMVCNZ37765FM3R,0x9616daa15b9676689587b5ad3cd9459ecdfbbd262751d116a7524c2f535e5aab,true,119000000 11 | SP2F0DP9Z3KSS0DABDBJN0DA0SHMCVWHXPVTH3PJJ,0xb732b3a063a788ef076859a833cdfeb4eb89614d30adc5e6578719c29645af90,true,99000000 12 | SP3S3X4WCNPTDZW0623D5MGFK6K8WR8PSQAXTY505,0x679962316ec535cb60c97d247fa49cee3d765f57893fc624343bb5c5ec927877,true,1053996000000 13 | SP3N2RARPZ4FZP7JHJTXF30NAHQ0T9EYG4QZG4DJ5,0xbdf0a3d6fcb284a13d5cf1c18160d3d19d829fb63ded4a909de780bf6304df54,true,1680000000 14 | SP2CM2RVAAKEJ4BF8AD5KV7B84FN2KPRM0A578AE6,0x93dad6e055d2fd40553acb6157f69ca94fd5ea200983b18b7a4e8839db3ac294,true,499999999519 15 | SP2W7WXBSVXGQGDBM03C691T5ZGTV9EQ7NVJH9H19,0x1d6695f3b2bfd5e3f21c42ff71e705fc6da639b8a6ebc025118915e70050d168,true,1044412696452 16 | SP2KW6DXVTR0SJGY3GN8GMPRP0KK2J8B9T4PMJWEP,0xd9f9198c3b3b361e131dbf36c3def9c5b3e019016cc7ef7e619e7d7df7ebb847,true,799999000000 17 | SPZFXRQMCWCYJWM0MCJ6RVRX1AX6297SJ50VE41R,0x812ea10afd1254f220362d9053f4fec22e277b94e8f8dabce8aa68fba35c4d5f,true,5048000000 18 | SP329M6CS0S3738Z0T268FXQXBSX0ZD1FZVBZS037,0x26690a514edd9bb8f928589fd5c5d5cef1b40133a70b98e2ff6f9ee7f12c0cd5,true,747000000 19 | SPSTE5R54386QDCDNJJWH2EXQFST44QYZW3RPMD3,0x9a5cd39860cc26634377562d4b8719e32e10ebb4b1bddc2e13e9bb2e2402e8c5,true,299000000 20 | SP12RR3Q6P9RAM5C4MJNFQ2PP17QRNNJ81VC9MEW2,0x48d58940464170fe2ecfae5b07624508b2f07422237fbec6dfde309d59030ca7,true,198000000 21 | SP2Q5WHA9NAGWQV500HSV93SEG8PJDNC6FAH88EP4,0x9996688c703ba74ca7def85b6f196520ae9dbd1b12ee1a24ca0bf26435953666,true,219999000000 22 | SPGTGMQWQ24S4SDZE9QV7TH6J2M9PEPQX6DKRTX4,0x5c4b4179ff3e009eb6e45546c95d7f7afa455afbd43a36fcc453d6bc29a073c8,true,970741646 23 | SP30JZHPM23NN4KRNBZWCKRW6HGKN7EYKFKP9HBBN,0x5cb28fbcf7157ef4598c07ae242ae0641ac874cef7cb8f38e3819b581b1eed07,true,59997000000 24 | SP3BNT6YEYFMVTT9V8MMY8ZKM4P9M3SY9X9PDJVEB,0xa1cd335ea715d27d035792e9b88df71e59ad56a0a4b6234e7ba535653bb34a98,true,11998000000 25 | SP1WYMS04HEP4V5RQQ51JJ4D9S1Z15RTJ3GPR0HDK,0x5d34743e97b3c9f15277c714f7b6dd95221c5fec7496c6c716960aea2ee79cdf,true,303982000000 26 | SP9XX1CEWA7JVG98P888VMYD4X5YBQ6H3ST516HG,0x2562412014bfcde5be7e58084f464c67ee819a0446071b0a6544aad1f6118e39,true,498000000 27 | SP8R8AT0HS12MRKHMZ22J05DMTBDHRW9XJBKE5DG,0x689847ef5774f935758bd1c6a2edab820cad72683ce3d572f329053af03de927,true,579000000 28 | SP3N0TH3N7BDG4WBSYV6FE2ASSAPEGWK47EEWD9TV,0x986513eb0bac134231cf1066f6e95577bb4081f64fb792fb402c59cd294199e3,true,1749000000 29 | SP2TZE09GHARKG0B8NTT9X77QXBTQPQ2J1579T0D8,0x12e413f9aac2902816bb051ed4459feb5feff858abc108f760b968984887f514,true,49999000000 30 | SP27Z5KCV5QGFH255ZWGMF0RVSRGZ9RTNAEE1X28,0x356ce4cdb75e3065f082b2e62bf52375d80b54c3635eeb76e076656fd9df551b,true,299000000 31 | SP20D7NAJPTDS8AVTFE88VWQ5QQTYB29HYNEHZZGA,0xed50aa5e6de4ffe26c5301cb79300d4c309b096fb16e2fcd48bc5f57332a5f8c,true,128999000000 32 | SP2EJSKCAD26AKPNYBQACSX9AY2JX6V27D3F9BW56,0x19b766dfaffc506f48fd62c2c907e9030fe4a8f923bdf8d39e1e74d2047dd045,true,740000000 33 | SPP3HM2E4JXGT26G1QRWQ2YTR5WT040S5NKXZYFC,0xf880b92b162e387c4ba7bced7fbc494de7a18f10d61852c294150f8d3c56c72a,true,5399000000 34 | SP39DC776TVRWSPSXNXCCM80APY6EBV4J1Y3HAZYJ,0xca79dae630eec22105e5ce819a223aa96b3faa60601f96adaf6384f640aeabf5,true,600049000000 35 | SP2G67CTZDK869T8E25W3M6AAF1MNJ5GNEJVZA6A4,0x6e64dcf5b82e97a15c05dce1421a83e6455b08b5a7c0e11c424612a6d32f41a9,true,103000000 36 | SP35MER4PHM6XGB99YDRQAK0M0JQ8F9CVF04VZ1VX,0x00dbd5315926e62fcf29222d4803443d4dcc41e67a9f166efbfbd07e9c925056,true,11999000000 37 | SP29902VVK134BEFGP0F3QT7W2H5CFY2BVWAKSN7E,0xfbaedaecbadd396b0e43491f849286c690c214801eda8825f1a52fdf5910b1a9,true,2000000000 38 | SP2ZRF8JCSA852P2K4ZB7RS21M43NYFKPSQ7DG1N8,0xdc3b4efdd644f2a291f5217f851563f8e67862785571d50ebc2b27a51aca93bf,true,6993000000 39 | SP2DC8W3DB139SWGHCZ173ZRQJKY05BCXMC2KGXX7,0x7a58649ecc03e4ce143ae6650b120c48b06e9df66ad5c01820bed9838b2a740c,true,2799000000 40 | SPF4682V9B3SNAYRTGWX6H3MWDRVM1VC4ETDC3MS,0x62f3c199fe1b0ee6db9a713282e26ea9aace4fc560c293d775a4695c965d0ba4,true,9999000000 41 | SP10Y2X7RMBZPDH64Y49KFDPG4WK3YY6QN7XE8KHD,0xcb5c8e7ad2a51155fee1ed48bf9e251fb1539bf2875b3f8c62e614785fa4f38d,true,24005930751 42 | SP3J9J71T02XB5C4PJJT3FZ1FASYJ4V8XMR6QY8D0,0x9620034d7ddce6a3410d719dcca63d73e058a832c0d9de4c825fbab9a3b88303,true,599000000 43 | SP1RJC76DDEGTXEA21MNVDAV40Y4HW845C9J46RJS,0xe0f1680ed983daa208f4f0c53e34629b3c72976681ac7ee92b3118d32d261e19,true,101000000 44 | SP22B1M07CY1TTC683V4P6VPTCCWCX21BES7DD35M,0x3a14072db68af796f7a15e0ccf91969f3125caca3be950699a48a7597929644f,true,39404300660 45 | SP3CHC5CKZGPZ3W4Q4JASMM5ZSMD3P7TQWNSE6BQ8,0x5e4b7e919b6ddc8f2119bec977ce051a003d98d40023c97c57e4c056d91b3f1a,true,36198000000 46 | SMX5RPBHKPF4M2WG14K8W8D9M7Y58A20N6GY9VBB,0xbe16eda8ff0dc9d726aabd730d28574a809be3ea7f4fc59509d0214456456b14,true,125000000000 47 | SM375112TJX2XDBKV31HTS7Y96681KDSJ9VV4PQKV,0xd5a4a61768251919163d70ed0b17e1243b9382b9fa6f8039d8168fd38e9ea55c,true,150000000000 48 | SM28MZMVW2W1PK9EGY0MWVTKKW5C8H8FGPNZY3Z6H,0x40c09fc8f40a56ffa4a477a5a8c9f91b8b849a580e90dac97310f1b7ec49c2da,true,125000000000 49 | SMSTT1YVA10J7PFKWT9C8C4Y0TRQX14KGKQDXJX6,0x0941b7e05981cbe36f524a40047bf997fd4fb3df623253e94dbbe64991e57401,true,120000000000 50 | SM11TJG7ZZJMERTMFZBRQF26WJBHJ1ES5TXWDEKJM,0xb06da129bf654fdbe3e3042986bea17f2293fc2d036859e9147d793dcc297ed3,true,125000000000 51 | SM43APJS7JJXJVF53RDH8AAA1561QZ127NWG6AQX,0xe664ad4a6f223457a9cd27d33f838d9428a10709bbdb7ec96ebbfb3babfe01bd,true,19000000000000 52 | SM4AETMATXSD8XKGV0J39JJ088XVEQXGD8287P8H,0x9ff5a426248dc98592088370382d381871fbdc302bbe61d1fefbc6a4e770e49f,true,120000000000 53 | SM2VPH5Q2S14DY67M0NBSW6GSY47Z5WRHRWDGB0RK,0xd72c6980c46e4c3b2bab532432dfa93daec3b1b9f858d4b1f7c1e088b5beef3a,true,125000000000 54 | SMFZTYFFXVZJNBX21ZZB0FZFTTBQT9RBNEZ5FZ01,0x7d8a010fa1024539690f56da86962a43a8b9c142cdea003d40046c62c6c2d16a,true,120000000000 55 | SM2BMD7QNSDDZXQXXGFNPD8EGSQ69GZF2CQ8Z1XN9,0x253ba5316e8c923fb2e581aa43b4a0e14837072955d6b711565e6a3f2132deb2,true,120000000000 56 | SM1JFZTVCX1RZCCHWMGWCZ3TY37KVEJZJKFEWP8F7,0xc9046bab41eeead77ac6b916c4818bb43731cbb535de21ab7d2e698ed46de331,true,15000000000000 57 | SM17AB7JPYHX1BJ0NGPR8TJ8GAQ5E7R65RJPX9EM,0xe44f2b14fbf2f1e80a2fe87d55b9ccd0278613b8999afec6fe90661c94d60ebe,true,5390000000000 58 | SM39S3W3ADQ5NP68N9R4FWMWBC1NQAS4VWXWWTZYM,0x772fee8ddaa0ad78d3e272b4bf205e91061e94333916836c99484ec6ba224eb4,true,3000000000000 59 | SP2NHZDAMMEEASE4DKHYYCVAG8RF8PA7YHPPW40BX,0x34383c87108696b62980ba95575bad6d2f41121ed888fcbe11ae284e2d59d902,true,5199000000 60 | SP3TA7SMY7APYR9SFKDT0527NC0GWR84S3AHEM0NE,0xe21ea78992fc21282803bbededfcd8a215341c83890a531040a790551aea9509,true,50054927941 61 | SP2C7E0N4PNV1E55SZ0QBHHXYTHHKJ7GTD5T17JGW,0x81100751b3cfdc00716e8d34f4eb0ae0b453830f0e675906bc4645ed55db912d,true,50052337860 62 | SP6WS2G1W2XHYXHX30PSPS25GDNB3DF7610SFZJC,0xf4b30ba2a3a19649063688fef392e5de32bee0a243ee0cdabf518504006beb91,true,140799000000 63 | SPG34S51QV6YTZQGVRPZY9323MY4BTCFAFP1HR25,0xf89bd1db3860ae92b1d2ac696ead1c729af49329862ca2ef7dcb1e75a8c2a2ec,true,1204000000 64 | SP37Q561WR22AXA3EC9GJDN9QGK9K97Z3H940EV9Z,0xff332cb55ca0e6b9e7ab417c052b43f7abbbb485b25261bc33b313e983a9e603,true,59999000000 65 | SM2CDAXV570733P3K1HAF54C6D63FXQ7X24SJTHVC,0x5c2dc7b668f8d87a2b0545dd0e26afeffb69d9c5ce67cfc04fb3e7f50fbacfab,true,15000000000000 66 | SP1G2V19PMG1HDAXZP7DY4Z59VSG2SR1BRGDZEGGG,0x0e5896916d38a201f7675bb6bde19abb1a5a66bd1548f9f3326d7f6d8f45aa09,true,238848000000 67 | SPTF7TRK58APKSPTRFK7N66RSCWE7MZ559A0A88J,0x06409ed827b0875d8d6a24c6ece78b4e59c25c2e36ca27a0b8a37587312ae97e,true,299000000 68 | SP1SJ7PGM3M7D7J60C39FGXJ29ES1JWVJGJ3XCX75,0x504ead937c63f2bfe790aac500218bbf079d7a3c03ea3e307fdfade45a6c54a0,true,79999000000 69 | SP103BZSXCX2YF8HXMN8DDP5Z46DN4A0HPRDYJXDD,0xfa3a1312e5d074c8b6d261234f0f53bb3041839c3a69ec65d24c4d9b6fc7e2b1,true,100000000 70 | SP3N4E7VQVRZVPVARD6QTYCCM3VBMDPNP53TM39AN,0x1cfeb40246c0a76797f29f3fe58863c44bda58c091a0a9a8ad8dc252faa319c2,true,76999000000 71 | SPETRC149CY5PSKEK1K2Q160MR8YQ924GETDJRSS,0xe52371e373ad1ba353cf9e8a3e7eb953d6c7056dc0f0c4b9efa5794ff6c9466f,true,419998000000 72 | SP3H4VWAJ9A2468RVKWCGMV33PGJC1Z8CFZZ19ZTR,0xc8ea0db9a9bd10da9fc8a9ac987b85a253149a7d9be2710c9e23735f01fb7194,true,30666000000 73 | SP2EM86AM2AYGGNJX562AY6BDTKWXQMQVQ0T863M6,0x5be52b38bf9c1270dd6977bd60a597a1965bb47556ea5f1cfe1399e68d11b3d1,true,92490000000 74 | SP2HCKXC6GAWMAHWH06XGJBTS7JVA6YFRJJB2PCWA,0xac40e60f38d4c8c467066861a149f9f85c0e9a11513eb565303827573624e995,true,2996000000 -------------------------------------------------------------------------------- /sips/sip-020/sip-020-bitwise-ops.md: -------------------------------------------------------------------------------- 1 | # Preamble 2 | 3 | SIP Number: 020 4 | 5 | Title: Bitwise Operations in Clarity 6 | 7 | Authors: Cyle Witruk , Brice Dobry 8 | 9 | 10 | Consideration: Technical, Governance 11 | 12 | Type: Consensus 13 | 14 | Status: Ratified 15 | 16 | Created: 12 November 2022 17 | 18 | License: CC0-1.0 19 | 20 | Sign-off: Jason Schrader , Jesse Wiley , Jude Nelson 21 | 22 | Layer: Consensus (hard fork) 23 | 24 | Discussions-To: https://github.com/stacksgov/sips 25 | 26 | # Abstract 27 | 28 | This SIP adds bitwise operations to the Clarity language which could simplify 29 | the implementation of smart contracts that require manipulation of bits. The 30 | changes include the addition of the following operations: 31 | 32 | - Bitwise Xor (`bit-xor`) 33 | - Bitwise And (`bit-and`) 34 | - Bitwise Or (`bit-or`) 35 | - Bitwise Not (`bit-not`) 36 | - Binary Left Shift (`bit-shift-left`) 37 | - Binary Right Shift (`bit-shift-right`) 38 | 39 | # License and Copyright 40 | 41 | This SIP is made available under the terms of the Creative Commons CC0 1.0 42 | Universal license, available at 43 | https://creativecommons.org/publicdomain/zero/1.0/ This SIP's copyright is held 44 | by the Stacks Open Internet Foundation. 45 | 46 | # Introduction 47 | 48 | Bitwise operations are common in other programming languages. Common algorithms, 49 | including many used in encryption, or the ability to set and check flags in a 50 | bit field for example, would be much more difficult to implement without the use 51 | of these operations. When executing a contract using these operations, the 52 | common hardware on which miners and nodes are likely to be running can all 53 | perform these operations very efficiently -- these are typically single cycle 54 | operations. Note that the addition of these bitwise operations commits the 55 | Clarity VM to using 2's complement to represent integers. 56 | 57 | # Specification 58 | 59 | ## Bitwise Xor (`bit-xor`) 60 | 61 | `(bit-xor i1 i2...)` 62 | 63 | - **Inputs:** int, ... | uint, ... 64 | - **Output:** int | uint 65 | 66 | Returns the result of bitwise exclusive or'ing a variable number of integer 67 | inputs. 68 | 69 | | Bit in i1 | Bit in i2 | Bit in Output | 70 | | --------- | --------- | ------------- | 71 | | 0 | 0 | 0 | 72 | | 0 | 1 | 1 | 73 | | 1 | 0 | 1 | 74 | | 1 | 1 | 0 | 75 | 76 | The following example uses only 8 bits to make it easier to follow. Actual 77 | Clarity values are 128 bits. 78 | 79 | ``` 80 | (bit-xor 17 30) ;; Return 15 81 | ;; Binary representation: 82 | ;; i1 (17): 00010001 83 | ;; i2 (30): 00011110 84 | ;; Output (15): 00001111 85 | ``` 86 | 87 | ### Examples 88 | 89 | ``` 90 | (bit-xor 1 2) ;; Returns 3 91 | (bit-xor 120 280) ;; Returns 352 92 | (bit-xor -128 64) ;; Returns -64 93 | (bit-xor u24 u4) ;; Returns u28 94 | (bit-xor 1 2 4 -1) ;; Returns -8 95 | ``` 96 | 97 | ## Bitwise And (`bit-and`) 98 | 99 | `(bit-and i1 i2...)` 100 | 101 | - **Inputs:** int, ... | uint, ... 102 | - **Output:** int | uint 103 | 104 | Returns the result of bitwise and'ing a variable number of integer inputs. 105 | 106 | | Bit in i1 | Bit in i2 | Bit in Output | 107 | | --------- | --------- | ------------- | 108 | | 0 | 0 | 0 | 109 | | 0 | 1 | 0 | 110 | | 1 | 0 | 0 | 111 | | 1 | 1 | 1 | 112 | 113 | The following example uses only 8 bits to make it easier to follow. Actual 114 | Clarity values are 128 bits. 115 | 116 | ``` 117 | (bit-and 17 30) ;; Return 16 118 | ;; Binary representation: 119 | ;; i1 (17): 00010001 120 | ;; i2 (30): 00011110 121 | ;; Output (16): 00010000 122 | ``` 123 | 124 | ### Examples 125 | 126 | ``` 127 | (bit-and 24 16) ;; Returns 16 128 | (bit-and 28 24 -1) ;; Returns 24 129 | (bit-and u24 u16) ;; Returns u16 130 | (bit-and -128 -64) ;; Returns -128 131 | (bit-and 28 24 -1) ;; Returns 24 132 | ``` 133 | 134 | ## Bitwise Or (`bit-or`) 135 | 136 | `(bit-or i1 i2...)` 137 | 138 | - **Inputs:** int, ... | uint, ... 139 | - **Outputs:** int | uint 140 | 141 | Returns the result of bitwise inclusive or'ing a variable number of integer 142 | inputs. 143 | 144 | | Bit in i1 | Bit in i2 | Bit in Output | 145 | | --------- | --------- | ------------- | 146 | | 0 | 0 | 0 | 147 | | 0 | 1 | 1 | 148 | | 1 | 0 | 1 | 149 | | 1 | 1 | 1 | 150 | 151 | The following example uses only 8 bits to make it easier to follow. Actual 152 | Clarity values are 128 bits. 153 | 154 | ``` 155 | (bit-or 17 30) ;; Return 31 156 | ;; Binary representation: 157 | ;; i1 (17): 00010001 158 | ;; i2 (30): 00011110 159 | ;; Output (31): 00011111 160 | ``` 161 | 162 | ### Examples 163 | 164 | ``` 165 | (bit-or 4 8) ;; Returns 12 166 | (bit-or 1 2 4) ;; Returns 7 167 | (bit-or 64 -32 -16) ;; Returns -16 168 | (bit-or u2 u4 u32) ;; Returns u38 169 | ``` 170 | 171 | ## Bitwise Not (`bit-not`) 172 | 173 | `(bit-not i1)` 174 | 175 | - **Inputs:** int | uint 176 | - **Output:** int | uint 177 | 178 | Returns the one's compliment (sometimes also called the bitwise compliment or 179 | not operator) of `i1`, effectively reversing the bits in `i1`. 180 | 181 | In other words, every bit that is `1` in `ì1` will be `0` in the result. 182 | Conversely, every bit that is `0` in `i1` will be `1` in the result. 183 | 184 | | Bit in i1 | Bit in Output | 185 | | --------- | ------------- | 186 | | 0 | 1 | 187 | | 1 | 0 | 188 | 189 | The following example uses only 8 bits to make it easier to follow. Actual 190 | Clarity values are 128 bits. 191 | 192 | ``` 193 | (bit-not u41) ;; Return u214 194 | ;; Binary representation: 195 | ;; i1 (41): 00101001 196 | ;; Output (214): 11010110 197 | ``` 198 | 199 | ### Examples 200 | 201 | ``` 202 | (bit-not 3) ;; Returns -4 203 | (bit-not u128) ;; Returns u340282366920938463463374607431768211327 204 | (bit-not 128) ;; Returns -129 205 | (bit-not -128) ;; Returns 127 206 | ``` 207 | 208 | ## Bitwise Left Shift (`bit-shift-left`) 209 | 210 | `(bit-shift-left i1 shamt)` 211 | 212 | - **Inputs:** int, uint | uint, uint 213 | - **Outputs:** int | uint 214 | 215 | Shifts all bits in `i1` to the left by the number of places specified in `shamt` 216 | modulo 128 (the bit width of Clarity integers). New bits are filled with zeros. 217 | 218 | Note that there is a deliberate choice made to ignore arithmetic overflow for 219 | this operation. In use cases where overflow should be detected, developers 220 | should use `*`, `/`, and `pow` instead of the shift operators. 221 | 222 | The following example uses only 8 bits to make it easier to follow. Actual 223 | Clarity values are 128 bits. 224 | 225 | ``` 226 | (bit-shift-left 6 u3) ;; Return 48 227 | ;; Binary representation: 228 | ;; Input (6): 00000110 229 | ;; Output (48): 00110000 230 | ``` 231 | 232 | ### Examples 233 | 234 | ``` 235 | (bit-shift-left 16 u2) ;; Returns 64 236 | (bit-shift-left -64 u1) ;; Returns -128 237 | (bit-shift-left u4 u2) ;; Returns u16 238 | (bit-shift-left 123 u9999999999) ;; Returns -170141183460469231731687303715884105728 (== 123 bit-shift-left 127) 239 | (bit-shift-left u123 u9999999999) ;; Returns u170141183460469231731687303715884105728 (== u123 bit-shift-left 127) 240 | (bit-shift-left -1 u7) ;; Returns -128 241 | (bit-shift-left -1 u128) ;; Returns -1 242 | ``` 243 | 244 | ## Bitwise Right Shift (`bit-shift-right`) 245 | 246 | `(bit-shift-right i1 shamt)` 247 | 248 | - **Inputs:** int, uint | uint, uint 249 | - **Output:** int | uint 250 | 251 | Shifts all the bits in `i1` to the right by the number of places specified in 252 | `shamt` modulo 128 (the bit width of Clarity integers). When `i1` is a `uint` 253 | (unsigned), new bits are filled with zeros. When `i1` is an `int` (signed), the 254 | sign is preserved, meaning that new bits are filled with the value of the 255 | previous sign-bit. 256 | 257 | Note that there is a deliberate choice made to ignore arithmetic overflow for 258 | this operation. In use cases where overflow should be detected, developers 259 | should use `*`, `/`, and `pow` instead of the shift operators. 260 | 261 | The following example uses only 8 bits to make it easier to follow. Actual 262 | Clarity values are 128 bits. 263 | 264 | ``` 265 | (bit-shift-right u170 u1) ;; Return u85 266 | ;; Binary representation: 267 | ;; Input (u170): 10101010 268 | ;; Output (u85): 01010101 269 | ``` 270 | 271 | ### Examples 272 | 273 | ``` 274 | (bit-shift-right 2 u1) ;; Returns 1 275 | (bit-shift-right 128 u2) ;; Returns 32 276 | (bit-shift-right -64 u1) ;; Returns -32 277 | (bit-shift-right u128 u2) ;; Returns u32 278 | (bit-shift-right 123 u9999999999) ;; Returns 0 279 | (bit-shift-right u123 u9999999999) ;; Returns u0 280 | (bit-shift-right -128 u7) ;; Returns -1 281 | (bit-shift-right -256 u1) ;; Returns -128 282 | (bit-shift-right 5 u2) ;; Returns 1 283 | (bit-shift-right -5 u2) ;; Returns -2 284 | ``` 285 | 286 | # Related work 287 | 288 | Not applicable 289 | 290 | # Backwards Compatibility 291 | 292 | Because this SIP introduces new Clarity operators, it is a consensus-breaking 293 | change. A contract that uses one of these new operators would be invalid before 294 | this SIP is activated, and valid after it is activated. 295 | 296 | # Activation 297 | 298 | This SIP will be a rider on SIP-015. It will be considered activated if and only 299 | if SIP-015 (and Stacks 2.1) is activated. 300 | 301 | # Reference Implementations 302 | 303 | - https://github.com/stacks-network/stacks-blockchain/pull/3389 304 | - See also discussions in 305 | https://github.com/stacks-network/stacks-blockchain/pull/3382 306 | -------------------------------------------------------------------------------- /sips/sip-034/sip-034.md: -------------------------------------------------------------------------------- 1 | # Preamble 2 | 3 | SIP Number: 034 4 | 5 | Title: Dimension-Specific Tenure Extend Variants 6 | 7 | Author(s): 8 | 9 | - Aaron Blankstein 10 | - Jude Nelson 11 | 12 | Status: Activation-in-Progress 13 | 14 | Consideration: Technical, Governance 15 | 16 | Type: Consensus 17 | 18 | Layer: Consensus (hard fork) 19 | 20 | Created: 2025-10-15 21 | 22 | License: CC0-1.0 23 | 24 | Sign-offs: 25 | * Brice Dobry , Acting Chair, Technical CAB: https://github.com/stacksgov/sips/blob/feat/sip034/considerations/minutes/technical-cab/2025-10-17-sip-034.md 26 | * Jason Schrader , Chairperson, Governance CAB: https://github.com/stacksgov/sips/blob/main/considerations/minutes/governance-cab/2025-10-17-sip-034.md 27 | * werner.btc , SIP Editor, Editors 28 | 29 | Discussions-To: 30 | * SIP pull request: https://github.com/stacksgov/sips/pull/236 31 | * SIP reference implementation: https://github.com/stacks-network/stacks-core/pull/6609 32 | 33 | # Abstract 34 | 35 | This SIP details a rider to SIP-033, including a new variant of the tenure change 36 | control transaction. This variant allows the tenure change to specify which 37 | dimension of the block budget to reset. 38 | 39 | # Copyright 40 | 41 | This SIP is made available under the terms of the CC0 (Creative Commons Zero) 42 | license, available at https://opensource.org/licenses/CC0-1.0. This SIP’s 43 | copyright is held by the Stacks Open Internet Foundation. 44 | 45 | # Introduction 46 | 47 | The Stacks network controls total runtime and I/O expenditure during Nakamoto tenures 48 | via a total tenure budget [1]. Costs are tracked using worst-case estimates of the actual 49 | runtime or I/O expended to evaluate a given Clarity operation. In Nakamoto rules, 50 | signers and miners may coordinate to include a `TenureChange` transaction in the miner's 51 | next block which extends the current tenure by resetting the counters for its ongoing 52 | runtime and I/O costs. 53 | 54 | This mechanism allows the tenure's overall budget to grow, for example, there has been a long 55 | delay between Bitcoin blocks. However, if the assessed Clarity costs are much higher 56 | than the actual runtime or I/O characteristics of the executed blocks (i.e., the actual 57 | block runtime is much faster than the worst-case scenario around which costs are modeled), 58 | signers and miners have limited ability to address this. This is because a mismatch in one 59 | dimension (e.g., read-count) should not result in another dimension being reset (e.g., write-count). 60 | Resetting all dimensions of the block budget when only one was misaligned would open the 61 | network up to denial of service (unintentional or otherwise). 62 | 63 | To address these concerns, this SIP proposes to add a new variant to `TenureChange` transactions 64 | which allows them to specify **which** cost dimension should be reset (or all of them). 65 | 66 | # Specification 67 | 68 | ## Wire Formats 69 | 70 | The serialization of the `TenureChangePayload` will be a backwards-compatible extension of 71 | the existing SIP-021 serialization [2]: 72 | 73 | ``` 74 | tenure consensus hash: 20 bytes 75 | previous tenure consensus hash: 20 bytes 76 | burn view consensus hash: 20 bytes 77 | previous tenure end: 32 bytes 78 | previous tenure blocks: 4 bytes, big-endian 79 | cause: 1 byte 80 | pubkey hash 20 bytes 81 | ``` 82 | 83 | The `cause` field serializes the new variant in a backwards compatible scheme: 84 | 85 | ``` 86 | 0x00 indicates NewBlockFound whole budget is reset. 87 | 0x01 indicates Extend whole budget is reset. 88 | 0x02 indicates Extend read-count budget is reset. 89 | 0x03 indicates Extend read-length budget is reset. 90 | 0x04 indicates Extend runtime budget is reset. 91 | 0x05 indicates Extend write-count budget is reset. 92 | 0x06 indicates Extend write-length budget is reset. 93 | ``` 94 | 95 | Values `0x00` and `0x01` are used today to indicate whether or not the 96 | `TenureChangePayload` represents a change to a new tenure or the extension 97 | of the ongoing tenure. No other values are accepted today. 98 | This SIP proposes accepting values `0x02` through `0x06` for `cause`, and taking 99 | the above actions to reset a specific cost dimension's budget. 100 | 101 | ## Coordination Between Miners and Signers 102 | 103 | This SIP only requires Stacks nodes to accept dimension-specific tenure budget 104 | resets via these new `TenureChangePayload` transaction payloads. It does 105 | not mandate a strategy for coordinating with miners to determine when 106 | dimension-specific resets might be granted. However, a brief description of how 107 | this might be achieved is provided here, for informational purposes. 108 | 109 | In the reference implementation today, signers determine how often a miner can 110 | submit a tenure-extension transaction based on how much "idle time" each signer has 111 | observed in its node. This is the amount of time the node spends doing work 112 | besides processing block proposals. Signers individually choose an amount of 113 | idle time that must pass on their node before they will approve a tenure 114 | extension. By choosing larger idle times, signers ensure that the chain does 115 | not grow so quickly that it prevents miners and signers from catching up to and 116 | staying at the chain tip. Signers advertize the earliest UNIX epoch time at 117 | which they will accept a tenure extension as part of their block proposal 118 | acknowledgements to the miner. 119 | 120 | This behavior is not consensus-critical, and is outside the scope of this SIP, 121 | but is worth mentioning because it informs how future coordination between miners 122 | and signers could work. Signers may adopt similar notions of idle time for each 123 | budget dimension in order to determine when they will accept a 124 | dimension-specific tenure budget reset. For example, a signer may measure 125 | the amount of time the node spends _not_ performing read I/O on the chainstate database 126 | ("read I/O idle time") to determine when they will issue a read-count reset. 127 | 128 | This SIP does not require a coordination strategy to be implemented before its 129 | activation. 130 | 131 | # Related Work 132 | 133 | The Stacks blockchain measures a transaction's resource expenditures along five 134 | dimensions: the number or indexed reads ("read count"), the number of bytes 135 | read ("read length"), the number of indexed writes ("write count"), the number 136 | of bytes written ("write length"), and the amount of CPU used ("runtime"). Each 137 | miner is granted a budget of each measured resource to consume over the duration 138 | of their tenure. Each Clarity operation consumes one or more of these 139 | resources. A Nakamoto block is only valid if the additional resources its 140 | transactions consume do not exceed the tenure's limits on each of these 141 | resources. 142 | 143 | The cost measurements for each Clarity operation were chosen to 144 | ensure that a Stacks node would be able to reprocess the tenure much more 145 | quickly than it is produced. If this were not the case, then Stacks nodes would 146 | be unable to catch up to the chain tip. This is particularly dangerous for 147 | Stacks signers, which may go offline for mundane reasons; signers must be able 148 | to quickly catch up to the rest of the signer network. 149 | 150 | An alternative approach considered to this SIP was to produce a more accurate 151 | measurement of how much of each resource each Clarity operation consumes. The 152 | current model is pessimistic, and assumes a worst-case resource consumption. It 153 | also does not consider the size of the _value_ of the data being processed; it 154 | instead considers the _worst-case size_ allowed by the data's _type_. 155 | We believe that the approach in this SIP is superior building a more accurate 156 | model (but does not negate a new model's usefulness) because it allows 157 | signers to determine whether or not to allocate more resources to an ongoing 158 | tenure based on their real-world observation of resource consumption when 159 | evaluating block proposals. As long as the signers observe that resource 160 | consumption in each dimension is below an acceptable threshold, such that a 161 | crashed signer could quickly catch back up, then the signers can safely extend 162 | individual resource budgets regardless of the current model's pessimism 163 | This in turn allows signers to grow the chain's tenure budgets in response 164 | to acquiring better harder, or running upgraded nodes with better 165 | block-processing algorithms. 166 | 167 | A future SIP may increase the granularity of tenure extensions. For example, 168 | the signers may be able to choose the amount of each resource to extend. 169 | This SIP does not call for this in order to speed its implementation. 170 | Furthermore, signers have the option to enforce a more granular resource 171 | consumption rate without a hard fork -- they announce to miners their target 172 | resource consumption rates, and reject miner blocks that consume resources at 173 | higher rate than their target rate. 174 | 175 | # Backwards Compatibility 176 | 177 | Per the Specification section above, the wire formats for `TenureChange` 178 | transactions are backwards compatible with the existing wire format. All that 179 | has been added are new values to represent the kind of tenure extension 180 | requested. 181 | 182 | # Activation 183 | 184 | This is intended as a rider SIP to SIP-033 [3]. If SIP-033 is ratified, then this 185 | SIP will also be ratified. Similarly, if SIP-033 is not ratified, then this SIP 186 | will not be ratified. No further criteria are needed for this SIP. 187 | 188 | # Reference Implementation 189 | 190 | This SIP's implementation is written in Rust, and is available here: https://github.com/stacks-network/stacks-core/pull/6609 191 | 192 | # References 193 | 194 | [1] https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#nakamoto-terminology 195 | [2] https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#block-structure 196 | [3] https://github.com/obycode/sips/blob/feat/clarity-4/sips/sip-033/sip-033-clarity4.md 197 | -------------------------------------------------------------------------------- /sips/sip-009/sip-009-nft-standard.md: -------------------------------------------------------------------------------- 1 | # Preamble 2 | 3 | SIP Number: 009 4 | 5 | Title: Standard Trait Definition for Non-Fungible Tokens 6 | 7 | Author: Friedger Müffke (mail@friedger.de), Muneeb Majeed 8 | 9 | Consideration: Technical 10 | 11 | Type: Standard 12 | 13 | Status: Ratified 14 | 15 | Created: 10 December 2020 16 | 17 | License: CC0-1.0 18 | 19 | Sign-off: Jude Nelson , Technical Steering Committee Chair 20 | 21 | # Abstract 22 | 23 | Non-fungible tokens or NFTs are digital assets registered on blockchain with unique identifiers and properties that distinguish them from each other. 24 | It should be possible to uniquely identify, own and transfer a non-fungible token. This SIP aims to provide a flexible and easy-to-implement standard that can be used by developers on the Stacks blockchain when creating their own NFTs. This standard only specifies a basic set of requirements, non-fungible tokens can have more features than what's specified in this standard. 25 | 26 | # License and Copyright 27 | 28 | This SIP is made available under the terms of the Creative Commons CC0 1.0 Universal license, available at https://creativecommons.org/publicdomain/zero/1.0/ 29 | This SIP’s copyright is held by the Stacks Open Internet Foundation. 30 | 31 | # Introduction 32 | 33 | Tokens are digital assets registered on blockchain through a smart contract. A non-fungible token (NFT) is a token that is globally unique and can be identified through its unique identifier. 34 | 35 | In blockchains with smart contracts, including the Stacks blockchain, developers and users can use smart contracts to register and interact with non-fungible tokens. 36 | 37 | The Stacks blockchain's programming language for developing smart contracts, Clarity, has built-in language primitives to define and use non-fungible tokens. Although those primitives exists, there is value in defining a common interface (known in Clarity as a "trait") that allows different smart contracts to interoperate with non-fungible token contracts in a reusable way. This SIP defines that trait. 38 | 39 | Each NFT always belong to one smart contract. NFTs of a smart contract are enumerated starting at 1. The current last ID is provided by a smart contract function. The asset ID together with the contract ID defines a globally unique NFT. 40 | 41 | # Specification 42 | 43 | Every SIP-009 compliant smart contract in Stacks blockchain must implement the trait, `nft-trait`, defined in the [Trait](#trait) section and must meet the requirements for the following functions: 44 | 45 | ### Last token ID 46 | 47 | `(get-last-token-id () (response uint uint))` 48 | 49 | Takes no arguments and returns the identifier for the last NFT registered using the contract. The returned ID can be used as the upper limit when iterating through all NFTs. 50 | 51 | This function must never return an error response. It can be defined as read-only, i.e. `define-read-only`. 52 | 53 | ### Token URI 54 | 55 | `(get-token-uri (uint) (response (optional (string-ascii 256)) uint))` 56 | 57 | Takes an NFT identifier and returns a response containing a valid URI which resolves to the NFT's metadata. The URI string must be wrapped in an `optional`. If the corresponding NFT doesn't exist or the contract doesn't maintain metadata, the response must be `(ok none)`. If a valid URI exists for the NFT, the response must be `(ok (some ""))`. The length of the returned URI is limited to 256 characters. The specification of the metadata should be covered in a separate SIP. 58 | 59 | This function must never return an error response. It can be defined as read-only, i.e. `define-read-only`. 60 | 61 | ### Owner 62 | 63 | `(get-owner (uint) (response (optional principal) uint))` 64 | 65 | Takes an NFT identifier and returns a response containing the principal owning the NFT with the given identifier. The principal must be wrapped in an optional. If the corresponding NFT doesn't exist, the response must be `(ok none)`. The owner can be a contract principal. 66 | 67 | If a call to function `get-owner` returns some principal `A`, then it must return the same value until the `transfer` function is called with principal `A` as the sender. 68 | 69 | For any call to `get-owner` with an ID greater than the last token ID returned by the `get-last-token-id` function, the call must return a response `(ok none)`. 70 | 71 | This function must never return an error response. It can be defined as read-only, i.e. `define-read-only`. 72 | 73 | ### Transfer 74 | 75 | `(transfer (uint principal principal) (response bool uint))` 76 | 77 | The function changes the ownership of the NFT for the given identifier from the sender principal to the recipient principal. 78 | 79 | This function must be defined with define-public, as it alters state, and must be externally callable. 80 | 81 | After a successful call to `transfer`, the function `get-owner` must return the recipient of the `transfer` call as the new owner. 82 | 83 | For any call to `transfer` with an ID greater than the last token ID returned by the `get-last-token-id` function, the call must return an error response. 84 | 85 | It is recommended to use error codes from standardized list of codes and implement the function for converting the error codes to messages function that are defined in a separate SIP. 86 | 87 | ## Trait 88 | 89 | ``` 90 | (define-trait nft-trait 91 | ( 92 | ;; Last token ID, limited to uint range 93 | (get-last-token-id () (response uint uint)) 94 | 95 | ;; URI for metadata associated with the token 96 | (get-token-uri (uint) (response (optional (string-ascii 256)) uint)) 97 | 98 | ;; Owner of a given token identifier 99 | (get-owner (uint) (response (optional principal) uint)) 100 | 101 | ;; Transfer from the sender to a new principal 102 | (transfer (uint principal principal) (response bool uint)) 103 | ) 104 | ) 105 | ``` 106 | 107 | ## Use of native asset functions 108 | 109 | Although it is not possible to mandate in a Clarity trait, contract implementers must define at least one built-in native non-fungible [asset class](https://app.sigle.io/friedger.id/FDwT_3yuMrHDQm-Ai1OVS) that are provided as Clarity primitives. This allows clients to use Post Conditions (explained below), and takes advantages of other benefits, like native support for these asset balances and transfers through `stacks-blockchain-api`. The reference implementations included in this SIP use the native asset primitives, and provide a good boilerplate for their usage. 110 | 111 | The native asset functions include: 112 | 113 | - `define-non-fungible-token` 114 | - `nft-burn?` 115 | - `nft-get-owner?` 116 | - `nft-mint?` 117 | - `nft-transfer?` 118 | 119 | The following requirements for using native asset functions are defined: 120 | 121 | ### Transfer 122 | 123 | If the `transfer` function is called from a client without a [post-condition](https://docs.blockstack.org/understand-stacks/transactions#post-conditions) in deny mode or without any NFT condition about a changed owner, then the function call must fail with `abort_by_post_condition`. 124 | 125 | # Using NFTs in applications 126 | 127 | Developers who wish to use a non-fungible token contract in an application should first be provided, or keep track of, various different non-fungible token implementations. When validating a non-fungible token contract, they should fetch the interface and/or source code for that contract. If the contract implements the trait, then the application can use this standard's contract interface for making transfers and getting other details defined in this standard. 128 | 129 | All of the functions in this trait return the `response` type, which is a requirement of trait definitions in Clarity. However, some of these functions should be "fail-proof", in the sense that they should never return an error. These "fail-proof" functions are those that have been recommended as read-only. If a contract that implements this trait returns an error for these functions, it may be an indication of a non-compliant contract, and consumers of those contracts should proceed with caution. 130 | 131 | ## Use of Post-Conditions 132 | 133 | The Stacks blockchain includes a feature known as "Post-Conditions" or "Constraints". By defining post-conditions, users can create transactions that include pre-defined guarantees about what might happen in that contract. 134 | 135 | For example, when applications call the `transfer` function, they should _always_ use post conditions to specify that the new owner of the NFT is the recipient principal in the `transfer` function call. 136 | 137 | # Related Work 138 | 139 | NFTs are an established asset class on blockchains. Read for example [here](https://www.ledger.com/academy/what-are-nft). 140 | 141 | ## EIP 721 142 | 143 | Ethereum has [EIP 721](https://eips.ethereum.org/EIPS/eip-721) that defined non-fungible tokens on the Ethereum blockchain. Notable differences are that the transfer function in EIP 721 uses a different ordering of the arguments ending with the token id. The transfer function in this SIP uses the token ID as the first argument which is in line with the other native functions in Clarity. Furthermore, this SIP only defines a function for getting the URI pointing to the metadata of an NFT. The specifications for schema and other properties of the token metadata should be defined in a separate SIP. 144 | 145 | # Backwards Compatibility 146 | 147 | Not applicable 148 | 149 | # Activation 150 | 151 | This SIP is activated if 5 contracts are deployed that use the same trait that follows this specification. This must happen before Bitcoin tip #700,000. 152 | 153 | A trait that follows this specification is available on mainnet as [`SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait.nft-trait`](https://explorer.stacks.co/txid/0x80eb693e5e2a9928094792080b7f6d69d66ea9cc881bc465e8d9c5c621bd4d07?chain=mainnet). 154 | 155 | # Reference Implementations 156 | 157 | ## Source code 158 | 159 | ### Friedger's clarity-smart-contracts 160 | 161 | https://github.com/friedger/clarity-smart-contracts/blob/master/contracts/sips/nft-trait.clar 162 | 163 | ## Deployed Contracts 164 | 165 | - mainnet: [SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait.nft-trait](https://explorer.stacks.co/txid/SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait?chain=mainnet) 166 | - testnet: [ST1NXBK3K5YYMD6FD41MVNP3JS1GABZ8TRVX023PT.nft-trait.nft-trait](https://explorer.stacks.co/txid/ST1NXBK3K5YYMD6FD41MVNP3JS1GABZ8TRVX023PT.nft-trait?chain=testnet) 167 | -------------------------------------------------------------------------------- /sips/sip-008/sip-008-analysis-cost-assessment.md: -------------------------------------------------------------------------------- 1 | # Preamble 2 | 3 | SIP Number: 008 4 | 5 | Title: Clarity Parsing and Analysis Cost Assessment 6 | 7 | Author: Aaron Blankstein 8 | 9 | Consideration: Technical 10 | 11 | Type: Consensus 12 | 13 | Status: Ratified 14 | 15 | Created: 5 March 2020 16 | 17 | License: BSD 2-Clause 18 | 19 | Sign-off: Jude Nelson , Technical Steering Committee Chair 20 | 21 | Discussions-To: https://github.com/stacksgov/sips 22 | 23 | # Abstract 24 | 25 | This document describes the measured costs and asymptotic costs 26 | assessed for parsing Clarity code into an abstract syntax tree (AST) 27 | and the static analysis of that Clarity code (type-checking and 28 | read-only enforcement). This will not specify the _constants_ 29 | associated with those asymptotic cost functions. Those constants will 30 | necessarily be measured via benchmark harnesses and regression 31 | analyses. 32 | 33 | # Introduction 34 | 35 | The cost of analyzing Clarity code is measured using the same 5 categories 36 | described in SIP-006 for the measurement of execution costs: 37 | 38 | 1. Runtime cost: captures the number of cycles that a single 39 | processor would require to process the Clarity block. This is a 40 | _unitless_ metric, so it will not correspond directly to cycles, 41 | but rather is meant to provide a basis for comparison between 42 | different Clarity code blocks. 43 | 2. Data write count: captures the number of independent writes 44 | performed on the underlying data store (see SIP-004). 45 | 3. Data read count: captures the number of independent reads 46 | performed on the underlying data store. 47 | 4. Data write length: the number of bytes written to the underlying 48 | data store. 49 | 5. Data read length: the number of bytes read from the underlying 50 | data store. 51 | 52 | Importantly, these costs are used to set a _block limit_ for each 53 | block. When it comes to selecting transactions for inclusion in a 54 | block, miners are free to make their own choices based on transaction 55 | fees, however, blocks may not exceed the _block limit_. If they do so, 56 | the block is considered invalid by the network --- none of the block's 57 | transactions will be materialized and the leader forfeits all rewards 58 | from the block. 59 | 60 | Costs for static analysis are assessed during the _type check_ pass. 61 | The read-only and trait-checking passes perform work which is strictly 62 | less than the work performed during type checking, and therefore, the 63 | cost assessment can safely fold any costs that would be incurred during 64 | those passes into the type checking pass. 65 | 66 | # Specification 67 | 68 | ## Common Analysis Metrics and Costs 69 | 70 | ### AST Parsing 71 | 72 | The Clarity parser has a runtime that is linear with respect to the Clarity 73 | program length. 74 | 75 | ``` 76 | a*X+b 77 | ``` 78 | 79 | where a and b are constants, and 80 | 81 | X := the program length in bytes 82 | 83 | ### Dependency cycle detection 84 | 85 | Clarity performs cycle detection for intra-contract dependencies (e.g., 86 | functions that depend on one another). This detection is linear in the 87 | number of dependency edges in the smart contract: 88 | 89 | ``` 90 | a*X+b 91 | ``` 92 | 93 | where a and b are constants, and 94 | X := the total number of dependency edges in the smart contract 95 | 96 | Dependency edges are created anytime a top-level definition refers 97 | to another top-level definition. 98 | 99 | ### Type signature size 100 | 101 | Types in Clarity may be described using type signatures. For example, 102 | `(tuple (a int) (b int))` describes a tuple with two keys `a` and `b` 103 | of type `int`. These type descriptions are used by the Clarity analysis 104 | passes to check the type correctness of Clarity code. Clarity type signatures 105 | have varying size, e.g., the signature `int` is smaller than the signature for a 106 | list of integers. 107 | 108 | The signature size of a Clarity type is defined as follows: 109 | 110 | ``` 111 | type_signature_size(x) := 112 | if x = 113 | int => 1 114 | uint => 1 115 | bool => 1 116 | principal => 1 117 | buffer => 2 118 | optional => 1 + type_signature_size(entry_type) 119 | response => 1 + type_signature_size(ok_type) + type_signature_size(err_type) 120 | list => 2 + type_signature_size(entry_type) 121 | tuple => 1 + 2*(count(entries)) 122 | + sum(type_signature_size for each entry) 123 | + sum(len(key_name) for each entry) 124 | ``` 125 | 126 | ### Type annotation 127 | 128 | Each node in a Clarity contract's AST is annotated with the type value 129 | for that node during the type checking analysis pass. 130 | 131 | The runtime cost of type annotation is: 132 | 133 | ``` 134 | a + b*X 135 | ``` 136 | 137 | where a and b are constants, and X is the type signature size of the 138 | type being annotated. 139 | 140 | ### Variable lookup 141 | 142 | Looking up variables during static analysis incurs a non-constant cost -- the stack 143 | depth _and_ the length of the variable name affect this cost. However, 144 | variable names in Clarity have bounded length -- 128 characters. Therefore, 145 | the cost assessed for variable lookups may safely be constant with respect 146 | to name length. 147 | 148 | The stack depth affects the lookup cost because the variable must be 149 | checked for in each context on the stack. 150 | 151 | Cost Function: 152 | 153 | ``` 154 | a*X+b*Y+c 155 | ``` 156 | 157 | where a, b, and c are constants, 158 | X := stack depth 159 | Y := the type size of the looked up variable 160 | 161 | ### Function Lookup 162 | 163 | Looking up a function incurs a constant cost with respect 164 | to name length (for the same reason as variable lookup). However, 165 | because functions may only be defined in the top-level contract 166 | context, stack depth does not affect function lookup. 167 | 168 | Cost Function: 169 | 170 | ``` 171 | a*X + b 172 | ``` 173 | 174 | where a and b are constants, 175 | X := the sum of the type sizes for the function signature (each argument's type size, as well 176 | as the function's return type) 177 | 178 | ### Name Binding 179 | 180 | The cost of binding a name in Clarity -- in either a local or the contract 181 | context is _constant_ with respect to the length of the name, but linear in 182 | the size of the type signature. 183 | 184 | ``` 185 | binding_cost = a + b*X 186 | ``` 187 | 188 | where a and b are constants, and 189 | X := the size of the bound type signature 190 | 191 | ### Type check cost 192 | 193 | The cost of a static type check is _linear_ in the size of the type signature: 194 | 195 | ``` 196 | type_check_cost(expected, actual) := 197 | a + b*X 198 | ``` 199 | 200 | where a and b are constants, and 201 | 202 | X := `max(type_signature_size(expected), type_signature_size(actual))` 203 | 204 | ### Function Application 205 | 206 | Static analysis of a function application in Clarity requires 207 | type checking the function's expected arguments against the 208 | supplied types. 209 | 210 | The cost of applying a function is: 211 | 212 | 213 | ``` 214 | a + sum(type_check_cost(expected, actual) for each argument) 215 | ``` 216 | 217 | where a is a constant. 218 | 219 | This is also the _entire_ cost of type analysis for most function calls 220 | (e.g., intra-contract function calls, most simple native functions). 221 | 222 | ### Iterating the AST 223 | 224 | Static analysis iterates over the entire program's AST in the type checker, 225 | the trait checker, and in the read-only checker. This cost is assessed 226 | as a constant cost for each node visited in the AST during the type 227 | checking pass. 228 | 229 | ## Special Function Costs 230 | 231 | Some functions require additional work from the static analysis system. 232 | 233 | ### Functions on sequences (e.g., map, filter, fold) 234 | 235 | Functions on sequences need to perform an additional check that the 236 | supplied type is a list or buffer before performing the normal 237 | argument type checking. This cost is assessed as: 238 | 239 | ``` 240 | a 241 | ``` 242 | 243 | where a is a constant. 244 | 245 | ### Functions on options/responses 246 | 247 | Similarly to the functions on sequences, option/response functions 248 | must perform a simple check to see if the supplied input is an option or 249 | response before performing additional argument type checking. This cost is 250 | assessed as: 251 | 252 | ``` 253 | a 254 | ``` 255 | 256 | ### Data functions (ft balance checks, nft lookups, map-get?, ...) 257 | 258 | Static checks on intra-contract data functions do not require database lookups 259 | (unlike the runtime costs of these functions). Rather, these functions 260 | incur normal type lookup (i.e., fetching the type of an NFT, data map, or data var) 261 | and type checking costs. 262 | 263 | ### get 264 | 265 | Checking a tuple _get_ requires accessing the tuple's signature 266 | for the specific field. This has runtime cost: 267 | 268 | ``` 269 | a*log(N) + b 270 | ``` 271 | where a and b are constants, and 272 | 273 | N := the number of fields in the tuple type 274 | 275 | ### tuple 276 | 277 | Constructing a tuple requires building the tuple's BTree for 278 | accessing fields. This has runtime cost: 279 | 280 | 281 | ``` 282 | a*N*log(N) + b 283 | ``` 284 | where a and b are constants, and 285 | 286 | N := the number of fields in the tuple type 287 | 288 | ### use-trait 289 | 290 | Importing a trait imposes two kinds of costs on the analysis. 291 | First, the import requires a database read. Second, the imported 292 | trait is included in the static analysis output -- this increases 293 | the total storage usage and write length of the static analysis. 294 | 295 | The costs are defined as: 296 | 297 | ``` 298 | read_count = 1 299 | write_count = 0 300 | runtime = a*X+b 301 | write_length = c*X+d 302 | read_length = c*X+d 303 | ``` 304 | 305 | where a, b, c, and d are constants, and 306 | 307 | X := the total type size of the trait (i.e., the sum of the 308 | type sizes of each function signature). 309 | 310 | ### contract-call? 311 | 312 | Checking a contract call requires a database lookup to inspect 313 | the function signature of a prior smart contract. 314 | 315 | The costs are defined as: 316 | 317 | ``` 318 | read_count = 1 319 | read_length = a*X+b 320 | runtime = c*X+d 321 | ``` 322 | 323 | where a, b, c, and d are constants, and 324 | 325 | X := the total type size of the function signature 326 | 327 | ### let 328 | 329 | Let bindings require the static analysis system to iterate over 330 | each let binding and ensure that they are syntactically correct. 331 | 332 | This imposes a runtime cost: 333 | 334 | ``` 335 | a*X + b 336 | ``` 337 | where a and b are constants, and 338 | 339 | X := the number of entries in the let binding. 340 | 341 | # Related Work 342 | 343 | This section will be expanded upon after this SIP is ratified. 344 | 345 | # Backwards Compatibility 346 | 347 | Not applicable. 348 | 349 | # Activation 350 | 351 | At least 20 miners must register a name in the `.miner` namespace in Stacks 1.0. 352 | Once the 20th miner has registered, the state of Stacks 1.0 will be snapshotted. 353 | 300 Bitcoin blocks later (Bitcoin block 666050), the Stacks 2.0 blockchain will launch. Stacks 2.0 354 | implements this SIP. 355 | 356 | # Reference Implementations 357 | 358 | Implemented in Rust. See https://github.com/blockstack/stacks-blockchain. 359 | 360 | -------------------------------------------------------------------------------- /sips/sip-029/sip-029-halving-alignment.md: -------------------------------------------------------------------------------- 1 | # Preamble 2 | 3 | **SIP Number:** 029 4 | 5 | **Title:** Preserving Economic Incentives During Stacks Network Upgrades 6 | 7 | **Authors:** 8 | - Alex Miller (alex@hiro.so) 9 | - Andre Serrano (andre@bitcoinl2labs.com) 10 | - Brittany Laughlin (brittany@lattice.vc) 11 | - Jesse Wiley (jesse@stacks.org) 12 | - Jude Nelson (jude@stacks.org) 13 | - Philip De Smedt (philip@stackingdao.com) 14 | - Tycho Onnasch (tycho@zestprotocol.com) 15 | - Will Corcoran (will@stacks.org) 16 | 17 | **Consideration:** Economics, Technical, Governance 18 | 19 | **Type:** Consensus (hard fork) 20 | 21 | **Status:** Ratified 22 | 23 | **Created:** 2024-11-06 24 | 25 | **License:** BSD 2-Clause 26 | 27 | **Sign-off:** 28 | - j2p2 i.digg.tech@gmail.com (SIP Editor) 29 | - Mike Cohen mjoecohen@gmail.com (Technical CAB) 30 | - Jason Schrader jason@joinfreehold.com (Governance CAB) 31 | - MattySTX mattystx@gmail.com (Economics CAB) 32 | 33 | **Discussions-To:** 34 | - Stacks Forum Post: [Aligning with Bitcoin Halving and Incentives after Nakamoto](https://forum.stacks.org/t/aligning-with-bitcoin-halving-and-incentives-after-nakamoto/17668) 35 | 36 | 37 | # Abstract 38 | 39 | The first Stacks halving is expected to take place 210,384 Bitcoin blocks after the Stacks 2.0 starting height, 666,050, which is Bitcoin height 876,434, which is set to occur during Reward Cycle 100 in December 2024, cutting the STX block reward from 1,000 STX to 500 STX. This SIP proposes a modification to the emissions schedule given that the network is going through two major launches (Nakamoto and sBTC) which rely on predictable economic incentives. The proposed schedule modification and associated STX emission rate would create time for Nakamoto and sBTC to launch and settle in, but, being mindful of supply, would still result in an overall reduced target 2050 STX supply (0.77% lower) and a reduced tail emission rate (50% lower). 40 | 41 | # License and Copyright 42 | 43 | This SIP is made available under the terms of the BSD-2-Clause license, 44 | available at https://opensource.org/licenses/BSD-2-Clause. This SIP’s copyright 45 | is held by the Stacks Open Internet Foundation. 46 | 47 | # Introduction 48 | 49 | STX halvings were originally designed to happen every 4 years, similar to Bitcoin. The first Stacks halving is expected to take place at Bitcoin block 876,434, which is set to occur during Reward Cycle 100 in December 2024, cutting the STX block reward from 1,000 STX to 500 STX, thereby significantly altering the economic incentives of mining on the Stacks blockchain. At the same time, the Stacks network is going through two major upgrades/changes, both of which are highly dependent on economic incentives. 50 | 51 | First, the role of Stackers is changing. The role of Stackers in the Nakamoto blockchain (SIP-021) differs from their role in the original Stacks blockchain in that they must now collectively sign Stacks blocks. This is required to prevent Stacks forks from arising, and to secure the chain tip before it can be fully anchored to the Bitcoin chain. This also means that Stackers must run and maintain signing nodes with high availability in order to ensure that blocks always reach the requisite signature threshold. The PoX payouts (SIP-007) granted to Stackers by miners provide a positive monetary incentive for Stackers to carry out this task. 52 | 53 | Second, the release of the Nakamoto blockchain unblocks sBTC (SIP-028), a wrapped Bitcoin asset on the Stacks blockchain which benefits from Nakamoto’s newfound resistance to forks. Because inducing a chain reorganization (a reorg) in Nakamoto is at least as hard as doing so in the Bitcoin blockchain, applications can rely on Nakamoto to ensure that each sBTC token is backed 1:1 by a BTC token – there is no feasible way to double-spend sBTC through a Stacks blockchain reorg. 54 | 55 | Because of how important both of these upgrades are to the future of the Stacks blockchain and the dependency of all blockchains on economic incentives for security, changing the incentives while the system is going through a transition could have negative impacts. In particular, given that miners bid BTC in order to win the STX coinbase reward (and that BTC is what provides PoX payouts for Signers), it is highly likely that a 50% reduction in the STX coinbase reward would lead to a corresponding 50% reduction in PoX payouts, thereby dramatically decreasing incentives for signers while Nakamoto and sBTC are gaining adoption. Additionally, as discussed in the 7th Avenue Group report [1][2], by reducing the gross value of the block rewards and corresponding PoX payouts, it is likely that some miners and signers may choose to cease their work on the Stacks blockchain, reducing competition and economics further. 56 | 57 | While ultimately halvings do need to happen, for those reasons, it would be highly preferable to not change the economic incentives until both Nakamoto and sBTC have been live for some time, as well as to have reductions in the STX block reward happen at the same time as reductions in the BTC block reward given their links. 58 | 59 | Therefore, this SIP proposes altering the token emission schedule to preserve the existing incentive structure while ensuring no increase in the 2050 target supply, and incorporating these principles: 60 | 61 | * All STX holders would see a reduced 2050 target STX supply by 0.77%, thereby making STX more scarce 62 | * All STX holders would see a reduced tail inflation (from 125 STX to 62.5 STX) after the final halving 63 | * Stacks miners and signers’ economic incentives would remain consistent with the existing incentives for the next 16 months 64 | * The new Stacks halving schedule would align with Bitcoin halvings starting in 2028 to strengthen the connection the Stacks L2 has to Bitcoin and also synchronize the economic adjustments of both assets, reducing changes in incentives for miners and signers at each halving, as further outlined in the Forum post [3] 65 | 66 | # Specification 67 | 68 | Applying these upgrades to the Stacks blockchain requires a consensus-breaking network upgrade, in this case, a hard fork. Like other such changes, this will require a new Stacks epoch. In this SIP, we will refer to this new epoch as Stacks 3.1. 69 | 70 | The _current_ STX emission schedule is presented as follows. Note that the **first STX halving is in December 2024**. The tail emission after the final halving in 2032 would be 125 STX per block. 71 | 72 | | Coinbase Reward Phase | Bitcoin Height | Approx Date | STX Supply at Block | STX Reward | Annual Inflation | 73 | |--------------------|----------------|----------------------|-------------------|------------|-----------------| 74 | | Current | 870,100 | - | 1,552,452,847 | 1000 | - | 75 | | 1st | 876,434 | Dec 2024 | 1,558,786,847 | 500 (50%) | 3.37% | 76 | | 2nd | 1,086,818 | Dec 2028 | 1,663,978,847 | 250 (50%) | 1.58% | 77 | | 3rd | 1,297,202 | Dec 2032 | 1,716,574,847 | 125 (50%) | 0.77% | 78 | | - | 2,197,560 | Jan 2050 (17.08y) | 1,829,119,597 | 125 (0%) | 0.36% | 79 | 80 | 81 | The _proposed_ STX emission schedule is presented as follows. In particular, this SIP proposes preserving the 1000 STX coinbase until April 2026. After this, there would be a halving to 500 STX after two years, aligning the remaining Stacks halving block heights with Bitcoin's halving schedule. Four years later, emissions halve again to 125 STX, and the tail emission after the final halving in 2036 would be 62.5 STX. This brings the total supply in 2050 to 1,804,075,347, or about 0.77% lower than the original 1,818,000,000 estimate. 82 | 83 | | Coinbase Reward Phase | Bitcoin Height | Approx Date | STX Supply at Block | STX Reward | Annual Inflation | 84 | |--------------------|----------------|---------------------|-------------------|------------|-----------------| 85 | | Current | 870,100 | - | 1,552,452,847 | 1000 | - | 86 | | 1st | 945,000 | Apr 2026 (+1.33y) | 1,627,352,847 | 500 (50%) | 3.23% | 87 | | 2nd | 1,050,000 | Apr 2028 (2y) | 1,679,852,847 | 250 (50%) | 1.57% | 88 | | 3rd | 1,260,000 | Apr 2032 (4y) | 1,732,352,847 | 125 (50%) | 0.76% | 89 | | 4th | 1,470,000 | Apr 2036 (4y) | 1,758,602,847 | 62.5 (50%) | 0.37% | 90 | | - | 2,197,560 | Jan 2050 (13.83y) | 1,804,075,347 | 62.5 (0%) | 0.18% | 91 | 92 | 93 | With these changes, miner incentives and PoX yield remain unchanged for another 16 months, which we believe is sufficient time for the nascent Nakamoto signer set to develop into a set of stable, professional block signers, and for the sBTC project to attract sufficient initial liquidity. 94 | 95 | The model for both the current and proposed emissions schedules can be found in the SIP-029 Stacks Emission Model[4]. 96 | 97 | # Related Work 98 | 99 | While many blockchain protocols implement token emission schedules with periodic reductions in block rewards, we are not aware of any precedent for modifying an emission schedule specifically to maintain economic incentives during major protocol upgrades. 100 | 101 | # Backwards Compatibility 102 | 103 | This change requires a hard fork of the Stacks blockchain 104 | 105 | # Activation 106 | 107 | ## Voting Timeline 108 | 109 | Voting will begin at bitcoin block height 870,750, which occurs ~ Sunday, November 17th, 2024. 110 | Voting will conclude at bitcoin block height 872,750, which occurs ~ Sunday, December 1st, 2024. 111 | 112 | ## Activation 113 | 114 | The SIP-029 STX emission schedule is designed to activate on Stacks 3.0 as defined in [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md). The SIP-029 emission schedule will be active starting at bitcoin block height 875,000, which is in the middle of stacking cycle 99. 115 | 116 | ### Process of Activation 117 | 118 | Users can vote to approve this SIP with either their locked/stacked STX or with unlocked/liquid STX, or both. The SIP voting page can be found at [stx.eco](https://stx.eco). The criteria for the stacker and non-stacker voting is as follows. 119 | 120 | #### To Vote: 121 | 122 | In order for this SIP to activate, the following criteria must be met: 123 | 124 | - At least 80 million stacked STX must vote, with at least 80% of all stacked STX committed by voting must be in favor of the proposal (vote "yes"). 125 | - At least 80% of all liquid STX committed by voting must be in favor of the proposal (vote "yes"). 126 | 127 | The voting addresses will be: 128 | 129 | | Vote | Bitcoin Address | Stacks Address | Msg | ASCII-encoded msg | Bitcoin script | 130 | | - | - | - | - | - | - | 131 | | yes | `11111111111mdWK2VXcrA1e7in77Ux` | `SP00000000001WPAWSDEDMQ0B9J76GZNR3T` | `yes-sip-29` | `000000000000000000007965732d7369702d3239` | `OP_DUP` `OP_HASH160` `000000000000000000007965732d7369702d3239` `OP_EQUALVERIFY` `OP_CHECKSIG` | 132 | | no | `111111111111ACW5wa4RwyeKgtEJz3` | `SP000000000006WVSDEDMQ0B9J76NCZPNZ` | `no-sip-29` | `00000000000000000000006e6f2d7369702d3239` | `OP_DUP` `OP_HASH160` `00000000000000000000006e6f2d7369702d3239` `OP_EQUALVERIFY` `OP_CHECKSIG` | 133 | 134 | The addresses have been generated as follows: 135 | 136 | - Encode `` in ASCII, with 0-padding. 137 | - Use the resulting `` in the Bitcoin script`OP_DUP` `OP_HASH160` `` `OP_EQUALVERIFY` `OP_CHECKSIG`. 138 | - The Bitcoin address is the `base58check` of the hash of the Bitcoin script above. 139 | - The Stacks address is the `c32check-encoded` message. 140 | 141 | All STX holders vote by sending Stacks dust to the corresponding Stacks address from the account where their Stacks are held (stacked or liquid). To simplify things, user's can create their votes by visiting the [stx.eco](https://stx.eco/) platform. Voting power is determined by a snapshot of the amount of STX (stacked and un-stacked) at the block height at which the voting started (preventing the same STX from being transferred between accounts and used to effectively double vote). 142 | 143 | Solo stackers only can also vote by sending a bitcoin dust transaction (6000 sats) to the corresponding bitcoin address. 144 | 145 | #### For Miners 146 | 147 | There is only one criterion for miners to activate this SIP: they must mine the Stacks blockchain up to and past the end of the voting period (bitcoin block height 872,750). In all reward cycles between cycle 97 & 98 and the end of the voting period, PoX must activate. 148 | 149 | # Reference Implementation 150 | 151 | The reference implementation can be found at https://github.com/stacks-network/stacks-core/pull/5461. 152 | 153 | # References 154 | 155 | [1] Soslow, J (2023) Review of Mining Emissions and Risks of the Halving. Available at https://stx.is/emissions-report-1 [Verified 5 November 2024] 156 | 157 | [2] Soslow, J (2023) Halving Proposals. Available at https://stx.is/emissions-report-1 [Verified 5 November 2024] 158 | 159 | [3] Laughlin, B (2024) Aligning with Bitcoin Halving and Incentives after Nakamoto. [Online forum post] forum.stacks.org https://forum.stacks.org/t/aligning-with-bitcoin-halving-and-incentives-after-nakamoto/17668 [Verified 5 November 2024] 160 | 161 | [4] Müffke, F & Corcoran, W (2024) SIP-029 Stacks Emission Model. [Online spreadsheet] docs.google.com https://docs.google.com/spreadsheets/d/1ZRQgQV99kWvcSjkmZWKgldflcB2ytaN6sjo2RiHcjnk/edit?gid=0#gid=0 [Verified 13 November 2024] 162 | --------------------------------------------------------------------------------