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
* nep-14: add missing successor standard number
* *: fix links to NEP-14
It's in obsolete and we should always link to the current version.
* nep-31: fix file name
* README: fix links and descriptions of accepted standards
* README: place nep-25 properly
The list is sorted.
* nep-31: mark as accepted, add to README list
---------
Signed-off-by: Roman Khimov <[email protected]>
Copy file name to clipboardExpand all lines: nep-15.mediawiki
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ The <code>features</code> field will be used for future expansion and should alw
51
51
52
52
The <code>supportedstandards</code> field describes which standard it supports, such like <code>NEP</code> or <code>RFC</code>. It must be an array. In order to make smart contracts or other clients understand correctly, all NEPs must be capitalized. NEP and number must be connected with <code>-</code>. For example: <code>"supportedstandards": ["NEP-11", "NEP-17", "RFC 1035"]</code>.
53
53
54
-
The <code>abi</code> field describes which methods and events are included in the contract and how other contracts interact with them. For technical details of ABI, please refer to [[nep-14.mediawiki|NEP-14: NeoContract ABI]].
54
+
The <code>abi</code> field describes which methods and events are included in the contract and how other contracts interact with them. For technical details of ABI, please refer to [[obsolete/nep-14.mediawiki|NEP-14: NeoContract ABI]].
55
55
56
56
The <code>permissions</code> field is an array containing a set of <code>Permission</code> objects. It describes which contracts may be invoked and which methods are called.
Copy file name to clipboardExpand all lines: nep-25.mediawiki
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,13 +19,13 @@ This NEP describes the ABI standards for Neo smart contracts.
19
19
Neo smart contract system is designed to be mutually invocable between contracts. To achieve this, we need a mechanism for exposing the interface of smart contracts. With NeoContract ABI, developers can easily create programs to invoke smart contracts or write clients that automatically access contract functionalities.
20
20
21
21
This NEP is a compatible extension of the previous one,
22
-
[https://github.com/neo-project/proposals/blob/06a6b550987a74025009cf6841757f2426462697/nep-14.mediawikiNEP-14]. Some complex
22
+
[[obsolete/nep-14.mediawiki|NEP-14]]. Some complex
23
23
data types required more data for ABI to be useful for automatic SDK/wrapper
24
24
code generation. For example, parameter of "Array" type could be a structure
25
25
with three fields of "ByteArray", "Hash160" and "Integer" types or an array of
26
26
"Integer" values. These cases couldn't be differentiated both for method
27
27
parameters and return values with
28
-
[https://github.com/neo-project/proposals/blob/06a6b550987a74025009cf6841757f2426462697/nep-14.mediawikiNEP-14], while this proposal fixes it.
28
+
[[obsolete/nep-14.mediawiki|NEP-14]], while this proposal fixes it.
29
29
30
30
==Rationale==
31
31
@@ -249,7 +249,7 @@ type specified in the <code>namedtypes</code> object).
249
249
==Backwards Compatibility==
250
250
251
251
For the field extension this NEP is completely backwards-compatible with
Copy file name to clipboardExpand all lines: nep-29.mediawiki
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,7 @@ Neo N3 has a native <code>ContractManagement</code> contract that is used for co
43
43
44
44
This method will be automatically executed by <code>ContractManagement</code> contract when a contract is first deployed or updated. At this point new contract state is already saved (and it can be called from other code), but <code>Deploy</code> or <code>Update</code> notification is not yet emitted by <code>ContractManagement</code> contract.
45
45
46
-
The <code>data</code> parameter is completely contract-specific, contracts can accept any valid [[nep-14.mediawiki|NEP-14]] parameter types and handle them as required. It's the same <code>data</code> that is accepted by <code>deploy</code> and <code>update</code> methods of <code>ContractManagement</code> contract.
46
+
The <code>data</code> parameter is completely contract-specific, contracts can accept any valid [[obsolete/nep-14.mediawiki|NEP-14]] parameter types and handle them as required. It's the same <code>data</code> that is accepted by <code>deploy</code> and <code>update</code> methods of <code>ContractManagement</code> contract.
47
47
48
48
<code>update</code> is true when contract is updated via <code>update</code> and it's false on initial deployment via <code>deploy</code>.
Copy file name to clipboardExpand all lines: nep-30.mediawiki
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,7 +36,7 @@ Contracts that want their addresses to be used as transaction signers MUST imple
36
36
}
37
37
</pre>
38
38
39
-
Parameters are contract-specific, any number of valid [[nep-14.mediawiki|NEP-14]] parameters can be added if contract needs them to perform verification. Compliant contract MUST have only one method with this name, otherwise the result is undefined.
39
+
Parameters are contract-specific, any number of valid [[obsolete/nep-14.mediawiki|NEP-14]] parameters can be added if contract needs them to perform verification. Compliant contract MUST have only one method with this name, otherwise the result is undefined.
40
40
41
41
To prevent using this method in regular application calls contract can check for trigger returned from <code>System.Runtime.GetTrigger</code> interop function.
42
42
@@ -48,7 +48,7 @@ Transactions with contract address used as one of signers MUST include an approp
48
48
49
49
==Rationale==
50
50
51
-
Neo Legacy differentiated contract verification and application contexts only with VM trigger type, but Legacy contracts had only one entry point and their hashes were derived directly from the byte code, so they could be used as verification scripts as well. In N3 contract hashes are derived from the script that is intentionally made to abort execution, but N3 contracts also have multiple entry points described in [[nep-14.mediawiki|NEP-14]] ABI. Therefore a specific name was chosen to represent a method to be used for contract address verification.
51
+
Neo Legacy differentiated contract verification and application contexts only with VM trigger type, but Legacy contracts had only one entry point and their hashes were derived directly from the byte code, so they could be used as verification scripts as well. In N3 contract hashes are derived from the script that is intentionally made to abort execution, but N3 contracts also have multiple entry points described in [[obsolete/nep-14.mediawiki|NEP-14]] ABI. Therefore a specific name was chosen to represent a method to be used for contract address verification.
52
52
53
53
Since the system knows all deployed contract hashes and they can not intersect with valid verification scripts the choice was made to keep verification scripts attached to transactions empty. But as some contracts may need additional data for this method (typically, signatures or addresses) method parameters are not fixed and invocation scripts can be used to pass them.
0 commit comments