n October, Numerai announced Erasure, a protocol for building trusted, unstoppable data markets. In March, we announced an $11 million raise to make it happen. We’re announcing lots more this quarter. Starting with this: we’re launching the Numerai Grants Program, $1 million in NMR to support teams building on top of Erasure.
powers markets for information, by leveraging the core trust models of
crypto — staking, time-stamping, and public-key identities.
Erasure, you can upload encrypted data, stake it with cryptocurrency,
then sell it to a buyer. The buyer trusts you because your past is
etched into the blockchain, your stake can be burned if your claims are
false, and because the purchase is handled atomically via smart
started with finance. What if we took everything Numerai’s learned
about crowdsourcing ideas for trades, and built a platform for anyone to
build a market for themselves? I joined the project because, after a
stint at a hedge fund in Connecticut and a payments app outside Somaliland,
I saw Erasure as part of a defining, generation-long effort: to extend
market infrastructure to the frontier. Erasure answers the question of
how to drive more capital into Ethiopia, or into fusion startups. Build a marketplace for diligence.
But as we built, the vision expanded. Markets with both high trust and high privacy can empower whistleblowers. Richard tweeted:
“The next Snowden will use Erasure.” We started to see Erasure as part
of another grand, generational project: to make the Web more trusted.
Fake news is a signal problem of our time, and it’s getting worse. Imagine a Web where skin-in-the-game is de rigueur,
where activity is logged on permanent but anonymized identities, where
communication is peer-to-peer. It’s a Web we want. Drop Erasure into
your next site.
Grants ⇋ NMR
Grants in the context of NMR 2.0
Erasure wants a great developer community. Numerai wants NMR to be the best token in the world. The Grants Program serves both.
tokens have constrained supply. So we committed to burn most of the NMR
we had the right to mint (reducing total supply by ~50%). Good tokens
are secure. So we committed to shutting down contract upgradability (so
the rules never change).
tokens are widely used. Erasure will help here — majorly. It will
expand the usefulness of NMR from Numerai’s tournament, for only
Numerai’s data scientists, to a theoretically unbounded set of finance
tournaments, media sites, and apps of other kinds.
Good tokens, finally, are widely held. This is where the Grants Program comes in. Tokens are subject to classic network effects.
Getting them into engaged holders’ hands mean new transaction
possibilities, more global incentive alignment, and less discretionary
market power for whales. NMR should be held by the community, not by
Numerai, in the long run. We believe this strongly.
be quantitative. Below is NMR’s current state, then ideal state. We get
there via a contract upgrade in the immediate term, and Erasure in the
long term. The token on the right, simply put, is the one we’d prefer to
hold. We expect it’s the same for you.
best way to get NMR to the community is to give it to the community.
But we’ll do this carefully. New supply in circulation should generate
lasting value, and offsetting demand. This is why we love grants. A
great way to build value for NMR is to give NMR to builders. There’s a
precedent close to home. NMR wasn’t launched with an ICO. We gave it to our best data scientists. The strategy worked. So we’re doing it again.
How to Apply
How does Numerai’s Grants Program work?
We’re looking for people with charismatic ideas about the future. If you have them, we’ll support you.
The grants process is direct:
Send us your concept for an app powered by Erasure to [email protected] Write as much detail as you can. Tell us your budget.If we’re intrigued, we’ll chat. We’ll give you suggestions. We’ll introduce you to our protocol team.Once we get a final plan, including milestones for releasing funds and technical specs, if everyone is excited, we’ll roll.
What can be built on Erasure?
love the idea of new trading tournaments built on Erasure. We love the
idea of media sites with Erasure baked in. Or surprise us.
“How can a Marriott spin-off be an exciting market inefficiency and the chaotic development of half the planet not be?” — What Would Ben Graham Do Now?
a world where every hedge fund ran their own tournament. They’d pull
the backend data direct from Erasure. Their frontend would be an oracle
for calculating reputation. They’d put up a bounty for signals and call
on the community to submit.
Some tournaments we’d love to fund:
One specialized entirely in Tesla (or another widely-followed company), calling for predictions across its financial statements.One
specialized in a fast-growing frontier country stock market, like
Kenya’s, helping developed-world funds move money to it from abroad.One specialized in crypto, both quant and discretionary.
a world where every company had an open bounty for information on
corporate crimes. The site is native to Tor, and because it’s on
Erasure, its backend is as censorship resistant as the blockchain. Or
imagine a social media site where people staked cash on their claims.
You burn scambots to the ground, and the $TSLAQ fintwit folks have to put money where their mouths are.
Some apps we’d love to fund:
Bounties to whistleblow crimes, corporate and otherwise.A Twitter UX, but with a tip jar and a burn lever.A browser plugin, that puts money at stake on real Twitter from Chrome.
surprise us. Drop Erasure into a remote work platform to align
incentives. Build a decentralized bug bounty system leveraging Erasure’s
anonymity. We’d love a React package that makes it easy for an Erasure
modal to pop up anywhere.
the connecting thread? The ultimate goal, to my mind, is
redistribution: get capital into the hands of people who know scarce
truths. You can be a teenager in Nairobi with a Juypter install,
competing in a crowdsourced signal tournament. You can be a janitor at a
bank in London, who’s witnessed fraud. Or you can be an AI. We’re
building systems of moving money where truth is the sole objective
function. Join us.
Along with all these updates, I started working in a private repository to create the new RISE v2.
New v2 is built to have the following concepts in mind
The ones above are the 4 core features that I think were lacking in the old v1 codebase hence why I started the rewrite.
What’s new in v2
RISE v2 hosts several new improvements. Let’s start from the biggest change:
Thanks to yarn and Lerna we were able to rewrite all main RISE functionalities separating the concerns of each module.
This is not only a nice coding approach allowing to re-use components but will also allow third-party developers to override core modules by injecting their own replacing module.
For example, there is a “consensus-dpos” module which provides all the code needed to handle the DPoS rules and API; If a developer wants to, they might write their own consensus module and re-use all the other core modules.
can think about modules like pieces of a puzzle. As long as your piece
has the same shape as the “original” one, it will fit nicely creating a
every module is an (almost)-self-contained piece of software it needs
to follow a contract, or a so-called interface, in order to be a valid
developers can also benefit from using the lifecycle declared within
the above-mentioned interface. This is beneficial especially when
modules need to initialize or teardown specific elements within their
The main 4 lifecycle events are (in order of execution): preBoot, boot, teardown, postTeardown.
Modules can also override the configuration of other modules as well as adding specific commander options when booting the application.
DAG — Source: Wikipedia
Since Module ‘A’ could depend on ‘###em/em###’ a Directed-Acyclic-Graph is built on-startup so that the lifecycle and config override respects the expected natural flow.
also ensures that no 2 modules reference each-other (either directly or
non-directly) leaving the codebase clean as well as making sure that
different boot produces the same result in term of booting priority.
Since I follow (as much as possible) the KISS principle, modules can declare that they depend on another module by exploiting the ‘package.json’ capabilities that Node.js developers are already used to.
underlying technology of the RISE core needs to be constantly updated
to leverage both performance and security improvements.
With this in mind we decided to update:
Node.JS from v8 to v10;TypeScript from 2.8 to 3.4.5;PostgresSQL from 10.4 to 11.3.
We then decided to remove Redis entirely as it was no longer used in the codebase and there was no real reason to keep it as third-party dep.
The WordPress-like Hook System
If there’s something great about WordPress is its the plugin and hook system.
Since one of the main assets of the whole WordPress ecosystem is the
wide variety of plugins that are installable it seemed a good idea to
copy the good concepts and bring them, for the first time, in the
In RISE v2 we use “mangiafuoco”, a Node.JS library written by me that mimics the WordPress hook system by adding utility functions.
Embracing this technology was kind of the next step when building a modular core since it allowed us to decouple modules inter-communication enhancing by several factors the maintainability and code clarity.
To enhance and smoothen out the learning curve we even created TypeScript Decorators which you can apply on your methods. This will give you type-safety, the thing we all love about TypeScript.
Example of multi-hooks usage.
Of course, all filters and actions are declared in the “hooks” directory of each module allowing every developer to easily find exported actions and filters.
Execution priorities you ask? We also support that and you can use it as well :).
New Transaction Types and functionalities
V1.x Transaction system has several design flaws and is not as flexible as I wanted it to be.
The new tx schema has the following benefits compared to the previous version:
Streamlined serialization and deserializationAbility to encode different address systems (more on this later)Unequivocally encode-decode payload
Before this update, we had several constraints and, for example, the Ledger Nano integration was painful to code and test.
The new tx schema opens a lot of new possibilities for RISE enabling the amount of flexibility we need to satisfy almost all use cases.
Another nice side-effect of the new transaction types is that they do natively support having dynamic fees.
Even if RISE does not necessarily need dynamic fees now, we always need
to anticipate needs to avoid unnecessary network bottlenecks.
The new Send transaction type has a new field that can hold up to 128bytes of raw data
Send transaction with “banana” string encoded in the payload
This opens up a lot of new possibilities
and scenarios developers could use to permanently store data in the
RISE blockchain. EG: An eternity wall, a payment processor, a notary
State of the art technology (borrowed from Bitcoin — bech32),flexible,has
checksum!!!! Meaning that if you had to type a long address and made up
to 4 mistakes we would be able to find exactly where the error was
made,by far more secure,QR code efficient — easier to read.
Along with all the goodies, we are making a big change in the way the 2 address system will co-exist.
Since V2. The primary account key will no longer be publicKey
while rather the address itself. Since V2 is, by far, more secure than
the previous address system, we will discourage using V1 by highering
the TX fees when sending/receiving.
New P2P Comm Layer (Again)
we basically solved most of the p2p bottlenecks. Unfortunately, some
minor errors were made when designing the new p2p layer back then.
The new P2P layer features:
Same Transaction Per Second outputSame Bandwidth efficiencyMore flexibilityMore robustness
Let’s focus on the third and fourth elements above:
The P2P layer has been decoupled and is now a separate module (“core-p2p”)
which allows third-party devs to deploy their own p2p solution. Ex:
just for fun a developer could use morse-signals over the infrared
spectrum to send/receive data to/from neighbor nodes.
About Robustness: we designed the p2p classes to be easy to use and rock solid. The p2p layer will treat your data as an opaque message to be sent and received, serialization and de-serialization are up to the developer. Multiple codec technologies might co-exist; for example, a module could register a p2p endpoint for sending/receiving data in “plain-text” and another could use binary or ProtoBuf as the encapsulation method.
Furthermore, requests can now be batched and also eventually expire. Handy for many use-cases.
Last breaking change for the RISE v2 would be the communication ports. In RISE v1.x we used the 5555 (or 5566) port for both public APIs and internal consensus communication. In V2 we decided to separate the 2 comm channels:
Port 5554 for consensus communication;Port 5555 for APIs.
small change will improve even further the performances of the
communication layer by removing the API bloatware from the consensus
Deprecating MultiSignature Accounts
This might sound like a step back, right? No more multisig accounts… WhatTheHeck??
Well, there are 2 reasons behind this move:
The multisig functionality was, to say the least, over-engineered and poorly conceived (both in code and database)The new Address system is able to encapsulate multisig accounts such as in BTC.
Note: you can’t really create multisig accounts in v2. (they’ll come soon™)
To summarize, we removed a big chunk of codebase (and tests) that no-longer needs to be maintained :).
RISE we also have second signature accounts. That functionality will be
maintained as a separate module named after its functionality
(core-secondsignature). We decided to keep this feature since many
accounts were actively using it compared to multisig which was not used
Changes to the consensus (Again)
Improving current solution is crucial. That’s why we decided to stop distributing fees evenly to all delegates. “Wait what”?
In v1: All tx fees were collected and evenly distributed to all delegates who participated in the round.in v2: delegates will be rewarded the fees they forge.
all honesty, the “v2 way” should have been “the way” as it provides an
incentive for delegate nodes to keep their node up&running with
RISE v2 is, besides many other things, a big refactor of v1.x, it was
about time to change the Database structure to a more meaningful schema.
A bunch of columns was removed from the accounts table and, at its base form, only 4 (vs over 10) column are needed.
Furthermore, tables and some columns were properly renamed to follow a single standard convention.
Idempotent DB Update Scripts
Upgrading a blockchain isn’t as easy as you might expect. Database updates are no exception. In RISE v2 we decided to create “schema.sql” files which basically are idempotent. But what is idempotency? From wikipedia:
is the property of certain operations in mathematics and computer
science whereby they can be applied multiple times without changing the
result beyond the initial application.
With this change of approach we now have the ability to:
Keep the current, most-up-to-date, database schema in a single place for easier maintenance and debugging.run the schema.sql upon each startup and make sure we don’t break anythingHow/When will the update happen?
the p2p layer is no longer backward compatible we’ll provide an update
script that will take care of upgrading the blockchain core at a
specific point in time (or better said, in height).
node operator will need to trigger the update script before the
deadline to keep their node(s) synced with the network. Delegates
failing to do so will be eventually banned by the consensus leaving
space to worthy delegates that updated instead! (more info).
Of course we’ll give it a go using testnet first that has been rebooted a couple of weeks ago to have the same features and configuration we have in mainnet.
If interested, please join our Slack, and enter the #testnet channel to receive some testnet tokens to play with and instruction on how to set up a node.
bankroll staking has been the goal and aspiration from the very
beginning of Edgeless’ inception. Since December 2018, the team has
successfully run several rounds of beta staking. More than 150 people
tested the beta version. Thank you very much to all the community for
helping to improve staking!
is pleased to announce that from the 4th round, the staking platform
will be updated from beta to official release. After this change, the
platform will have new staking conditions. Some of the most important
changes — an increased staking reward from 5% to 40% and a new feature
which will incentivize community growth and reward heavily contributing
For new community members
those who are new to staking and wonder why a decentralized casino
needs staking, here’s a brief overview: There is a limited amount of
Edgeless tokens (a total of 132,046,997). It is not possible to create
new tokens or delete existing ones . In the near future, Edgeless’
players base and betting limits will increase, calling for a larger
total bankroll to sustain the growth of the entire system. To make sure
the bankroll is always sufficient, Edgeless needs a mechanism which
enables the community to support the growth of the bankroll. Without
such a mechanism, the casino would not be able to serve players.
bankroll staking feature is based on blockchain smart-contract
technology. Smart-contracts allow for effective ways to organize
Edgeless’ bankroll, which was never possible before.
The key updates
40% from the bankroll surplus and the new general staking conditions
previously mentioned, the staking platform will be updated from beta to
official release. Please familiarize yourself with the new conditions:
Reward offered in staking rounds: 40% (an increase from the current 5%)
of the bankroll surplus. Stakers get a part of the reward proportional
to their initial number of EDG tokens staked
- Each round length: 14 days
- Full staking round: From Monday 7 AM UTC till 7 AM UTC two weeks later
- Staking period starts: Wednesday, 7 AM UTC
- Staking period ends: Monday 7 AM UTC 12 days later
- Withdrawal period: From Monday 7 AM UTC till Wednesday 7 AM UTC
- Min stake deposit per user: 1,000 EDG. Max stake deposit per user: 50,000 EDG
- There will be no fees for moving funds to and from the staking account
- Users will have the possibility to deposit tokens at any time
- Stakers will join the “Staking Loyalty Program”. More information about this below.
People who would like to participate in Edgeless bankroll staking will
need to register and complete the KYC process. (Stakers who participated
in previous rounds do not need to register again. These users will be
automatically able to stake after the official release on 5 July)
- Due to uncertainty in the US in regard to the regulation of tokens, US citizens can not participate in staking
Edgeless Staking Loyalty Program / Let’s grow faster together
staking revolves around community, Edgeless is introducing a new
feature which will incentivize community growth and reward heavily
contributing individuals. This feature is called the Edgeless Staking
Loyalty Program. The Loyalty Program ranks every individual,
categorizing them into 3 different levels: Silver, Gold and VIP.
Different levels give different reward percentages according to this
achieve Gold or VIP status staking platform will have feature ‘Invite
Your Friend’. For each invited person, your status is upgraded for 30
days as well as the status of each invited friend.
Once the 30 days are over, and if you have not met the VIP requirements, your level drops to Gold and then to Silver.
Requirements for ‘Invite Your Friend’:
1 invited friend = Gold status
2 invited friends = VIP status
A has 12 days left of their VIP status. Staker A invites 4 additional
friends through a tracking link. Now staker A has 72 days of VIP status.
A has 0 days left of their VIP status. For the next round, he gets Gold
status. After another round, he gets Silver status. If the staker
invites 1 person — he’s upgraded to Gold for 30 days. Once he invites
another person, he’s upgraded to VIP status and his status is valid for
- Total staking pool is 5 million EDG tokens.
- Edgeless bankroll surplus is 1 million. 40% of 1 million is 400K.
- Staker A who owns GOLD status stakes 50K which is 1% of the entire staking pool. 1% from 400k surplus is 4k EDG.
- Staker B who owns VIP status stakes 50K which is 1% of the entire staking pool. 1% from 400k surplus is 4k EDG.
Staker A reward is calculated using multiplier mentioned above: 4000 x
0.5 = 2000 EDG. Staker A who owns GOLD is rewarded 2K EDG tokens.
Staker B reward is calculated using multiplier mentioned above: 4000 x 1
= 4000 EDG. Staker B who owns VIP is rewarded with 4K EDG tokens.
There will be also other many ways
to achieve Gold or VIP status in the future. Starting from the 4th
staking round, all participants will get VIP status for 30 days. The
full version of the Staking Loyalty Program — Gold, Silver status,
“Invite Your Friend” and other features — is expected to be deployed in
the 5th or 6th staking round. More information related to this topic
will be announced in June.
IMPORTANT REMINDER: Edgeless offer
some of the games that are 0%. Therefore, the casino winning against the
player is not guaranteed, there is a luck factor. This means that a
negative bankroll surplus is possible.
The 4th round details
Key dates of the 4th round:
- Until 2019–06–05
initiation of staking. Those who would like to participate in Edgeless
bankroll staking will need to make a deposit*. Deposit now -> press here
and the possibility to make a deposit will close on Jun 5, 2019 12:00
PM GMT +0. On this day, all staked EDG tokens until Jun 5, 2019 12:00 PM
GMT +0 will be sent to the bankroll smart contract.
smart contract system will automatically check whether Edgeless’
bankroll has a surplus. If there is a surplus a smart contract will then
automatically take 40% of the surplus and distribute it to those who
had participated in bankroll staking. Participants will be able to
redeem their tokens until Jun 19, 2019 12:00 PM GMT +0 and participate
in the upcoming round.
bankroll staking model is created to factor in recent legal
developments in the crypto sector. Similar staking mechanisms are used
by other crypto projects.
The Edgeless team follows all legal
developments and, if needed, in the future there will be changes made to
the principles of staking so that our activities will be in line with
The EDG token is a UTILITY token. It has no profit sharing, dividends or any other features associated with securities.
LBRY (LBC) Pre Release v0.37.0rc7[0.37.0rc7] - 2019-05-10
[improvement] added logging to publish command (#2106#2104) by eukreign
[fixup] fix store content fee (#2105) by jackrobison
[fixup] fix stream_update failing on metadata only updates for files we don't have (#2107) by jackrobisonsource code:https://github.com/lbryio/lbry...