Ecocredit Module on Mainnet #78
Comments
do-not-edit-start-codetree-epic-issuesIssues in this epic:
do-not-edit-end-codetree-epic-issues |
|
I would defer on-chain geospatial indexing to later release, it's not needed for Mainnet release and early adopter projects where we doing things in a concierge model that does not allow duplicity. |
|
One piece we still need to iron out here is whether to take a whitelisted approach to credit class creation, or just prevent spam with a non-negligible fee (e.g. $100-500 USD equivalent). Benefits of a whitelisted approach (upgradable via governance) is that we fully restrict who can issue credit classes during this early stage. It will also make upgrades easier potentially when we connect the credit module more fully to the data module & SHACL schema work. On the other hand, fees are much more permissionless than whitelisting. And we will initially be providing some basic filtering of credits on Regen Registry, so it might not be that important to have such strict filtering on the blockchain itself. |
|
I voiced my opinion on this specific matter, I rather initially start with
more restricted approach and then open it up to permissionless once we have
at least some basic curation service on the network. My main concern is
spam on the network and though Aaron said that $500 will limit 95% of the
spammers probably, that still leaves the room to a few troublemakers who
can make a bad impression and negative PR at a time where we should be
building up our reputation and as we want to potentially increase the token
value through access to liquidity pools/DEXs.
At the same time, I do not want to limit any legitimate potential
developers who want to tinker and try out things.
A couple thoughts I had that might be a more 'both and' approach:
- Can we developers work on a beta/testnet environment, that we or someone
like Daniel Swid (a validator) set up that will allow developers to easily
integrate with ? He is happy to do so.
- Start with a whitelist approach that has a built in sunset clause that
within let's say 12 months would be replaced by $500 fee (i.e.
permissionless structure) - this would give us enough time to build out the
scaffolds, hopefully get some legitimate credits onchain and creating some
positive PR around a few deals.
- Can the whitelist governance (i.e. what issuers are added/removed from
list) be more agile, i.e. voting on proposals every week rather than three
weeks?
…On Fri, Apr 16, 2021 at 2:58 PM Cory ***@***.***> wrote:
One piece we still need to iron out here is whether to take a whitelisted
approach to credit class creation, or just prevent spam with a
non-negligible fee (e.g. $100-500 USD equivalent).
Benefits of a whitelisted approach (upgradable via governance) is that we
fully restrict who can issue credit classes during this early stage. It
will also make upgrades easier potentially when we connect the credit
module more fully to the data module & SHACL schema work.
On the other hand, fees are much more permissionless than whitelisting.
And we will initially be providing some basic filtering of credits on Regen
Registry, so it might not be that important to have such strict filtering
on the blockchain itself.
@glandua <https://github.com/glandua> @aaronc <https://github.com/aaronc>
@rsteinhe <https://github.com/rsteinhe> thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#78 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVQK3XXSDU3TLBBQSOLANLTJCXHHANCNFSM4JE26VTA>
.
--
<https://www.regen.network/>
Ron Steinherz
VP Product
www.regen.network
+1 408 318 9484
<https://medium.com/regen-network> <http://t.me/regennetwork_public>
<https://twitter.com/regen_network?lang=en>
<https://www.facebook.com/weareregennetwork/>
|
|
This might be a good place to start stewarding and innovating some community governance. The decision on whitelisting could be delegated from the full on-chain governance to a working group or the foundation for example. When we do that we will probably want to have some decent governance user interfaces built around the group module. @glandua would love for you to chime in here. |
|
Permissioned access is against the blockchain ethos. While it makes sens to start with whitelist of users who can issue tokens, IMHO, we shouldn't wait too much with opening the access. Right fee model should solve the spam. BTW: spam is a nature of open internet. |
The baikal upgrade of Regen Ledger (v2.0.0) will include the first mainnet incarnation of the ecocredit module.
While the ecocredit module has existed in Regen Ledger for some time, a number of additional requirements have come up that we've decided to include in the featureset for the Baikal Upgrade (e.g. when the ecocredit module is available in mainnet).
Initial Featureset
For prior context on the initial specification of the ecocredit module, please see RFC-001 (#107). This is the featureset that is live on Regen Ledger devnet, which is currently being used (in beta) by Regen Registry for tracking vintages of the CarbonPlus Grasslands credit.
Mainnet Featureset
The following additional features are being added to the ecocredit module for the Baikal Upgrade:
Note- several other minor implementation & testing tickets are also being addressed for the Baikal Upgrade, but for simplicity, the above list only enumerates changes that affect the featureset of the ecocredit module.
Post-Mainnet Ecocredit Module
In preparing for the mainnet launch of the ecocredit module, we've come across a handful of larger items that warrant a larger design conversation about Regen Ledger's data model, and how that relates to the top-level fields stored alongside credit batches.
For the collection of these requirements and refining into a concrete specification, we'll be tracking these items as as separate epic, in #439
The text was updated successfully, but these errors were encountered: