Skip to content

Commit 160d075

Browse files
committed
Introduce endowment:keyring.version
1 parent 7f9b039 commit 160d075

File tree

1 file changed

+87
-0
lines changed

1 file changed

+87
-0
lines changed

SIPS/sip-34.md

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
sip: 34
3+
title: endowment:keyring.version
4+
status: Draft
5+
discussions-to: https://github.com/MetaMask/SIPs/discussions/172
6+
author: Charly Chevalier (@ccharly), Daniel Rocha (@danroc)
7+
created: 2025-04-07
8+
---
9+
10+
## Abstract
11+
12+
This proposal introduces a new field, `version`, within the existing configuration object used by the `endowment:keyring`.
13+
This field will allow the versioning of the keyring API, providing the flexibility to define the current API version being used.
14+
By declaring the version in the configuration, we can implement conditional behavior in the API based on the selected version.
15+
This will allow us to modify or add new functionality in the API without breaking backward compatibility.
16+
17+
## Motivation
18+
19+
The current `endowment:keyring` configuration does not support versioning, which limits our ability to introduce breaking changes or new functionality that may require changes in behavior.
20+
Adding the `version` field allows us to version the API and define distinct behaviors based on the declared version.
21+
22+
This is useful as we want to add new fields and features that should only apply to specific versions of the API, ensuring that existing implementations relying on previous versions continue to work without modification.
23+
24+
Our current request "parsing" (within the keyring API) is strict and does not allow extra-fields. Meaning that current EVM Snaps might throw an error if we add new fields to some of our requests (even optional fields).
25+
26+
We plan to modify the `submitRequest(request)` method by adding a new `origin` field to the `request` parameter, but only for version `2` and higher.
27+
We won't forward this `origin` field for requests made with version `1` to ensure backward compatibility.
28+
29+
```json
30+
{
31+
"jsonrpc": "2.0",
32+
"id": "7c507ff0-365f-4de0-8cd5-eb83c30ebda4",
33+
"method": "keyring_submitRequest",
34+
"params": {
35+
"id": "c555de37-cf4b-4ff2-8273-39db7fb58f1c",
36+
"scope": "eip155:1",
37+
"account": "4abdd17e-8b0f-4d06-a017-947a64823b3d",
38+
"request": {
39+
"method": "eth_method",
40+
"params": [1, 2, 3]
41+
},
42+
"origin": "someOrigin"
43+
}
44+
}
45+
```
46+
47+
This system will allow us to introduce future versions in a flexible way, limiting the need for breaking changes when new features are added.
48+
49+
## Specification
50+
51+
### Language
52+
53+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" written in uppercase in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
54+
55+
### Proposed implementation
56+
57+
Add an OPTIONAL `version` field to the `endowment:keyring` configuration object.
58+
This field will be a `number` and will defaults to `1` if not provided to maintain compatibility with existing implementations.
59+
60+
```json
61+
{
62+
"endowment:keyring": {
63+
"version": 2,
64+
"allowedOrigins": [
65+
...
66+
]
67+
}
68+
}
69+
```
70+
71+
On the keyring API implementation side, we will modify our API methods to conditionally behave based on the `version`:
72+
- When `version` is set to `1`, the API will behave as it currently does.
73+
- When `version` is set to `2`, the API will allow new fields, such as the `origin` field, to be included in the request.
74+
- Future versions will allow additional features or fields to be introduced, with conditional logic to ensure backward compatibility.
75+
76+
> Example of conditional behavior in `submitRequest(request)`:
77+
> - If the `version` is `1`, the request will not include the `origin` field.
78+
> - If the `version` is `2`, the `origin` field will be added to the request.
79+
80+
This new implementation MUST ensure backward compatibility with older Snaps.
81+
- Snaps using the existing `endowment:keyring` configuration object will continue to function without modification.
82+
- New functionalities, will only be enabled for Snaps that declare `"version": 2` (or above).
83+
- As more versions are introduced, **each versions will have its own set of features or modifications, ensuring that older versions continue to operate as expected**.
84+
85+
## Copyright
86+
87+
Copyright and related rights waived via [CC0](../LICENSE).

0 commit comments

Comments
 (0)