Signum Improvement Proposals (SIPs) describe standards for the Signum platform, including core protocol specifications, client APIs, and contract standards.
Before you initiate a pull request, please read the SIP-Basics process document. There is a template SIP here.
If you use your email address, that address must be the one publicly shown on your GitHub profile.
The Signum Improvement Proposals repository exists as a place to share concrete proposals with potential users of the proposal and the Signum community at large.
- Idea - An idea that is pre-draft. This is not tracked within the SIP Repository.
- Draft - The first formally tracked stage of an SIP in development.
- Review - An SIP Author marks an SIP as ready for and requesting Peer Review.
- Last Call - This is the final review window for an SIP before moving to FINAL. An SIP editor will assign Last Call status and set a review end date (
last-call-deadline), typically 14 days later. If this period results in necessary normative changes it will revert the SIP to Review. - Final - This SIP represents the final standard. A Final SIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
- Stagnant - Any SIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. A SIP may be resurrected from this state by Authors or SIP Editors through moving it back to Draft.
- Withdrawn - The SIP Author(s) have withdrawn the proposed SIP. This state has finality and can no longer be resurrected using this SIP number. If the idea is pursued at later date it is considered a new proposal.
- Living - A special status for SIPs that are designed to be continually updated and not reach a state of finality. This includes most notably SIP-Basics.
SIPs are separated into a number of types:
Improvements requiring a consensus fork
Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs.
Application-level standards and conventions, including contract standards such as smart contracts
Describes a Signum design issue, or provides general guidelines or information to the Signum community, but does not propose a new feature. Informational SIPs do not necessarily represent Signum community consensus or a recommendation, so users and implementers are free to ignore Informational SIPs or follow their advice.
| SIP | Type | Category | Title | Status | Implemented |
|---|---|---|---|---|---|
| Basic | Informational | - | SIP Purpose and Guidelines | Living | |
| 1 | Standard | Interface | Dynamic BRS Node Capabilities | Final | yes |
| 2 | Standard | Core | Quadruple Block Size | Final | yes |
| 3 | Standard | Core | Variable Slot-based Fees | Final | yes |
| 4 | Standard | Core | Multi-Out Transactions | Final | yes |
| 5 | Standard | Core | PoC2 | Final | yes |
| 6 | Standard | Interface | Unconfirmed Tx Queue Optimizations | Final | yes |
| 7 | Standard | Interface | Differential Unconfirmed Tx Propagation | Final | yes |
| 8 | Informational | - | Define Tx and Balance "Dust" | Stagnant | no |
| 9 | Informational | - | To-All Transactions | Stagnant | no |
| 10 | Standard | Core | Anchor Real-World Data in Blockchain | Stagnant | no |
| 11 | Standard | Core | Tethered Assets | Stagnant | no |
| 12 | Informational | - | SFS | Stagnant | no |
| 13 | Standard | Interface | Suggested Transaction Fees | Final | yes |
| 14 | Standard | Interface | Signum Actions through Deeplink QR-codes | Final | yes |
| 15 | Standard | Core | RWFDS-enabled FEE_QUANT introspection and adjustment | Draft | no |
| 16 | Informational | - | PoC2.X16 - A New Optimized Plot File Format | Final | yes |
| 17 | Standard | Interface | Differential UT Propagation in push & pull | Final | yes |
| 18 | Informational | - | Cross-Platform Wallet UI | Final | yes |
| 19 | Standard | Interface | Incoming Multi-Out Tracking | Final | yes |
| 20 | Standard | Core | Updated AT fees | Final | yes |
| 21 | Standard | Core | Adjustment for Asset-Issuance fee | Final | yes |
| 22 | Standard | SRC | Deep Link Specification | Final | yes |
| 23 | Standard | Core | Enforce slot fees | Final | yes |
| 24 | Standard | Core | New deadline algorithm based on a logarithm transformation | Final | yes |
| 25 | Standard | Core | Minor Network Changes | Final | yes |
| 26 | Standard | Interface | Extended Reed Solomon Address Format | Final | yes |
| 27 | Standard | Core | Proof of Commitment (PoC+) consensus | Final | yes |
| 28 | Standard | Core | Updated AT max steps and AT API | Final | yes |
| 29 | Standard | Core | Mininum mining incentives | Final | yes |
| 30 | Standard | Core | Green Contracts | Final | yes |
| 31 | Standard | Core | New fee framwork | Final | yes |
| 32 | Standard | Core | PoC+ polishing | Final | yes |
| 33 | Standard | Core | Smart Tokens | Final | yes |
| 34 | Standard | Core | Round minimum fee to 2 digits | Final | yes |
| 35 | Standard | Core | Cashback | Final | yes |
| 36 | Standard | Core | Distribution of node-related fees (smart contract and similar) | Final | yes |
| 37 | Standard | Core | General smart contract upgrade | Final | yes |
| 38 | Standard | Core | Map support for smart contracts | Final | yes |
| 39 | Standard | Core | Smart token support for smart contracts | Final | yes |
| 40 | Standard | SRC | Signum NFT specifications | Final | yes |
| 41 | Standard | Core | Smart Tokens Distribution Changes | Final | yes |
| 42 | Standard | Core | Subscription behaviour enhancement | Final | no |
| 43 | Standard | Core | Introduce Smart Token Owner | Final | yes |
| 44 | Standard | SRC | Descriptor | Final | yes |
| 45 | Standard | SRC | Staking Contracts | Final | yes |
| 46 | Standard | SRC | Secure solo mining setup | Final | yes |
| 47 | Standard | SRC | URI Resolution (SNS) | Review | no |
| 48 | Standard | Core | Modernize the Alias frameworks | Final | yes |
| 49 | Standard | SRC | Liquidity Pool Contracts | Review | yes |
| 50 | Standard | SRC | WebSocket API | Review | yes |