Skip to content

Update ERC-7754: updating the acronym to avoid negative connotation #991

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Aug 5, 2025
+35 −20
Merged

Update ERC-7754: updating the acronym to avoid negative connotation #991

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
f4e8302
ERC-7754: updating the acronym to avoid negative connotation
uni-guillaume Mar 24, 2025
9857889
Merge branch 'ethereum:master' into master
uni-guillaume Jul 23, 2025
fbe06ff
ERC-7754: adding key security detail to the TWIST verification spec
uni-guillaume Jul 23, 2025
3bb198d
ERC-7754: shortening the title
uni-guillaume Jul 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 17 additions & 17 deletions ERCS/erc-7754.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
eip: 7754
title: Tamperproof Web Immutable Transaction (TWIT)
title: Tamperproof Web Immutable Secure Transaction (TWIST)

Check failure on line 3 in ERCS/erc-7754.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble header `title` value is too long (max 44) 

error[preamble-len-title]: preamble header `title` value is too long (max 44)
 --> ERCS/erc-7754.md:3:7
  |
3 | title: Tamperproof Web Immutable Secure Transaction (TWIST)
  |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ too long
  |
  = help: see https://ethereum.github.io/eipw/preamble-len-title/

Check failure on line 3 in ERCS/erc-7754.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble header `title` value is too long (max 44) 

error[preamble-len-title]: preamble header `title` value is too long (max 44)
 --> ERCS/erc-7754.md:3:7
  |
3 | title: Tamperproof Web Immutable Secure Transaction (TWIST)
  |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ too long
  |
  = help: see https://ethereum.github.io/eipw/preamble-len-title/
Copy link
Contributor

@SamWilsn SamWilsn Jun 10, 2025

Choose a reason for hiding this comment

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

I don't really see a way to reduce the title except moving the expanded form to the abstract.

Suggested change
title: Tamperproof Web Immutable Secure Transaction (TWIST)
title: Tamperproof Extension Wallets API (TWIST)

Copy link
Contributor Author

@uni-guillaume uni-guillaume Jul 23, 2025

Choose a reason for hiding this comment

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

accepted your suggestion

description: Provides a mechanism for dapps to use the extension wallets API in a tamperproof way
author: Erik Marks (@remarks), Guillaume Grosbois (@uni-guillaume)
discussions-to: https://ethereum-magicians.org/t/erc-7754-tamperproof-web-immutable-transaction-twit/20767
Expand Down Expand Up @@ -54,7 +54,7 @@

1. The user's browser verifies the domain certificate and displays appropriate warnings if overtaken
2. The DNS record of the dapp hosts a TXT field pointing to a URL where a JSON manifest is hosted
- This file SHOULD be at a well known address such as `https://example.com/.well-known/twit.json`
- This file SHOULD be at a well known address such as `https://example.com/.well-known/twist.json`
3. The config file contains an array of objects of the form `{ id, alg, publicKey }`
4. For signed requests, the dapp first securely signs the payload with a private key, for example by submitting a request to its backend
5. The original payload, signature, and public key id are sent to the wallet via the `wallet_signedRequest` RPC method
Expand All @@ -77,10 +77,10 @@

```txt
...
TXT: TWIT=/.well-known/twit.json
TXT: TWIST=/.well-known/twist.json
```

Example TWIT manifest at `https://my-crypto-dapp.invalid.com/twit.json`:
Example TWIST manifest at `https://my-crypto-dapp.invalid.com/twist.json`:

```json
{
Expand All @@ -100,7 +100,7 @@
```json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "TWIT manifest",
"title": "TWIST manifest",
"type": "object",
"properties": {
"publicKeys": {
Expand Down Expand Up @@ -155,17 +155,17 @@

#### Signature verification

1. Upon receiving an [EIP-1193](./eip-1193.md) call, the wallet MUST check of the existence of the TWIT manifest for the `sender.tab.url` domain
1. Upon receiving an [EIP-1193](./eip-1193.md) call, the wallet MUST check of the existence of the TWIST manifest for the `sender.tab.url` domain
a. The wallet MUST verify that the manifest is hosted on the `sender.tab.url` domain
b. The wallet SHOULD find the DNS TXT record to find the manifest location
b. The wallet MAY first try the `/.well-known/twit.json` location
2. If TWIT is NOT configured for the `sender.tab.url` domain, then proceed as usual
3. If TWIT is configured and the `request` method is used, then the wallet SHOULD display a visible and actionable warning to the user
b. The wallet MAY first try the `/.well-known/twist.json` location
2. If TWIST is NOT configured for the `sender.tab.url` domain, then proceed as usual
3. If TWIST is configured and the `request` method is used, then the wallet SHOULD display a visible and actionable warning to the user
a. If the user opts to ignore the warning, then proceed as usual
b. If the user opts to cancel, then the wallet MUST cancel the call
4. If TWIT is configured and the `wallet_signedRequest` method is used with the parameters `requestPayload`, `signature` and `keyId` then:
4. If TWIST is configured and the `wallet_signedRequest` method is used with the parameters `requestPayload`, `signature` and `keyId` then:
a. The wallet MAY display a visible cue indicating that this interaction is signed
b. The wallet MUST verify that the keyId exists in the TWIT manifest and find the associated key record
b. The wallet MUST verify that the keyId exists in the TWIST manifest and find the associated key record
c. From the key record, the wallet MUST use the `alg` field and the `publicKey` field to verify `requestPayload` integrity by calling `crypto.verify(alg, key, signature, requestPayload)`
d. If the signature is invalid, the wallet MUST display a visible and actionable warning to the user
i. If the user opts to ignore the warning, then proceed to call `request` with the argument `requestPayload`
Expand All @@ -186,16 +186,16 @@
// 2. Get the manifest for the current domain
// It's possible to use RFC 8484 for the actual DNS-over-HTTPS specification, see https://datatracker.ietf.org/doc/html/rfc8484.
// However, here we are doing it with DoHjs.
// This step is optional, and you could go directly to the well-known address first at `domain + '/.well-known/twit.json'`
// This step is optional, and you could go directly to the well-known address first at `domain + '/.well-known/twist.json'`
const doh = require('dohjs');
const resolver = new doh.DohResolver('https://1.1.1.1/dns-query');

let manifestPath = '';
const dnsResp = await resolver.query(domain, 'TXT');
for (record of dnsResp.answers) {
if (!record.data.startsWith('TWIT=')) continue;
if (!record.data.startsWith('TWIST=')) continue;

manifestPath = record.data.substring(5); // This should be domain + '/.well-known/twit.json'
manifestPath = record.data.substring(5); // This should be domain + '/.well-known/twist.json'
break;
}

Expand All @@ -221,10 +221,10 @@

### Wallet UX suggestion

Similarly to the padlock icon for HTTPS, wallets should display a visible indication when TWIT is configured on a domain. This will improve the UX of the end user who will immediately be able to tell
that interactions between the dapp they are using and the wallet are secure, and this will encourage dapp developer to adopt TWIT, making the overall ecosystem more secure
Similarly to the padlock icon for HTTPS, wallets should display a visible indication when TWIST is configured on a domain. This will improve the UX of the end user who will immediately be able to tell
that interactions between the dapp they are using and the wallet are secure, and this will encourage dapp developer to adopt TWIST, making the overall ecosystem more secure

When dealing with insecure request, either because the dapp (or an attacker) uses `request` on a domain where TWIT is configured, or because the signature does not match, wallets should warn the user but
When dealing with insecure request, either because the dapp (or an attacker) uses `request` on a domain where TWIST is configured, or because the signature does not match, wallets should warn the user but
not block: an eloquently worded warning will increase the transparency enough that end user may opt to cancel the interaction or proceed with the unsafe call.

## Rationale
Expand Down
Loading