You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 5, 2021. It is now read-only.
Dapp is using the Authenticator to ask wallet_signTypedData.
The extension publishes "signTypedData" extension to the app
App displays the "Signature Request" screen
User taps "Sign" button
App publishes the "signTypedDataConfirmation" notification to the extension
Extension creates the contract signature according to our Safe Smart Contract specification
Extension returns the result to the dapp.
Alternative:
User taps "Cancel" button.
App publishes "rejectSignTypedData" notification
Extension cancels the process (cancellation if any of the owners rejected) [CLARIFY]
Extension returns error to the dapp.
Dapp --[WalletConnect]--> App -> Extension
Dapp is using wallet connect to ask wallet_signTypedData
App displays Signature Request" screen.
App publishes the "signTypedData" notification and waits
Extension signs the data (confirmed by user) and publishes the "signTypedDataConfirmation" notification
App collects the signature from the extension.
User taps "Sign" button to sign by the device
App creates the Gnosis Safe Contract signature according to the specification.
App returns the signature as a result of the wallet connect call.
Alternative 1:
4. User taps "Cancel" in the app
5. App publishes "rejectSignTypedData" to the extension
6. App returns error to the wallet connect request result
Alternative 2:
4. User rejects the signing in the extension.
5. Extension publishes "rejectSignTypedData"
6. App receives the rejection and updates the "Signature Request" screen.
7. User can tap "Resend" to send the signature request again.
8. Otherwise, user taps "Cancel" and the app returns error to the wallet connect request.
Data Definition
Push Notifications
Requesting to sign a message
signTypedData
payload - message to sign (bytes), hex byte string starting with 0x
safe - safe address, should be checksummed?
type - signTypedData
r - big int, stringified base 10
s - big int, stringified base 10
v - int, stringified
The sender of the notification shall create an ecdsa signature by:
Then use it to construct the push notification and publish it.
The receiver of the notification must construct the hash of the eip712-encoded payload and recover the origin from the signature and hash. The recovered origin address must be a legitimate owner of the safe otherwise, the message shall be discarded.
The receiver of the notification shall check (1) that the hash is an appropriate hash - the one for which the signing request notification signTypedData was published; (2) that the recovered address from the signature is an owner of the safe associated with the signing request.
When there are enough signatures collected (collector's signature + confirmationCount - 1), then the final contract signature is constructed by sorting signatures by their hex (non-checksummed) addresses lexicographically, and concatenating all of them into byte string.
The resulting byte string is the contract signature.
After creating the contract signature, the collector shall check it is valid by calling smart contract's isValidSignature() method. If the signature validation fails, then error shall be shown to the user.
Rejecting
rejectSignTypedData
hash: 32-byte string encoding as hexadecimal and starting with '0x'
type: rejectSignTypedData
r: big int, stringified base 10
s: big int, stringified base 10
v: big int, stringified base 10
The sender must send this notification when the user rejects the signature signing. This will abort the signing process and return "error" esult to the caller of the signTypedData method.
The sender of the notification creates the (r, s, v) the same way as in the signTypedDataConfirmation with the difference that the signature is serialized with r, s, and v values explicitly rather than in byte string.
The receiver of the notification must check that the signature is valid, that the hash is the one for which signTypedData notification was issued before (pending signature request), and that the signer's address is an owner of the safe associated with the signing request.
During the development, for testing purposes, the app shall implement the eth_signTypedData with return value that is our contract's signature, instead of the standard ecdsa signature expected by the standard.
In addition, the app shall implement the wallet_signTypedData method to spearhead the extension to the EIP-712 standard. This method shall return signatures only for the * and eip1271 signature types. The ecdsa signature type is not supported by the smart contract.
Contract Signature
Currently, the Safe SC (smart contract) defines the signature as a concatenation of owner signatures, sorted by hex owner address lexicographically.
At the same time, a valid EIP-712 signature is just one signature (r, s, v) parameters that form 129 byte string. Thus, the safe's signature is not a valid EIP-712 signature. For this purpose, Richard has started draft for EIP that would extend the EIP-712 with custom RPC request wallet_signTypedData:
Epic
5afe/safe#78
Documentation
Example Code
Flows
Dapp -> Extension -> App
Alternative:
Dapp --[WalletConnect]--> App -> Extension
Alternative 1:
4. User taps "Cancel" in the app
5. App publishes "rejectSignTypedData" to the extension
6. App returns error to the wallet connect request result
Alternative 2:
4. User rejects the signing in the extension.
5. Extension publishes "rejectSignTypedData"
6. App receives the rejection and updates the "Signature Request" screen.
7. User can tap "Resend" to send the signature request again.
8. Otherwise, user taps "Cancel" and the app returns error to the wallet connect request.
Data Definition
Push Notifications
Requesting to sign a message
signTypedData
payload
- message to sign (bytes), hex byte string starting with 0xsafe
- safe address, should be checksummed?type
-signTypedData
r
- big int, stringified base 10s
- big int, stringified base 10v
- int, stringifiedThe sender of the notification shall create an ecdsa signature by:
Then use it to construct the push notification and publish it.
The receiver of the notification must construct the hash of the eip712-encoded payload and recover the origin from the signature and hash. The recovered origin address must be a legitimate owner of the safe otherwise, the message shall be discarded.
Confirming
signTypedDataConfirmation
hash
: hexadecimal bytestring (0xabc...) - 32 bytestype
:signTypedDataConfirmation
signature
: hexadecimal bytestring (0xabc...) - 129 bytes (64 for 'r', 64 for 's', and 1 for 'v')The sender of the notification shall create an ecdsa signature in the same way as for the
signTypedData
notification.The receiver of the notification shall check (1) that the
hash
is an appropriate hash - the one for which the signing request notificationsignTypedData
was published; (2) that the recovered address from the signature is an owner of the safe associated with the signing request.When there are enough signatures collected (collector's signature + confirmationCount - 1), then the final contract signature is constructed by sorting signatures by their hex (non-checksummed) addresses lexicographically, and concatenating all of them into byte string.
The resulting byte string is the contract signature.
After creating the contract signature, the collector shall check it is valid by calling smart contract's
isValidSignature()
method. If the signature validation fails, then error shall be shown to the user.Rejecting
rejectSignTypedData
hash
: 32-byte string encoding as hexadecimal and starting with '0x'type
:rejectSignTypedData
r
: big int, stringified base 10s
: big int, stringified base 10v
: big int, stringified base 10The sender must send this notification when the user rejects the signature signing. This will abort the signing process and return "error" esult to the caller of the
signTypedData
method.The sender of the notification creates the
(r, s, v)
the same way as in thesignTypedDataConfirmation
with the difference that the signature is serialized with r, s, and v values explicitly rather than in byte string.The receiver of the notification must check that the signature is valid, that the
hash
is the one for whichsignTypedData
notification was issued before (pending signature request), and that the signer's address is an owner of the safe associated with the signing request.WalletConnect RPC
eth_signTypedData
is defined in the EIP-712.wallet_signTypedData
is defined in a draft EIPDuring the development, for testing purposes, the app shall implement the
eth_signTypedData
with return value that is our contract's signature, instead of the standard ecdsa signature expected by the standard.In addition, the app shall implement the
wallet_signTypedData
method to spearhead the extension to the EIP-712 standard. This method shall return signatures only for the*
andeip1271
signature types. Theecdsa
signature type is not supported by the smart contract.Contract Signature
Currently, the Safe SC (smart contract) defines the signature as a concatenation of owner signatures, sorted by hex owner address lexicographically.
At the same time, a valid EIP-712 signature is just one signature (r, s, v) parameters that form 129 byte string. Thus, the safe's signature is not a valid EIP-712 signature. For this purpose, Richard has started draft for EIP that would extend the EIP-712 with custom RPC request
wallet_signTypedData
:https://github.com/rmeissner/EIPs/blob/rmeissner-wallet-rpc/EIPS/eip-xxx.md#wallet_signtypeddata
There are other custom requests defined in that document.
SafeMessage
:message
of typebytes
EIP712Domain
verifyingContract
of typeaddress
The text was updated successfully, but these errors were encountered: