[Idea] NuLaw - 60 NBT bounty!

Hey howdy hey there,

I had a quick idea on my commute, so don’t judge me if it turns out to be useless :dromedary_camel:


There are a lot of motions that passed so far. Getting a quick overview what rules are currently in place requires you to enjoy a lot of forum posts.


I suppose having all of them on one page would be cool.

This way we would have rule book like

§ 1 - @woolly_sammoth has the most awesome beard.
§ 2 - @willy shall not pull on @woolly_sammoth’s beard.

and so on.

Changing existing rules would than look like this:

I hereby propose to change § 2 of the NuLaw book to
"§ 2 - @willy shall be allowed to pull on @woolly_sammoth’s beard."

Motion hash: 1323489723adsasdaiuhsiSKsjkl

Here’s the clue: The site will be edited with github pull requests.

When the motion passed, I’ll go on github and create a pull request for my fresh piece of law.
A couple of NuDruids (don’t mix this up with NuDroid), who are allowed to merge the repository, will then allow my request into the master branch and thus the website.


Great idea!
I already wrote a concern about that in a recent conversation

The forum already is cluttered and will rather sooner than later require some more structure like wiki threads that track activities just like the “voting hotlist” does.[/quote]

Your proposal is very useful to get an overview and track changes!
I don’t see why it wouldn’t work this way.

https://docs.nubits.com/ looks like a good place to use.

1 Like

+1, I like this

just gonna leave this here :pray:


You could also call them “Nu Regulations” as well.

1 Like

Sounds great and indeed like a simple working solution.

Good idea: plain and simple!

I thought we would have to books

Book I - Rules / Laws (e. g. pool operators shall allow a SAF of 1%)
Book II - Guidelines (e. g. Nu shall create Nu-SDR)

I’m currently discussing the implementation of a project like this into docs.nubits.com with @CoinGame.

Looking at http://blockexplorer.nu/motions/success, there is a lot of work to be done.
Any volunteers yet?

Maybe we can distribute the work load like volunteer 1 gets motions from 09/14 till 12/14 and so on.


Okay, no it seems.

I can understand. Reading and reviewing about 48 motions is a lot of work.

What would shareholders be willing to pay for that work?

  • 0 NBT
  • 1-100 NBT
  • 101-500 NBT
  • 501-1000 NBT
  • 1001-2000 NBT
  • More than 2000 NBT

0 voters

Voting period: 14 days from now.

1 Like

Can we like… hire an actual lawyer to create legal documents for a DAO? That would be interesting.


Why not. But I guess that would require around 5-10k?!

Maybe it’s a bit premature but it would be fun seeing future articles say “the Nu legal team has…”

1 Like

Maybe even more.
Could it be worth it?
I think so.

Let’s make some necessary adjustments in the liquidity provision scheme and spend parts of the saved money for that :wink:

Forgive the potentially naive post, I’m still new here… But wanted to chime in :smile:

As much as I love the idea of GitHub being the host (so you can track revisions over time), we’d still be up against the problem of figuring out whether…

a. the git diff reflects the (exact) text of the motion, and
b. the motion was actually passed

Without some check here, it’s possible that someone with access to a computer that has push-access to the GH repo could “update” the text. :frowning:

Maybe this could be solved with a quick validation script, to be run by Travis CI on each pull-request?

A “validation script” would (sort of like how we verify blocks in the Nu block chain…):

  1. Grab the messages from each commit being merged in the PR
  2. Pull the motion hash from the commit message (using magic syntax like Motion: <hash here>)
  3. Lookup the motion from the Nu network
  4. Check that it actually passed…
  5. Check that commit hash matches the one voted for

The idea then is that the process for proposing a change is:

  1. Fork the repository
  2. Add the statute you want to your repo, commit, push to your repo
  3. Create a PR to the NuBits repository with the commit (build will fail, that’s OK)
  4. Debate the commit in the PR on GH
  5. Once everyone agrees on GH, create a motion to "merge commit <your hash here>"
  6. Once it’s voted on, we re-trigger the build, and Travis will say “good to go” (build will pass)
  7. Click the Merge button

If someone were to ever try to merge something invalid, or mess with something in the git history (ie, rebase), the validation script, while going through all commit hashes, would notice the problem (“commit abcde references motion 12345 which wasn’t passed”).

Any commit that doesn’t validate would be a red flag, and since git is a hierarchical chain, changing something in the past affects all future hashes, so we’d have to re-vote on everything to get the new chain to validate.

This obviously assumes that all merges are fast-forward, which … seems like a reasonable assumption given that changes likely wouldn’t be all that frequent.

Thoughts? Am I overlooking some built-in feature of NuBits that already does this for us?


You’re not overlooking anything. Having automated verification would be extremely valuable. I think the process sounds nice except for the creation of a PR prior to motion passing and discussions on github (I find it to be a terrible platform for long discussions and debates). I would modify the process a bit to this:

  1. Submit a motion anywhere (Forums, Reddit, Facebook, etc.)
  2. Go through criticisms and critique until you feel it’s ready
  3. Finalize your motion by creating a RIPEMD-160 hash of the text to vote on and sharing it anywhere along with the text. Anyone will be able to validate the motion their voting on via the text.

All that is normal operating procedure at this point. Everyone is familiar with it thus far.

  1. Anyone can submit a PR to the repo with the motion text
  2. The validation script runs the validation,
  3. If the text is verified as passed. Click the Merge button, if not the PR is closed automatically.

The reason I suggest this is because NuSharesholders can be anyone. The motions can be presented and discussed by anyone on any platform. Not everyone knows or understands how to use Github. We required a Github login for Daology.org to find that many people don’t have a Github account or might be unwilling to create one for one purpose. While this forum is the main discussion place for motions at the moment, it may not be in the future. It’s really difficult to say “everyone start doing what you’ve been doing over here now”, and get everyone to comply. So this change keeps the current structure of issues being potentially discussed broadly across many online communities without requiring use of a specific platform. Though usually there’s one or two technical people in each group that could take the contents and submit it to the repo once it has been voted on, with validation that they aren’t trying to submit something that wasn’t accepted.

Maybe it doesn’t need to be exactly like that, but the goal is to try an be as platform neutral as possible. This same process could be ported over to bitbucket or gitlab without requiring people to move along with it. Just core maintainers utilizing some sort of hosted git solution.

1 Like

[proposals should be able to be] discussed broadly across many online communities without requiring use of a specific platform

Agreed. That seems perfectly reasonable.

The problem only arises when we realize that we’re effectively talking about “codification” in the legal sense.

Due to that, the “vote” needs to be for more than just the motion text; it also has to be for the modification to the codex – in our case, git repo.

(Using a diff becomes an obvious choice when the motion we want to pass actually affects several different files in the repo, at which point copying/pasting the new text makes it very difficult to spot what exactly is changing.)

Note that in regular-world, if there was a mistake in codifying something, a person would go “whoops, that was a mistake” and go fix it. But we live in crypto-world, where signatures either pass or they don’t, so there’s really no “whoops”. This means the diff becomes just as important as the text of the motion itself. Otherwise, the codex (git repo) is really just “somebody’s interpretation of the motions”, which is a troublesome direction to go.

If we agree on that situation, the important piece I’m trying to address is taking a git commit hash and tying it to a motion hash, because we effectively need to keep several things all bundled up together:

  1. the text of the motion (wherever it was posted and discussed)
  2. it’s RIPEMD-160 hash
  3. the git diff that represents the exact changes (textual alterations)
  4. the git commit hash that lives in the git repository (unique and chained)

In lawyer-land this (I think) corresponds to:

  1. the text of the amendment (ie, Sep 29, 1999, http://uscode.house.gov/statviewer.htm?volume=113&page=478)

    Sec. 644. (a) Increase in Annual Compensation.-- Section 102 of title 3, United States Code, is amended by striking “$200,000” and inserting “$400,000”

  2. the codified law or decision (ie, https://www.law.cornell.edu/uscode/text/3/102)

    The President shall receive in full for his services during the term for which he shall have been elected compensation in the aggregate amount of $400,000 a year

So, based on your comment, the process would be:

  1. Submit a motion anywhere (Forums, Reddit, Facebook, etc.)
  2. Go through criticisms and critique until you feel it’s ready for voting
  3. Create a git commit against the NuBits GH repository (to codify your change)
  4. Add the git commit hash and diff to the motion, so all pieces are included
  5. Create a RIPEMD-160 hash of the text, diff, and commit hash to vote on and share it anywhere (GH doesn’t require an account to look at diffs)
  6. Vote as usual

Does that line up with what you were thinking?


Very well explained. I didn’t fully grasp the extent of your idea. Thank you for elaborating. I think the changes are fantastic and offer more flexibility. I made a post recently about my belief that governance will be one of the key issues that defines crypto projects in 2016. I think developing an idea like this for Nu, (and even B&C Exchange) should be a priority for the network through the course of the year. Even if it takes a custodial grant to push things in motion.



I’m going to start sifting through the list of motions that have passed (which is no simple task), and doing my best to codify what they all said in the same style that BIPs do.

Once I have something worth looking at, I’ll send it over here, and if we get to the point where we have a bit of momentum, maybe we can consider making a motion of it.


After going through the first few motions (using http://blockexplorer.nu/api/successMotions as a starting point), things are … pretty messy.

I tried to add some structure just to get the motions in a somewhat standard format, but it’s definitely nowhere near done. Take a look if you’re interested: https://github.com/jgeewax/nubits-law

Once we have the motions all collected, the next step would be to start codifying these. With that in mind, I’m noticing that there are a few categories that might translate to “Titles”:

Title 1: Protocol

Rules here would be focused on changes to Nu’s protocol. Ideally the whole protocol is documented here, but that might be tricky…

Example motions include: voting on protocol versions, NuBits seeder, prioritizing fees.

Title 2: Funding

Could also be called “Custodians” or “Investments”, but the typical “rules” here would basically be a list of the current custodians, FLOT, and links back to the motions that include the more detailed terms of the funding arrangement.

Example motions include: B&C exchange, NuLagoon, liquidity operations compensation, new logos, FLOT team membership.

Title 3: Liquidity

Motions and rules having to do with liquidity pools. This would include the documentation of the liquidity tiers, all the currently running bots, the buy-back schedules, etc. This is likely to be the largest section as we’d want to keep a historical account of this stuff…

For this one, since we want to have the record of buy-backs and all that, we may run into trouble as the commit gets approved and sealed before the buy-back happens… We’ll have to figure something out for that…

Example motions include: auctions, custodial grants, burns, buybacks, dividends, new products, NuSafe, bots on exchanges.

Title 4: Community

The rules here might include what qualifies as a “featured exchange”, what the license of the NuBits source code should be, etc.

Example motions include: open sourcing code, listing exchanges, shareholder response rate test.

No idea if this is remotely close to what we had in mind… @willy, care to chime in?

If it is, the next step is to start working on the validation script that we can run against the repository to satisfy anyone worried about committers changing the rules out from under the network. Anyone should be able to run a quick script and know for sure that these rules are exactly what was intended.

Obviously, the “seed block” here will be the first commit, which brings things up to date – that’ll be a nasty commit to review, sorry for whoever draws that short straw.

I’d also like to suggest that from now on, a motion should be put inside code blocks so that we don’t wonder what the browser does between copy and hashing, so…:

Your motion text goes here:
1. Point 1
  - Formatted however you want
2. Point 2
  - Using *plaintext* style
3. Point 3

I haven’t verified the RIPEMD-160’s in the GH repo yet, but I suspect I’m going to have to do a bunch of sifting to make everything check out because of the rich-markup stuff we have in some of the motions posted.