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
Copy file name to clipboardExpand all lines: LSPs/LSP-20-CallVerification.md
+16-12Lines changed: 16 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,20 +27,23 @@ Delegating the function call requirements to another smart contract enables a mo
27
27
28
28
## Specification
29
29
30
-
There are two distinct contracts involved in the Call Verification standard, each playing a different role in achieving the desired functionality: the contract that receives the initial function call and asks the verifier contract for verification and the verifier contract that handles the actual verification process.
30
+
There are two distinct contracts involved in the LSP20 Call Verification standard, each playing a different role in achieving the desired functionality:
31
31
32
-
The contract receiving the function call and calling a verifier contract MUST support the `LSP20-CallVerification` interfaceId: `0x1a0eb6a5`, calculated as the first 4 bytes of the keccak256 hash of the string `"LSP20CallVerification"`. This interface ensures that the required behavior is available for performing the necessary verifications.
32
+
- the contract that receives the initial function call (**LSP20-CallVerification**) and asks the verifier contract for verification.
33
+
- the verifier contract (**LSP20-CallVerifier**) that handles the actual verification process.
33
34
34
-
The verifier contract receiving the verification call MUST support the `LSP20-CallVerifier` interfaceId: `0xc9dfc532`, calculated as the XOR of the functions mentioned below.
35
+
The contract receiving the function call and calling a verifier contract MUST support the **LSP20-CallVerification** interfaceId: `0x1a0eb6a5`, calculated as the first 4 bytes of the keccak256 hash of the string `"LSP20CallVerification"`. This interface ensures that the required behavior is available for performing the necessary verifications.
36
+
37
+
The verifier contract receiving the verification call MUST support the `LSP20-CallVerifier` interfaceId: `0x0d6ecac7`, calculated as the XOR of the functions mentioned below.
35
38
36
39
### Methods
37
40
38
-
Smart contracts implementing the LSP20-CallVerifier interfaceId SHOULD implement both of the functions listed below:
41
+
Smart contracts implementing the **LSP20-CallVerifier** interfaceId SHOULD implement both of the functions listed below:
@@ -49,7 +52,8 @@ It can be used to run any form of verification mechanism **prior to** running th
49
52
50
53
_Parameters:_
51
54
52
-
-`callee`: The address of the contract that implements the LSP20 interface.
55
+
-`requestor`: The address that requested to make the call to `target`.
56
+
-`target`: The address of the contract that implements the `LSP20CallVerification` interface.
53
57
-`caller`: The address who called the function on the contract delegating the verification mechanism.
54
58
-`value`: The value sent by the caller to the function called on the contract delegating the verification mechanism.
55
59
-`receivedCalldata`: The calldata sent by the caller to the contract delegating the verification mechanism.
@@ -61,9 +65,9 @@ _Returns:_
61
65
_Requirements_
62
66
63
67
- the `bytes4` success value returned MUST be of the following format:
64
-
- the first 3 bytes MUST be the `lsp20VerifyCall(..)` function selector = this determines if the call to the function is allowed.
68
+
- the first 3 bytes MUST be the `lsp20VerifyCall(address,address,address,uint256,bytes)` function selector. This determines if the call to the function is allowed or not.
65
69
- any value for the last 4th byte is accepted.
66
-
- if the 4th byte is `0x01`, this determines if the `lsp20VerifyCallResult(..)` function should be called after the original function call (The byte that invokes the `lsp20VerifyCallResult(..)` function is strictly `0x01`).
70
+
- if the 4th byte is `0x01`, this determines if the `lsp20VerifyCallResult(bytes32,bytes)` function should be called after the original function call (The byte that invokes the `lsp20VerifyCallResult(bytes32,bytes)` function is strictly `0x01`).
67
71
68
72
#### lsp20VerifyCallResult
69
73
@@ -77,7 +81,7 @@ It can be used to run any form of verification mechanism after having run the ac
77
81
78
82
_Parameters:_
79
83
80
-
-`callHash`: The keccak256 of the parameters of `lsp20VerifyCall(..)` parameters packed-encoded (concatened).
84
+
-`callHash`: The keccak256 hash of the parameters of `lsp20VerifyCall(address,address,address,uint256,bytes)` parameters packed-encoded (concatened).
81
85
-`callResult`: the result of the function being called on the contract delegating the verification mechanism.
82
86
- if the function being called returns some data, the `callResult` MUST be the value returned by the function being called as abi-encoded `bytes`.
83
87
- if the function being called does not return any data, the `callResult` MUST be an empty `bytes`.
@@ -88,7 +92,7 @@ _Returns:_
88
92
89
93
_Requirements_
90
94
91
-
- MUST return the `lsp20VerifyCallResult(..)` function selector if the call to the function is allowed.
95
+
- MUST return the `lsp20VerifyCallResult(bytes32,bytes)` function selector if the call to the function is allowed.
92
96
93
97
### Handling Verification Result
94
98
@@ -122,7 +126,7 @@ An implementation can be found in the [lukso-network/lsp-smart-contracts] reposi
0 commit comments