-
Notifications
You must be signed in to change notification settings - Fork 11
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
MD-30: Movement Name Service #30
base: main
Are you sure you want to change the base?
Conversation
|
||
### D2: Bonding Curve for Key Minting and Burning | ||
|
||
**User Journey**: Users or services can mint or burn access keys based on a bonding curve. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe suggest some example bonding curves that have been used with Name Services. Are there any particular concerns we should have around the curve? Are there DOS vectors via economic attacks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the get-go it's important to figure out what the price should be. This depends on what we expect regarding the token price, but the friend.tech bonding curve math is pretty good.
|
||
### D3: Community-Driven Revenue Models | ||
|
||
**User Journey**: The community can implement their own revenue models via Rooms and Keys. Movement drives the first implementation with Ductus, a backend serving the name service and rooms, and Domus, the frontend that allows minting, trading, viewing of names and keys, and using chat rooms. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See note on moving Domus and Ductus up with other terms.
|
||
**Guidance and suggestions**: | ||
|
||
- Name and Room ownership should be tied to flexible access key resources, allowing for extensibility through third-party integrations and custom services. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Define Name and Room here.
### D5: Each Movement Name should grant access to its own Domain for .move TLD | ||
|
||
**User Journey**: Users acquire a `.move` domain. This allows the user to host an application running on http/https. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MNS Manager APP will probably be a correlated of this.
|
||
### Protocol Units | ||
|
||
- **NameRegistry**: Manages the registration and ownership of Names on the Movement blockchain, similar to the Aptos Name Service. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This starts to get more towards the actual proposal or recommendations herein. I would move this up to the top under a Terms section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also put all of this down in the appendix.
|
||
The protocol should utilize a bonding curve model for minting and burning access keys, with funds flowing through the following structure: | ||
|
||
```move |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can Domus and Ductus be represented here?
MD-30