Conversation
KBryan
commented
Nov 28, 2025
KBryan
commented
- A SIP for the Stacks ecosystem inspired by ERC-8001
* A SIP for the Stacks ecosystem inspired by ERC-8001
|
Just wanna add related ERCs links:
|
|
Awesome job getting this started! We chatted a bit about this in the AIBTC Discord It would be helpful to initialize clarinet with this contract code and create at least some relevant unit tests. Using You'll find resources on the Clarity language, Clarinet, the Clarinet SDK, and Rendezvous in the Stacks documentation. |
|
Actually while it's good to have the code here as a reference probably better to have a separate example repo for all that I listed. Hold tight - I have an idea! 💡 |
|
Very interesting |
|
I'll continue this conversation on Discord. Clarity isn't my primary language, and I will rely on the AIBTC to address any gaps in this proposal. |
Can we maybe also get it into the Stacks Forum here: https://forum.stacks.org/ ??? |
|
Used the ERC-8001 website text, the SIP text, Stacks docs, and Clarity tips from over the years to make the clarity reference in Started as an experiment to get the LLM to write better Clarity code. It improved the output with the extra context but still had to hand-hold it through some specific issues like incorrect keywords or Tests are a WIP I kept running into issues with OpenRouter returning short responses so iterations took a bit longer. It chokes a bit on simnet and Clarinet usage too but this should help get things closer (I think?) Direct link to CLARITY_REFERENCE.md document used with LLM: |
|
Maybe see if we could 'vibe' 8004 for SIP using the same process? 👀 |
|
Nice work @whoabuddy, going to get this setup today. |
|
I have an issue with Clarity 4. I want to use the new timestamp. |
|
@whoabuddy and @Hero-Gamer first deployment of ERC-8001 on Stacks. I personally don't like this moniker. At what point does one get assigned an official SIP # |
* Update contracts based on whoabuddy's template. * I want to take advantage of Clarity 4's timestamp. I will need to return to this later.
|
@KBryan excited to see this come to life on Stacks |
|
@KBryan curious how things are going, any blockers at this point? where are we at in the process? did you get your Clarity questions resolved? |
|
@whoabuddy, things have been going well, and thanks for checking in. ERC-8001 reached final status, and I want to get back to working on this SIP. The process is different from on Ethereum, and I haven't gotten any review on what I need to change or edit. How does this process work? Is there a reviewer who can give more insight? |
cannot confirm or deny i'm working on this also @Hero-Gamer can you hook @KBryan up with next steps? you had cool graphics and explainers and what-not I'll likely have similar questions if I get the 8004 variant out the door and they are both cross-chain designs so would be good to go through process near the same time |
wileyj
changed the title
|
@KBryan can you remove the |
* Revisions based on Stacks SIP proposal initial review.
|
@wileyj, revisions have been made based on your suggestions. @whoabuddy added you as a collaborator. |
sips/sip-037/sip-037.md
Outdated
| @@ -0,0 +1,154 @@ | |||
| # Preamble | |||
|
|
|||
| SIP Number: SIP-037 | |||
There was a problem hiding this comment.
| SIP Number: SIP-037 | |
| SIP Number: 037 |
small change - SIP isn't needed, only the number
There was a problem hiding this comment.
Sounds good, revised in the latest commit.
* Revised SIP number in preamble
.gitignore
Outdated
There was a problem hiding this comment.
Please remove this file from the PR (possibly added by mistake) 🙏
There was a problem hiding this comment.
@KBryan to be clear, i didn't mean to delete the file - just to revert the changes you made in your branch 😉 .
we want to keep .gitignore, but changes to that file should happen in a normal PR not related to a specific SIP (unless there's a strong case for doing so, which i don't think applies here).
| Created: 28 November 2025 | ||
| Licence: CC0-1.0 (Creative Commons Zero v1.0 Universal) | ||
| Sign-off: *(pending)* |
There was a problem hiding this comment.
| Created: 28 November 2025 | |
| Licence: CC0-1.0 (Creative Commons Zero v1.0 Universal) | |
| Sign-off: *(pending)* | |
| Created: 28 November 2025 | |
| Layer: Applications | |
| Licence: CC0-1.0 (Creative Commons Zero v1.0 Universal) | |
| Sign-off: *(pending)* |
I'm thinking this should be layer Applications, but please correct me if i'm incorrect.
|
|
||
| ## Data Structures | ||
|
|
||
| **Agent Intent:** The core message posted by an initiator describing the coordination request. It is a tuple of fields: |
There was a problem hiding this comment.
Formatting:
| **Agent Intent:** The core message posted by an initiator describing the coordination request. It is a tuple of fields: | |
| ### Agent Intent | |
| The core message posted by an initiator describing the coordination request. It is a tuple of fields: | |
| - `coordinationValue` (`uint`): An optional value field (e.g. an amount in micro-STX or an abstract value) that is informational for the core protocol. The core standard does not assign meaning to this field, but higher-level modules MAY use it (for example, to require a bond or to encode an expected payment amount). | ||
| - `participants` (`list(principal)`): The list of all participants’ principals involved in this intent, **including the initiator** (`agentId`). This list MUST be strictly ascending (sorted) by principal and contain no duplicates. Ordering the addresses canonically ensures everyone computes the same intent hash and prevents duplicate signers. | ||
|
|
||
| **Acceptance Attestation:** A participant’s acceptance of an intent. It is represented by: |
There was a problem hiding this comment.
Formatting:
| **Acceptance Attestation:** A participant’s acceptance of an intent. It is represented by: | |
| ### Acceptance Attestation: | |
| A participant’s acceptance of an intent. It is represented by: | |
| - `conditionsHash` (`buff 32`): A hash of any participant-specific conditions for their acceptance. This field is optional and not interpreted by the base contract logic. It might encode constraints like “price must be above X” or other domain-specific requirements that the participant expects to be true at execution. If no extra conditions, this can be a zero hash (all 0x00 bytes). | ||
| - `signature` (`buff 64/65`): The participant’s digital signature over the intent. This is the Secp256k1 ECDSA signature (65 bytes including recovery ID, or 64-byte compact form per EIP-2098) that proves the participant indeed signed the `intentHash` (and associated domain). | ||
|
|
||
| **Coordination Payload:** (Optional in core) The full data that `payloadHash` represents. The structure of this payload is outside the scope of SIP-037, as it is application-specific. However, by convention it could include fields like `version` (a format identifier), `coordinationType` (MUST equal the above type for redundancy), `coordinationData` (opaque binary or structured commands to execute), `conditionsHash` (the combined conditions for execution), `timestamp` (when the intent was created), and `metadata`. These are not processed by the core contract, but hashing them into `payloadHash` ensures that all participants are agreeing to the exact same details. |
There was a problem hiding this comment.
Formatting:
| **Coordination Payload:** (Optional in core) The full data that `payloadHash` represents. The structure of this payload is outside the scope of SIP-037, as it is application-specific. However, by convention it could include fields like `version` (a format identifier), `coordinationType` (MUST equal the above type for redundancy), `coordinationData` (opaque binary or structured commands to execute), `conditionsHash` (the combined conditions for execution), `timestamp` (when the intent was created), and `metadata`. These are not processed by the core contract, but hashing them into `payloadHash` ensures that all participants are agreeing to the exact same details. | |
| ### Coordination Payload: | |
| (Optional in core) The full data that `payloadHash` represents. The structure of this payload is outside the scope of SIP-037, as it is application-specific. However, by convention it could include fields like `version` (a format identifier), `coordinationType` (MUST equal the above type for redundancy), `coordinationData` (opaque binary or structured commands to execute), `conditionsHash` (the combined conditions for execution), `timestamp` (when the intent was created), and `metadata`. These are not processed by the core contract, but hashing them into `payloadHash` ensures that all participants are agreeing to the exact same details. |
There was a problem hiding this comment.
Please add the missing Activation section, and there should be some text about why the ./tests folder is included as supplemental material (perhaps in the same section where the example contract is linked).
remove .gitignore
6 participants
