Editorial updates (#187)

* 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]>

Author: roman-khimov

README.mediawiki

@@ -63,7 +63,7 @@ First review [[nep-1.mediawiki|NEP-1]]. Then clone the repository and add your N
 | Standard
 | Final
 |-
-| [https://github.com/neo-project/proposals/pull/133 18]
+| [[nep-18.mediawiki|18]]
 | Neo Address Resolution
 | Erik Zhang
 | Standard
@@ -87,10 +87,10 @@ First review [[nep-1.mediawiki|NEP-1]]. Then clone the repository and add your N
 | Standard
 | Accepted
 |-
-| [https://github.com/neo-project/proposals/pull/154 22]
-| Contract Basic Method Guideline
-| Owen Zhang, Fernando Díaz Toledano, Erik Zhang
-| Informational
+| [[nep-22.mediawiki|22]]
+| Contract Update Function
+| Owen Zhang, Fernando Díaz Toledano, Erik Zhang, Roman Khimov
+| Standard
 | Accepted
 |-
 | [[nep-23.mediawiki|23]]
@@ -105,6 +105,12 @@ First review [[nep-1.mediawiki|NEP-1]]. Then clone the repository and add your N
 | Standard
 | Final
 |-
+| [[nep-25.mediawiki|25]]
+| NeoContract ABI
+| Erik Zhang, Roman Khimov
+| Standard
+| Accepted
+|-
 | [[nep-26.mediawiki|26]]
 | Smart contract transfer callback for non-fungible tokens
 | Erik Zhang, Roman Khimov, Jaime Kindelan, Jimmy Liao
@@ -135,10 +141,11 @@ First review [[nep-1.mediawiki|NEP-1]]. Then clone the repository and add your N
 | Standard
 | Accepted
 |-
-| [[nep-25.mediawiki|25]]
-| NeoContract ABI
-| Erik Zhang, Roman Khimov
+| [[nep-31.mediawiki|31]]
+| Contract Destroy Guideline
+| Owen Zhang
 | Standard
+| Accepted
 |-
 | 
 | Dynamic Sharding
@@ -181,4 +188,4 @@ First review [[nep-1.mediawiki|NEP-1]]. Then clone the repository and add your N
 | 
 | Standard
 | Stub
-|}
+|}

nep-15.mediawiki

@@ -51,7 +51,7 @@ The <code>features</code> field will be used for future expansion and should alw
 
 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>.
 
-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]].
+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]].
 
 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.
 

nep-25.mediawiki

@@ -19,13 +19,13 @@ This NEP describes the ABI standards for Neo smart contracts.
 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.
 
 This NEP is a compatible extension of the previous one,
-[https://github.com/neo-project/proposals/blob/06a6b550987a74025009cf6841757f2426462697/nep-14.mediawiki NEP-14]. Some complex
+[[obsolete/nep-14.mediawiki|NEP-14]]. Some complex
 data types required more data for ABI to be useful for automatic SDK/wrapper
 code generation. For example, parameter of "Array" type could be a structure
 with three fields of "ByteArray", "Hash160" and "Integer" types or an array of
 "Integer" values. These cases couldn't be differentiated both for method
 parameters and return values with
-[https://github.com/neo-project/proposals/blob/06a6b550987a74025009cf6841757f2426462697/nep-14.mediawiki NEP-14], while this proposal fixes it.
+[[obsolete/nep-14.mediawiki|NEP-14]], while this proposal fixes it.
 
 ==Rationale==
 
@@ -249,7 +249,7 @@ type specified in the <code>namedtypes</code> object).
 ==Backwards Compatibility==
 
 For the field extension this NEP is completely backwards-compatible with
-[https://github.com/neo-project/proposals/blob/06a6b550987a74025009cf6841757f2426462697/nep-14.mediawiki NEP-14]
+[[obsolete/nep-14.mediawiki|NEP-14]]
 when new fields are ignored, old fields and their meaning remain intact.
 
 This NEP has more strict requirements for identifiers, but these are mostly

nep-29.mediawiki

@@ -43,7 +43,7 @@ Neo N3 has a native <code>ContractManagement</code> contract that is used for co
 
 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.
 
-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.
+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.
 
 <code>update</code> is true when contract is updated via <code>update</code> and it's false on initial deployment via <code>deploy</code>.
 

nep-30.mediawiki

@@ -36,7 +36,7 @@ Contracts that want their addresses to be used as transaction signers MUST imple
 }
 </pre>
 
-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.
+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.
 
 To prevent using this method in regular application calls contract can check for trigger returned from <code>System.Runtime.GetTrigger</code> interop function.
 
@@ -48,7 +48,7 @@ Transactions with contract address used as one of signers MUST include an approp
 
 ==Rationale==
 
-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.
+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.
 
 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.
 

nep-X1.mediawiki renamed to nep-31.mediawiki

@@ -3,7 +3,7 @@
   Title: Contract Destroy Guideline
   Author: Owen Zhang <[email protected]>
   Type: Standard
-  Status: Draft
+  Status: Accepted
   Created: 2024-09-11
 </pre>
 

obsolete/nep-14.mediawiki

@@ -6,6 +6,7 @@
   Status: Obsolete
   Created: 2020-03-25
   Replaces: 3
+  Superseded-By: 25
 </pre>
 
 ==Abstract==