[RFC] Proof of Creations


A proposal regarding the direction of the protocol and the specifications that should be provided.

Component Summary

  • Dev Protocol realizes “maximizing creativity” and builds a decentralized infrastructure for creators.
  • Dev Protocol is a unique protocol that can comprehensively support functional separated equities/incentives/governance for creators, and fan communities, with simple dynamics.
  • Compatibility with the already discussed gDEV, sTokens, Governance Dapps, and Staking Perks.
  • Additional implementations are Slashing and a preferential scheme for excellent projects.


Dev Protocol is committed to “maximizing creativity,” The scope to cover is not limited to financing. However, the scope currently achieved is extremely limited.

The goal is to create many positive loops―funded projects build a stronger creative foundation, stronger creative foundations bring more active and reliable creative activities, and more active and reliable creative activities attract larger stakes and fans―and improve the usefulness of Dev Protocol in those loops.


Before DIP-4, Dev Protocol was designed to increase or decrease staking rewards based on a quantitative evaluation of OSS. For example, positive indexes like the number of OSS downloads. However, that specification led to a concentration of staking and was abolished by DIP-4. Currently, staking rewards are calculated only by the number of stakes. In addition, there are concerns that positive indexes are vulnerable to manipulation by bots, larger time lag, and oracle cost increase, and there are creative areas that have difficulty evaluating quantitatively. Because of those concerns, the positive indexes were not suitable as a factor for calculating rewards.

Therefore, I propose a negative index, Slashing, and a preferential scheme for excellent projects.

  • A keeper or DAO( tentatively called the Stoppage Observer) reports Property tokens containing assets that have already been stopped and put them in the Slashing queue.
  • Property tokens queued by the Stoppage Observer are slashed after a council review.
  • Slashed Property tokens lose all unclaimed rewards and can no longer be staked.
  • Projects that aren’t slashed for a long time get an active coefficient and get bigger creator rewards.

People’s stakes prove the continuation of creation. And the number of stakes proves the reliability of the creation.

Projects funded by early-stage staking will use Governance Dapps and others to build a more active and reliable creative foundation. Or use Staking Perks and others to boost the seed funding by distributing some of the Property tokens to the initial stakers or offering unique perks. And as the project grows into a stronger project, the creator gets bigger stakes.

With the Proof of Creation, the protocol brings a positive growth loop to all creators and backers.

Agreed Collaborators

  • Dev Null AG / FRAME00, inc.

Missing Roles

  • Not decided yet


  • None

Lovely post as always, Aggre.

This is a widely discussed matter and has been in the forefront of discussions in our official telegram group for a few months now, so it’s great seeing it discussed and fleshed out!

Weeding out bad actors is important and a mechanism to slash out these said projects is very much needed. One could get accepted into dev and then abandon development so as to just sit back and accumulate dev (and sell).

So the general idea is to lower APY across the board and build a mechanism that gradually increases it for actively-funded projects that have been around for a while?


This is an excellent proposal and it will actually benefit all Dev Protocol creators, by having this mechanism it could end up being a ‘stamp of approval’ for Creators.

Just like integrating with Chainlink gives credibility to the security of a projects’ oracle and price feeds, implementing ‘Proof of Creation’ could have the same impact for Creators onboarding Dev Protocol and having stakers, in the future.


Omae-san also agreed with the concept of Proof of Creation. The concept seems that there is a big advantage to using negative indicators instead of positive ones. I designed Proof of Creation for the Dev Protocol’s vision of “maximizing creativity,” but he suggested that it has another advantage as well.

Finished software goes into maintenance mode and may no longer require financial support. We need to think about whether we should support software that is finished and does not require a lot of development or software that is unfinished and has potential value. There may be a strong correlation between the creative activities and when the stake is needed. Additionally, the mechanisms that work mechanically through the Proof of Creation system are better suited to supporting a larger number of projects than mechanisms such as a council and have the ability to encourage project metabolism through natural dynamism.


@Desu @Pdot Thank you all for your support of this concept! I’ll add my comment later :slight_smile:

I think Proof of Creation is a meaningful metric for creators, works to maintain the healthy protocol’s ecosystem, and is a concept that can add unique and rare value to Dev Protocol.

I would like to see a symbolic name that better describes the nature of Proof of Creation. Does anyone have any good ideas? ( Especially, @Midget_Gems san, @Desu san, @Pdot san? )


To keep inflation safe, I think it’s a good idea to start with an overall low APY, which reaches 100% with a long-term continuation bonus. That’s exactly what you’re saying, right?

Perhaps the most careful consideration in the Proof of Creation is the definition of “continuation.” What iteration is it measured in? Is it always constant? Do all markets have a common iteration or do they vary from market to market? If it varies from market to market, what rules do we use to determine it? I want to share that idea later.


Interval per activity (I/A): The average time per Market it takes for one activity. I/A is calculated based on the number of activities of all assets per Market in the past 6 months for each measurement. Assets that have an activity that is less than I/A are registered in the slash queue.

Measurement interval: Measured weekly, which is common to all markets. This means that the I/A is updated weekly.

I thought that such a rule would be a fair measure of continuity for all markets. These are measured by an open-source bot, which we call the Stoppage Observer oracle. Stoppage Observer Oracle detects assets whose creation has been interrupted and puts them in the slash queue. The council or DAO executes the actual slash.

Things that need further consideration:

  • Who will maintain the code for Stoppage Observer Oracle?
    Every time Market increases, Stoppage Observer Oracle needs to increase as well.

  • Stoppage Observer Oracle is a bot, and there will be a cost to run it. How will that cost be covered?

  • How will the assets in the slash queue be slashed?
    If it’s a council, who are its members? If it’s a vote by DAO, how do we withstand governance attacking by capitalists in the case of DAO voting?


I have raised the threshold on the assumption that it will ultimately be left to a council and DAO, but it may be a too rough to slashing projects less than an average. It might be a good idea to set the measurement interval is 1 week and the I/A is a uniform 6 months.

Projects with zero activity in the last 6 months will be queued in the slush queue. I think that 6 months is a good length of time for many digital activities. However, it may be too short for some fields, for example research. However, assuming that these rules will be updated by the DIP, a simple implementation is a good place to start.


This is an interesting idea and it follows what community members have been asking for in previous discussions (the Karma discussion for example).

It definitely varies from market to market, one Creator might have different creation time frames intrinsic to their own art. Musicians don’t create music everyday, filmmakers don’t make a film everyday, so finding a metric that makes sense for each market is ideal, if this is implemented.


Oh yeah, I think that for most Creators 6 month is a good amount of time, maybe these specific markets - like research- could have their own activity variables.


I will raise one point that could be problematic.

For music artists, the usual action is to release a song. The pace of the release can take six months or more depending on the person. In this case, it is not suitable to judge a project by its active coefficient.

Next, there are some people who work in music who do not have an official batch of soundcloud. These types of jobs do not leave any visible output (e.g., recording engineers, voice trainers, etc.).

Taking the above into account, we believe that some markets cannot be illuminated by “negative indicators”.


Thanks for the feedback :slight_smile:

It is not limited to music artists, but can happen to all creators.

I think Interval per activity (I/A) suggested by Aggre is the standard for fairness. Those creators with longer or shorter production periods will be averaged out in the market.

Earlier, I recieved feedback from Omae san,
It would be better that we have one solid standard (=I/A) and one filtering system.

What is filtering system?
It is the system that filters the creations by a score that indicates whether the asset is being used. It is not something that can be determined by the creators themselves, but something that shows how active the community is.
(Its premise is that creators create works not only for themselves, but also for others to use.)

For example, the number of blogs and tweets introducing the work, the number of events, etc.

How the filtering system works?
It works as a complement to I/A. For each asset that I/A intends to exclude, the filtering system selects an asset that should not be excluded.

This way of working proves that even creators who have been working for a very long time remain active as long as they are supported by the community.