Beam Feature Requests

Feature Request
#1

Following our announcement of moving to the bounty based model, we introduce the process of creating feature requests.

1. Creating a new feature request

  • In order to create a feature request, please create a new topic in the forum under the ‘Feature Requests’ category.

  • Describe the feature that you want to be implemented. Please be as precise as possible, but do not go too crazy, since we will discuss it and help to formalize the specifications together

  • Please indicate, which of the Beam products the feature is related to. The list of Beam products includes: Beam Desktop Wallet, Beam Mobile Wallet, DApps (usually a specific one, like NFT Marketplace or BANS), Blockchain Explorer etc…

  • If you would like to propose a bounty for the implementation of the feature, please indicate approximate amount in the description

  • Once you create a new FR it is always a good idea to post the link to the forum topic in Beam Community (and also directly to @bigromanov on Telegram), to make sure we are paying attention

2. Discussing the feature

Once the FR is created, we will start a discussion on the details of the feature, it’s viability and some technical details of its implementation. The discussions should result in clear understanding of as many feature aspects as possible and get the community ready to vote on the feature.

Feature discussion will also include estimations of bounties and resources needed for the implementation of the feature, as well as its complexity and other features it may affect.

The discussion phase will end with the summary of the agreed points and full feature specification that will be added as Github issue under Beam organization. This will help to track further changes, additions or improvements in a more formal way and make sure the agreed upon points are upheld.

3. Voting on the feature

The voting process can be done in several ways. Usually for most features we expect the voting to be done informally either in the Telegram or Twitter or both. Once the votes are counted we can determined if most of the community considers the feature to be useful and beneficial for the Beam ecosystem and hence can be prioritized for development

In certain cases of major disagreements or in case of large changes, including (always) the changes to the protocol that require hard fork, the feature will be voted upon on chain within the framework of the BeamX DAO Voting Process.

4. Feature prioritization

Once the community is in an agreement on the feature, it will enter the queue, since we expect that new feature requests will appear faster than we will be able to implement them. Prioritization of the features for development will be done according to the following criteria:

  1. Amount of community members that supported the feature

  2. Availability of Bounty sufficient to cover the development costs

  3. Availability of developers who can implement it

5. Bounty allocation

In most cases, building a new feature will require a bounty that can be provided by Beam Foundation, BeamX DAO (through voting only) or by the Community members through donations for specific purpose. Bounties will be stated in BEAM, or other assets that have a specific value. In some cases, bounties can be augmented by additional token types.

Once the needed bounty threshold for feature implementation is reached, and the developers are assigned, the development process can start.

6. Acceptance and Release process

Implemented features will always go through Beam testing process and only then will be included in the upcoming official Beam releases. Of course, due to the open source nature of the product, anyone can build the code with the new features, however all of these production should be used at your own peril as they are not officially signed or tested by the Beam Team.

Bug fixing and support rules will be determined on the per feature basis, as some feature require more support than others. Once the feature is tested it will be assigned towards the next Beam release, depending on the release schedule of the relevant components.

I am happy to start this new era of Beam development and invite everyone to participate in the process and keep helping Beam to move forward

Alex Romanov
Beam CTO

2 Likes
#2
#3

I’d like to request a tail emission, which will eventually become necessary as the block subsidy runs low and fees are insufficient to provide adequate security.

Specifically, I propose that subsidy halvings will end once the yearly supply inflation rate has dropped below 1%.

As this is a 1 line change in the consensus code, I think a bounty is superfluous.

1 Like
#4
#5

Thank you very much. Your request was assigned number: FR1 and moved to the ‘In discussion’ state. The issue is here: https://github.com/BeamMW/beam/issues/1913

Since this is a major change that requires a hard fork, final decision will be made through on chain voting

1 Like
#6

Thank you very much. Your request was assigned number: FR2 and moved to the ‘In discussion’ state. The issue is here: https://github.com/BeamMW/beam/issues/1914. Topic for the discussion of the FR is here: Beam NFT Gallery Feature Request

1 Like
#7

A “panic wipe” function built into the wallet. So you can move your funds and NFTs safely to a new wallet (new seed) with ease. A nice unique feature if other users also have interest.

3 Likes
#8

Great idea. Could you please start a separate topic and provide more details on how you envision this feature. How it should work? How do you see the user flow and use cases?

1 Like