oceanSPICE - Simulation of Ocean Protocol data assets - Proposal Round 7

Key Project Data

Name of project: oceanSPICE - TokenSpice Simulation for Ocean Market Ecosystem

Which category best describes your project? Pick one or more.

  • [x] Build / improve core Ocean software

Which Fundamental Metric best describes your project? Pick one.

  • [x] Datatoken Contracts

The proposal in one sentence:

The project creates a web solution to simulate the creation and economy of data assets with dynamic pricing on Ocean Protocol marketplaces via TokenSpice in the backend.

Description of the project and what problem is it solving:

Ocean Protocol marketplaces (whether it is Ocean Protocol’s own marketplace, the one launched by Big Data Protocol, deltaDAO or TransportGenie) all suffer from the same problem. They do not have an option for data asset launchers (publishers) to get any insights into which configurations of the data asset dynamic pricing parameters are most beneficial for their own data asset. The marketplace offers the users the option to set a certain initial datatoken price, an initial provided liquidity, a number of datatokens, and a swap fee. For a newcomer this is very difficult to understand. Robin, our team member, spent plenty of hours in calls with data asset providers to explain and determine good parameters with them to launch their data assets. This is a huge cause of churn for data asset providers right now and will remain to be one of the major hurdles for data asset providers in the future.

But if the parameters are set this does not give insight into how the future might look like in terms of development of the liquidity pool and potential reward estimations after the data asset has been launched.

This project provides a first step in the direction of a solution to these issues. The project will provide a web interface to simulate the launch of a data asset onto the marketplace. This will include all the options for dynamic pricing that can be set on the marketplace interface. Additionally certain simulation scenarios can be selected to get insights into the development of the data asset on the marketplace and potential revenue created from it. This is done by wrapping TokenSpice, a simulation tool developed by Ocean Protocol, into a backend and connecting its inputs and outputs to a web interface.

TokenSpice was created originally by Trent McConaghy to simulate the Web3 sustainability loop and offers the capability to simulate the whole Ocean Protocol ecosystem down to the smart contract level. This enables us to launch a pool on a local blockchain (via Ganache) and create data asset pools on it. It also enables us to create agents that will do all of the actions like launching the data asset, adding liquidity to it, buying it, or speculating on it. These agents do not completely exist yet and their configurability is not provided yet.

Trent has created these open issues on GitHub that we are solving next to everything else:

Be able to specify a netlist and run, without having to fork

Implement Ocean V3 market dynamics, run simulations, tune as needed

Implement rest of DataConsumerAgent, unskip its tests

Open topics for TokenSpice - Source: Trent’s presentation of TokenSpice

V3 Ocean Market ecosystem - Source: Trent’s presentation on TokenSpice

So the overall result of this grant will be a system according to this architecture:

The result will be open sourced and include Docker compose files to spin up a version of it. The changes made to TokenSpice will be offered to get pulled into it via pull requests.

What is the final product?

Website that enables anyone to simulate their data asset token launch, open source code to replicate the results as well as Docker compose files to spin up the software stack for further development or reuse.

Grant Deliverables:

  • Website that enables the simulation of data asset launches with different market scenarios
  • Open source code that enables the implementation of new scenarios and local deployment of the code
  • Pull requests to the TokenSpice repository to improve the Ocean Protocol software

Funding Requested: 32.000 $OCEAN

If your proposal is voted to receive a OceanDAO Grant, how would the proposal contribute a value greater than the grant amount back to the Ocean Ecosystem (best expressed as “Expected ROI”)?

It is very important to give potential data asset providers the opportunity to get more clarity on what they are getting into when they list their data asset on the marketplace. The marketplaces require an initial investment in liquidity of a utility token and this is something that larger enterprises always want to analyse before they get into it. This tool enables this.

If we think about a potential inclusion of Ocean Protocol in a large ecosystem like Gaia-X then an analysis tool like this will be used by the thousands of data asset providers that are going to join that ecosystem on top of Ocean Protocol.

Expected ROI:

Bang: 10 additional data assets hosted on Ocean marketplaces because of the ability to simulate the circumstances - each with an assumed TVL of 10.000 $OCEAN
Buck: 32.000 $OCEAN
Likelihood of success: 80%
ROI: 100.000/32.000 * 0.8 = 2,5

The ROI is bigger than the requested one of 1.0.

Proposal Wallet Address:


Team Website (if applicable): n/a

Project lead Contact Email: oceanSpice01@gmail.com

Twitter Handle (if applicable): https://twitter.com/OceanSpice01

Discord Handle (if applicable): ocean.spice#7793

Country of Residence: web3

Have you previously received an OceanDAO Grant (Y/N)? N

Part 2 - Proposal Details

Project Deliverables - Category

IF: Build / improve Ocean core software, then:

  • A PR will be made to these Ocean components: TokenSpice, following best practices for quality etc

  • We commit to working with Ocean core developers to merging the PR

If the project includes software:

Are there any mockups or designs to date?

An overview of the technology stack?

Frontend: React.JS

Backend: Flask + Python libraries, TokenSpice

Project Deliverables - Roadmap

Any prior work completed thus far?

The team has been working together in the Balancer Simulation: Ocean Protocol course by the Token Engineering Commons and came up with the idea for the proposal there.

Technologically the project will reuse parts of the DataUnion stack to create the software and skip a ton of work in the initial setup phase (web frontend and backend parts).

What is the project roadmap? That is: what are key milestones, and the target date for each milestone.

  • 27th of July 2021 is the final presentation of the Balancer Simulation course, this will be when the project will first show its results. The recording of this meeting will be made publicly available to the OceanDAO so that the ecosystem can evaluate the results.
  • After this the next milestones will be defined according to the results presented there.

Please include the milestone: publish an article/tutorial explaining your project as part of the grant (eg medium, etc).

  • Source code on GitHub
  • Video of the milestone presentation in the Balancer simulation course by the Token Engineering commons
  • Tutorial on how to use the web application

Any maintenance?

The server will have an upkeep cost - this will be sponsored by DataUnion

Foreseen or possible additions?

We will start with a limited number of scenarios for the market interactions and also focus on Ocean Protocol’s marketplace/contracts V3. So V4.1 could be a future addition to the simulation environment as well as more complex scenarios.

But this simulation environment also offers the opportunity to extend it to analyse many more scenarios e.g. how much transaction costs different blockchains consume for market scenarios to choose which blockchain to launch a data asset on or even extend the simulation much further to simulate potential data asset quality versus buyer expectations.

Team members






  • Role: DataUnion/OceanDAO proposal onboarder
  • Relevant Credentials (e.g.):
  • Background/Experience:
    • Head of Ocean Protocol Ambassador program
    • CEO at DataUnion
    • ML/Web3/DataUnion strategy at deltaDAO
    • Machine learning (10yrs)
    • Web3 (4yrs)
    • Working on a bottom up approach to bring DataUnions to as many verticals as possible to learn and adopt the concept to their needs

Sure. Anyways, I’d like to bring this thread’s attention back to my first question where I wanted to acquire more information about how the proposal deems to fulfill the deliverables etc.

Ok, let me comment on that:
Trang and Shawn (https://github.com/LinuxIsCool), who has 21 commits in the repository already, are going to work on improving the core functionality to be extended from being able to simulate the Dataecosystem. This is based on a comment of Trent (https://github.com/oceanprotocol/tokenspice/blob/b6d51f0b66aa8937ddf705bfe571ece09698db3d/engine/SimState.py#L56) - so significant work has to be done here to make that possible. This is next to the other tickets like supporting V3 in the simulation.
Additionally new agents have to be created to support the scenarios that are interesting to the end users. This will be supported by Richard.
The complete system of the agents reporting their results has to be reworked as Trent did not have them report individually for the Web3 sustainability loop simulation. These new output CSVs will then be transformed in visualisations for the end user. This will be a team effort to come up with a good solution.
Sarah will be working out the frontend while I will be adopting DataUnion’s backend stack to offer the REST APIs.

Additionally we will implement a Netlist system - think about it like a way to load scenarios into the simulation.

Trent is a genius, no questions asked, but what will be easy for him to further develop will probably take us quite a bit of time to understand and extend.
The goal is to also extend the documentation of the code and make it more accessible and extendable for the future e.g. for a hackathon to create agents for TokenSpice.
From a time spent point of view to achieve all of this I am quite sure that this will be a ton of hours done in engineering work.
I think all of these points were already explained in the proposal in the top - but o.k. do you want me to now create a waterfall model and assign hours to each individual tasks to be happy? I will most certainly not do that.

1 Like

As I understand, the oceanSpice is a token simulator that’s running in the browser. Why is an integration with DataUnion’s backend needed?

Btw. I don’t doubt that the team members here are capable of achieving what was laid out. But I think they’d still have way higher chances of winning a grant if they’d decreased their funding amount.

Also: ROI calculation is missing.

TokenSpice is a Python library that runs on a server.
The parameters entered by the users in the browser have to be communicated to the backend where TokenSpice runs and the results have to be transported back to the users in the browser.

This is not answering my question directly. If I want a python server, there’s many to choose from like e.g. flask or tornado or whatever. Why is oceanSpice embedded into the DataUnion backend?

Also: Robin since you don’t seem to be fulltime on this anyways, I’d prefer to here from the proposal’s authors directly if you don’t mind.

As I am the management part of the proposal I also do the communication - the engineers do the engineering, the managers the negotiations.

DataUnion has a fully fledged out Python backend based on Docker, Docker Compose as well as REST APIs. The porting to this use case is minimal and saves a ton of time to setup a battle proven backend infrastructure.

OK good to know. So oceanSpice will be integrated into the DataUnion backend.
Since that’s the case, I think this proposal shouldn’t receive funding as I think the oceanDAO community would be better served for oceanSpice to be integrated in a standalone Python server framework (e.g. flask or what ever is envogue these days) and then put open source as a standalone repository.

No, it will be included into a fork of the DataUnion backend and this fork + the integration + web frontend will become a standalone open source GitHub repository.
This is all stated in the proposal above.

Well, intensive discussions here. :slight_smile:
This is Trang, one of the team members of oceanSPICE.
To me, discussions, arguments are part of progress but I don’t think saying something like “this proposal shouldn’t receive funding” is constructive.

We believe that oceanSPICE would brings high value to OCEAN ecosystem and benefits all stakeholders by token engineering so we decided to request maximum amount.

One example is for publishers (mentioned in the proposal): when publishing a datatoken and create a pool, lots of $OCEAN staking happens in early days which is not desired. Solving this with system design / token engineering is already super valuable for the ecosystem.

This DUNE Analytics Dashboard I just created shows what I mean by staking happens in early days, (you can query for any datatoken pool by pasting onto pool_address)

  • ROI calculation had been added
  • Surely more analyses would bring pool picture clearer
  • I’m not sure what is full time and details of the rule but solely stick with 1 person 1 proposal is not so effective in this case.
1 Like


Yes. I commend the effort of arguing with (e.g. Dune Analytics) data :clap:!

Here some of the sessions this proposal is based on with Trent McConaghy, founder of Ocean Protocol:

Introduction to TokenSpice:

Working session #1:

Working session #2:

1 Like

You can find the Trello board where we coordinate our progress and work here (public):

1 Like

@oceanSpice @trang.nv

OceanSpice please add 500 OCEAN to your wallet address. https://github.com/oceanprotocol/oceandao/wiki/project-criteria see criteria #3.

Thank you.

1 Like

Done, sent 500 $OCEAN to the wallet

Last week’s session with Trent:

oceanSPICE’s presentation for the Token Engineering Balancer Simulation course:

Live presentation of oceanSPICE at the TE Balancer Simulations - Final Presentations event: