diff --git a/content/posts/rfp-data-guilds.md b/content/posts/rfp-data-guilds.md new file mode 100644 index 0000000..ebedbf1 --- /dev/null +++ b/content/posts/rfp-data-guilds.md @@ -0,0 +1,55 @@ +--- +title: "RFP: Decentralized Oracles & Data Guilds" +date: 2024-03-11T16:34:13-04:00 +draft: true +--- + +Chainlink, but for long tail data sources. + +# Data Guilds +A data guild is a DAO setup on chain to source certain data feeds. For example, there may be a Data Guild for Weather in Mumbai, another for NBA scores etc. + +In this DAO, there are two key participants. +1. Subscribers - who use the data feeds +2. Oracles - who provide the data onchain + +# Coins +Each Data Guild has its own coin. +This coin governs the data feeds coming on chain. +This coin is used to +1. subscribe to feeds +2. stake to become an oracle + +These coins are sold off a bonding curve, against USDC. + +# Becoming an oracle +An oracle must commit to the API they're going to hit in order to fetch a certain data point. +Some APIs maybe behind paid plans. The API keys do not have to be revealed. They must use Reclaim Protocol to execute this. + +The oracle stakes 1000 coins to start providing the feed, and committing to provide the latest data point every, say, 30 min or relevant refresh time. +There can be multiple oracles per Data Guild. + +# Becoming a subscriber +The data needs to be submitted onchain only once - after which the data is accessible to everyone. + +To incentivize oracles to join, subscribers should pool together enough coins. Every refresh, all the oracles are paid proportional to their stake. +If there is a way to offset tragedy of commons issue here - that'd be a huge bonus. + +# Slashing +Every oracle must provide data at the refresh time. If not provided, they get slashed a little. + +Each time a data point is provided, there must be consensus between the oracles within an agreed upon margin of error. If the data provided by an oracle is not within accepted margin of error, they get slashed. + +The Reclaim proof provided must be a valid proof. If not, they're slashed fully. + +# DAO +Many decisions will be in the control of the DAO like +1. API to be used +2. Refresh time +3. Price per datapoint + +# Willing to build? +Apply here for a [grant upto $10K](https://questbook.app/dashboard/?grantId=0x7b9762f7584de695dbd8c8fdb1a8ce77e2bbad3b&chainId=10&role=community&proposalId=65e73f398bf7331fd0c729c2) + + + diff --git a/public/404.html b/public/404.html index 7f9872f..540b887 100644 --- a/public/404.html +++ b/public/404.html @@ -18,6 +18,7 @@ + + + + + + + + +
+ +
+
+ +
+
+ +

+ Staying GDPR Compliant + + + + + +

+
January 21, 2024 + +
+
+

Collecting user data using Reclaim helps you to further your compliance with GDPR. Particularly, GDPR’s requirement for explicity consent and purpose limitation.

+

| In the GDPR, “explicit consent” is detailed under Article 7, which emphasizes that consent must be freely given, specific, informed, and unambiguous, with a clear affirmative action from the data subject. As for “purpose limitation,” Article 5(1)(b) states that personal data must be collected for specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with those purposes. For the full legal text and further details, you can refer to the official GDPR legal text on gdpr-info.eu.

+

When using Reclaim Protocol, you, the developer would request the data using the following code

+
const client = new ReclaimClient(appSecret);
+//...
+client.addContext({ message : "Requesting data for Acme Corp Airdrop"});
+/...
+

When you set the context message in the request, the user is asked to provide an explicit approval to share this information with you. +When the user signs in and generates a proof of their data, they are also shown the context for this proof that is being requested. When the proof is generated, the proof also contains a cryptographic affirmation from the user that they have generated the proof for this purpose, and this purpose alone. Even if you store this information on your database, you’d also be storing the affirmation the user provided.

+

As long as you store information and use the information for the stated purpose alone - you are GDPR compliant

+ + +
+ + +
+
+ + + + + + + + + + + + + + diff --git a/public/posts/honey-pot/index.html b/public/posts/honey-pot/index.html index 46369dc..87a94eb 100644 --- a/public/posts/honey-pot/index.html +++ b/public/posts/honey-pot/index.html @@ -18,6 +18,7 @@ + + + + + + + + +
+ +
+
+ +
+
+ +

+ RFP: Decentralized Oracles & Data Guilds + + + + + +

+
March 11, 2024 + +
+
+

Chainlink, but for long tail data sources.

+

Data Guilds

+

A data guild is a DAO setup on chain to source certain data feeds. For example, there may be a Data Guild for Weather in Mumbai, another for NBA scores etc.

+

In this DAO, there are two key participants.

+
    +
  1. Subscribers - who use the data feeds
    2. +
  2. Oracles - who provide the data onchain
    3. +
+

Coins

+

Each Data Guild has its own coin. +This coin governs the data feeds coming on chain. +This coin is used to

+
    +
  1. subscribe to feeds
    2. +
  2. stake to become an oracle
    3. +
+

These coins are sold off a bonding curve, against USDC.

+

Becoming an oracle

+

An oracle must commit to the API they’re going to hit in order to fetch a certain data point. +Some APIs maybe behind paid plans. The API keys do not have to be revealed. They must use Reclaim Protocol to execute this.

+

The oracle stakes 1000 coins to start providing the feed, and committing to provide the latest data point every, say, 30 min or relevant refresh time. +There can be multiple oracles per Data Guild.

+

Becoming a subscriber

+

The data needs to be submitted onchain only once - after which the data is accessible to everyone.

+

To incentivize oracles to join, subscribers should pool together enough coins. Every refresh, all the oracles are paid proportional to their stake. +If there is a way to offset tragedy of commons issue here - that’d be a huge bonus.

+

Slashing

+

Every oracle must provide data at the refresh time. If not provided, they get slashed a little.

+

Each time a data point is provided, there must be consensus between the oracles within an agreed upon margin of error. If the data provided by an oracle is not within accepted margin of error, they get slashed.

+

The Reclaim proof provided must be a valid proof. If not, they’re slashed fully.

+

DAO

+

Many decisions will be in the control of the DAO like

+
    +
  1. API to be used
    2. +
  2. Refresh time
    3. +
  3. Price per datapoint
    4. +
+

Willing to build?

+

Apply here for a grant upto $10K

+ + +
+ + +
+
+ + + + + + + + + + + + + + diff --git a/public/posts/self-sovereign/index.html b/public/posts/self-sovereign/index.html index 9ab6971..ccd5f5d 100644 --- a/public/posts/self-sovereign/index.html +++ b/public/posts/self-sovereign/index.html @@ -19,6 +19,7 @@ +