forked from near/NEPs
-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
sync up with near #1
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Storage rent has been superseded by storage staking a long time ago. This commit updates the account specification accordingly.
The link to FT docs on figment.io is dead, let's replace it with an archived version of the site. Also includes the following linter fixes in Core.md; - remove extra indentation of lists - add blank lines around lists - replace emphasis with real headings
- remove unused link declarations - surround titles and code with blank lines - give fenced code a language (using c to format comments)
While updating the specs for delegate actions, I noticed that there are two small mistakes in the error description of the NEP. Or I guess it would be more accurate to say the nearcore implementation is not compliant with the NEP. 1) `DelegateActionCantContainNestedOne` is impossible to happen because the chosen serialization format does not allow nesting in the first place. 2) The name for `DelegateActionSenderDoesNotMatchReceiver` somehow managed to get even longer in the real implementation and now spells `DelegateActionSenderDoesNotMatchTxReceiver` I know this isn't ideal. But since this is now de-facto part of the protocol, I suggest we update the NEP to reflect it. Alternatively, we could change it in nearcore. This would be a breaking change in some primitives crates, so I tend towards the first option.
Soulbound Tokens (SBT) are non transferrable NFTs. Even though tranferability is not available, we define a recoverability mechanism. SBTs are well suited of carrying proof-of-attendence NFTs, proof-of-unique-human "stamps" and other similar credibility-carriers. --- ## NEP Status *(Updated by NEP moderators)* SME reviews: * [x] @KazanderDad (NDC GWG): #393 (review) * [x] @alexastrum (Tenamint): #393 Contract Standards WG voting indications (❔ | 👍 | 👎 ): * 👍 @frol: #393 (review) * 👍 @fadeevab: #393 (review) * -- @robert-zaremba (can't vote myself) Wallet Standards WG voting indications: * ❔ @Cameron-Banyan * ❔ @MaximusHaximus * ❔ @esaminu ## Concerns | # | Concern | Resolution | Status | | --- | --- | -- | -- | | 1 | [Rober] Should we Emit NEP-171 Mint and NEP-171 Burn by the SBT contract (in addition to SBT native events emitted by the registry)? If the events will be emitted by registry, then we need new events to include the contract address. | [Robert] Don't emit NFT events. SBT is not NFT. Support: @alexastrum | open | | 2 | [Robert] remove `memo` in events. The `memo` is already part of the transaction, and should not be needed to identify transactions. Processes looking for events, can easily track transaction through event and recover `memo` if needed. | currently removed, consequently also removed from registry transactions . Support: @alexastrum | open | | 3 | [Token Spam](#393) | [Robert]: we have a `Burn` event. Added example `sbt_burn` function, but keeping it not as a part of required interface. Event should be enough. | open | | 4 | [Multiple registries](#393). Registry source of truth [comment](#393) | Robert: this is a part of the design: permissionless approach. [Justification for registry](#393) | open | | 5 | [Robert] Approve the proposed multi-token | Support: @alexastrum | open | | 6 | [Robert] Use of milliseconds as a time unit. | [Robert] Currently the standard uses milliseconds. | open | | 7 | Should a `burn` function be part of a standard or a recommendation? | [Robert] We already have the Burn event. IMHO a function should not be part of the standard inteface (similarly to FT and NFT). | open | | 8 | [Robert] Don't include `sbt_soul_transfer` in the standard interface, [comment](#393 (comment)). | [Robert] moving outside of the required interface. | open | | 9 | [Privacy](#393) | [Robert] Concerns have been addressed: [comment-1](#393) and [comment2](#393) | open | | 10 | x | resolution | open | --------- Co-authored-by: Vlad Frolov <frolvlad@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.