Skip to content

Conversation

@brice-stacks
Copy link
Contributor

This SIP proposes two new post-condition improvements, Originator mode, and a MAY SEND condition for NFTs.

@wileyj
Copy link
Contributor

wileyj commented Feb 11, 2026

@brice-stacks can you move the files into the expected structure?
./sips/sip-post-conds/sip-post-conds.md -> ./sips/sip-040/sip-post-conds.md

@wileyj wileyj changed the title feat: new SIP for improved post-conditions SIP-040: SIP for improved post-conditions Feb 11, 2026
brice-stacks and others added 2 commits February 11, 2026 10:06
Co-authored-by: wileyj <2847772+wileyj@users.noreply.github.com>
@brice-stacks brice-stacks requested a review from wileyj February 11, 2026 15:08
Co-authored-by: wileyj <2847772+wileyj@users.noreply.github.com>

- https://forum.stacks.org/t/improved-post-conditions/18661

# Abstract
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth mentioning that this sip is a rider for SIP-039, and if that sip is approved this one follows the same activation?

or is this SIP intended to activate separately?

Comment on lines +63 to +69
reverting to signing `Allow` mode transactions, just to make it work. This is a
very bad habit to teach our users, and we can do better. What the user really
cares about is something like, "When I call contract X, at most `m` STX and `n`
USDCx may be moved from my wallet." They don't care if contract X sends sBTC to
contract Y, which sends USDCx to contract Z, etc. `Originator` mode allows the
user to specify only the restrictions on their own assets, allowing any
movements of assets amongst other principals.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
reverting to signing `Allow` mode transactions, just to make it work. This is a
very bad habit to teach our users, and we can do better. What the user really
cares about is something like, "When I call contract X, at most `m` STX and `n`
USDCx may be moved from my wallet." They don't care if contract X sends sBTC to
contract Y, which sends USDCx to contract Z, etc. `Originator` mode allows the
user to specify only the restrictions on their own assets, allowing any
movements of assets amongst other principals.
reverting to signing `Allow` mode transactions, just to make it work. What users typically
prefer is something like, "When I call contract X, at most `m` STX and `n`
USDCx may be moved from my wallet.", and less so if contract X sends sBTC to
contract Y, which sends USDCx to contract Z, etc. `Originator` mode allows the
user to specify only the restrictions on their own assets, allowing any
movements of assets amongst other principals.

I hope i kept the intent in this section, but i felt it was important to not ascribe emotion to what users may or may not want.

The transaction encoding reserves 1-byte for the non-fungible condition code.
`MAY SEND` adds a new acceptable value for this byte, `0x12`.

## Updates to the SIP-005 Specification
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm - i wonder if we need a way to differentiate when a SIP replaces an older one -as well as- updates an existing spec. 🤔

Comment on lines +163 to +164
- This SIP will activate in epoch 3.4 together with
[SIP-clarity5](../sip-clarity5/sip-clarity5.md)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update with SIP numbers (039).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants