From cf3b119282c30ea93a14cd09ae03d274f99f1d3d Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Mon, 5 Sep 2022 09:10:00 -0700 Subject: [PATCH 01/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 333 ++++++++++++++++++++++ 1 file changed, 333 insertions(+) create mode 100644 specs/rfcs/003-forward-contract/README.md diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md new file mode 100644 index 0000000000..c09a79743d --- /dev/null +++ b/specs/rfcs/003-forward-contract/README.md @@ -0,0 +1,333 @@ +# RFC-003: Forward Contract + +- Created: YYYY-MM-DD +- Status: __DRAFT__ | __IN REVIEW__ | __ACCEPTED__ | __REJECTED__ | __SUPERSEDED__ | __ABANDONED__ +- Superseded By: +- RFC PR: [#]() +- Authors: + +### Table of Contents + +- [Summary](#summary) +- [Need](#need) +- [Approach](#approach) +- [Rationale](#rationale) +- [References](#references) +- [Changelog](#changelog) + +## Summary + + + +This RFC aims to lay out a high-level architecture and feature set for forward contract functionality. + +... + +## Need + + + +Regen Ledger enables entities (individuals or organizations) to design and issue credits for ecosystem services in the form of on-chain assets. Ecosystem service credits represent positive ecological outcomes and are issued after those outcomes have been measured and quantified. Project developers receive payment for their services after buyers purchase credits and are therefore responsible for covering upfront costs or seeking out financial support from off-chain sources. + +Forward contract functionality would enable project developers to offer a percentage of future credits issued and receive funding before those credits have been measured and quantified. Project developers would work alongside credit class issuers to design a forward contract that would offer a percentage of future credits issued in exchange for funding. After the contract has been approved, investors would be able to fund the project in exchange for a percentage of future credits issued from the project. + +... + +### Earthbanc Use Case + +... + +### Another Use Case + +... + +### Another Use Case + +... + +## Approach + + + +Forward contract functionality would be implemented as a `contract` submodule within the ecocredit module. For reference, [(x/ecocredit): forward contract proof-of-concept][2] was submitted as an initial proof-of-concept to help with framing forward contract functionality within the existing ecocredit module. + +... + +Investors would have the option of either receiving direct issuance of credits when credits are issued from the project or receiving tokens that would represent their claim on the contract and later be used to redeem credits from a claim account (i.e. an account managed by the submodule). Direct issuance would enable investors to optionally receive credits in a retired state upon issuance and investors would not have the ability to transfer their claim. Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to redeem credits at a later point in time. + +1. The direct issuance of credits would be managed by an issuance policy and the policy would be added at the time of funding the project including the address of the investor and the percent of credits to be issued to the investor. + +2. When receiving tokens that represent a claim, the amount of tokens received would be calculated based on the percent of credits that the investor has a claim to and the tokens would be specific to the project and the most recent batch claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created (or updated) using a claim account as the recipient. Investor would then be free to transfer the tokens and the owner(s) of the tokens would then be able to claim the credits at a time of their choosing. When credits are claimed, the owner of the tokens would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to redeem credits. The token denom for claim tokens would include the batch sequence number of the most recent batch claimed and redeeming credits would burn the tokens used to claim the credits and return new tokens with an updated denom. + +### Create Contract + +A project admin can create a contract. The contract is "proposed" until "approved" by a credit class issuer. + +```protobuf +// MsgCreate is the Msg/Create request type. +message MsgCreate { + + // project_id is the unique identifier of the project. + string project_id = 1; + + // project_admin is the admin of the project. + string project_admin = 2; + + // metadata is any arbitrary string that includes or references additional + // information about the contract such as estimated total supply, forward + // contract supply, and estimated price per credit type unit. + string metadata = 3; + + // funds_to_collect is the denom and amount the project is collecting. + cosmos.base.v1beta1.Coin funds_to_collect = 4; + + // volume_percentage is the percent of all credits issued that will be + // available to purchase. + string volume_percentage = 5; + + // start_date is the delivery start date. + google.protobuf.Timestamp start_date = 6; + + // end_date is the delivery end date. + google.protobuf.Timestamp end_date = 7; +} +``` + +```feature +Rule: Only a project admin can create a contract for their project +``` + +### Update Contract + +A project admin can update a contract with status "proposed". Once the contract status is "approved", the contract cannot be updated. + +```protobuf +// MsgUpdate is the Msg/Update request type. +message MsgUpdate { + + // id is the unique identifier of the contract. + uint64 id = 1; + + // project_admin is the admin of the project. + string project_admin = 2; + + // metadata is any arbitrary string that includes or references additional + // information about the contract such as estimated total supply, forward + // contract supply, and estimated price per credit type unit. + string metadata = 3; + + // funds_to_collect is the denom and amount the project is collecting. + cosmos.base.v1beta1.Coin funds_to_collect = 4; + + // volume_percentage is the percent of all credits issued that will be + // available to purchase. + string volume_percentage = 5; + + // start_date is the delivery start date. + google.protobuf.Timestamp start_date = 6; + + // end_date is the delivery end date. + google.protobuf.Timestamp end_date = 7; +} +``` + +```feature +Rule: Only a project admin can update a contract for their project +``` + +### Cancel Contract + +A project admin can cancel a contract with status "proposed". Once the contract status is "approved", the contract cannot be cancelled. + +```protobuf +// MsgCancel is the Msg/Cancel request type. +message MsgCancel { + + // id is the unique identifier of the contract. + uint64 id = 1; + + // project_admin is the admin of the project. + string project_admin = 2; +} +``` + +```feature +Rule: Only a project admin can cancel a contract for their project +``` + +### Approve Contract + +A credit class issuer can approve a contract. Once the contract is "approved", the contract cannot be updated and any account can fund the project. + +```protobuf +// MsgApprove is the Msg/Approve request type. +message MsgApprove { + + // id is the unique identifier of the contract. + uint64 id = 1; + + // class_issuer is the address of the credit class issuer that is approving + // the contract on behalf of the credit class. + string class_issuer = 2; +} +``` + +```feature +Rule: The volume percentage cannot exceed the sum percentage of existing issuance policies +``` + +```feature +Rule: An issuance policy is created for tradable credits and the submodule address is the recipient +``` + +### Fund Project + +Any account can view available contracts and fund a project. When an account funds a project, the account has a claim to credits issued from the project. The funds are transferred to the project admin. + +When an account funds a project and therefore owns a claim on future credits issued from the project, an issuance policy is automatically created and managed programmatically (i.e. no account has the authority to update the issuance policy and issuance policies would require a property that distinguishes policies managed programmatically from those managed by accounts with authority). + +```protobuf +// MsgFundProject is the Msg/FundProject request type. +message MsgFundProject { + + // id is the unique identifier of the contract. + uint64 id = 1; + + // funder is the address of the account funding the project and receiving a + // share of future credits issued from the project. + string funder = 2; + + // volume_percentage is the percent of all credits issued that the funder will + // receive. + string volume_percentage = 3; + + // funds is the token denom and amount the funder is providing in return for + // the specified volume percentage. + cosmos.base.v1beta1.Coin funds = 4; + + // direct_issuance determines whether the credits will be automatically issued + // to the funder (i.e. the funder account will be assigned as the recipient of + // the issuance policy) or whether the funder will receive claim tokens (i.e. + // the contract submodule will be assigned as the recipient of the issuance + // policy and the credits can be claimed at a later point in time). + bool direct_issuance = 5; + + // auto_retire determines whether the credits will be automatically retied upon + // issuance (i.e. the issuance policy will be set to auto-retire). This option + // only applies if direct issuance is enabled. + bool auto_retire = 6; + + // retirement_jurisdiction is the jurisdiction of the funder. A jurisdiction is + // only required if auto-reture is enabled. + string retirement_jurisdiction = 7; +} +``` + +```feature +Rule: The contract must be approved +``` + +```feature +Rule: The funds denom must match the denom defined in the contract +``` + +```feature +Rule: The funds amount must be greater than or equal to the calculated cost +``` + +```feature +Rule: The funds are deducted from the funder +``` + +```feature +Rule: The funds are added to the project admin +``` + +### Contract State + +```protobuf +// Contract defines a forward contract and the table within which the forward +// contract is stored. +message Contract { + option (cosmos.orm.v1alpha1.table) = { + id : 1, + primary_key : {fields : "id", auto_increment : true} + }; + + // id is the table row identifier of the contract. + uint64 id = 1; + + // project_id is the unique identifier of the project. + string project_id = 2; + + // status is the status of the contract (e.g. "proposed", "approved"). + ContractStatus status = 3; + + // metadata is any arbitrary string that includes or references additional + // information about the contract including the initial amount of funds to + // collect, the initial volume percentage offered, estimated total supply, + // forward contract supply, and estimated price per credit type unit. + google.protobuf.Timestamp metadata = 4; + + // volume_percentage is the remaining percent of all credits issued that + // are be available to claim. + string volume_percentage = 5; + + // funds_to_collect is the denom and remaining amount of funds the project + // is collecting. + cosmos.base.v1beta1.Coin funds_to_collect = 6; + + // start_date is the delivery start date. + google.protobuf.Timestamp start_date = 7; + + // end_date is the delivery end date. + google.protobuf.Timestamp end_date = 8; +} +``` + +### Contract Expiration + +How does contract expiration work? + +- (1) The issuance policy is removed on the end date and therefore no further credits are issued as a result of the contract. +- (2) The issuance policy is never removed. The issuance policy defines a range of dates within which the policy is valid and the amount of credits issued is calculated based on the batch end date and contract end date. + +### Automated Credit Issuance + +The credits issued to funders or to the claim account would be enforced programmatically. The functionality to support this will be explored as a separate feature set. + + +See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. + +### Project Approval Process + +In additional to forward contract functionality, the [Forward Contract Bond Module][1] document describes a set of features around a project approval process. The contract approval process only partially fulfills the outlined approval process. Additional functionality is being explored independently of the functionality described within this document and, although these features might be built in parallel, one is not dependent on the other. + +The existing credit class and project functionality can be used to accomplish the project approval process outlined in [Forward Contract Bond Module][1]. In the current implementation, a project can only be created within a credit class by an approved issuer of the credit class. An organization that intends to audit projects would need to administer a credit class and designate issuers to manage project audits. The application process would be handled off chain and the issuer would approve a project by creating a project on chain. + + +See [(x/ecocredit): independent projects proof-of-concept][4] for more information. + +## Rationale + + + +... + +## References + +1. [Forward Contract Bond Module][1] +2. [(x/ecocredit): forward contract proof-of-concept][2] +3. [(x/ecocredit): issuance policy proof-of-concept][3] +4. [(x/ecocredit): independent projects proof-of-concept][4] + +[1]: https://docs.google.com/document/d/1_BMb7dUVdYEiL5n1LNCjHtd6WYPXgxRY_gwflIwCXgE +[2]: https://github.com/regen-network/regen-ledger/pull/1420 +[3]: https://github.com/regen-network/regen-ledger/pull/1421 +[4]: https://github.com/regen-network/regen-ledger/pull/1422 + +## Changelog + + + +- [](#) First draft submitted by From c7a9344b7627208f057e7862321fd04055819103 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Mon, 5 Sep 2022 09:29:45 -0700 Subject: [PATCH 02/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index c09a79743d..f2e47e04f4 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -74,8 +74,9 @@ message MsgCreate { string project_admin = 2; // metadata is any arbitrary string that includes or references additional - // information about the contract such as estimated total supply, forward - // contract supply, and estimated price per credit type unit. + // information about the contract including the initial amount of funds to + // collect, the initial volume percentage offered, estimated total supply, + // forward contract supply, and estimated price per credit type unit. string metadata = 3; // funds_to_collect is the denom and amount the project is collecting. @@ -112,8 +113,9 @@ message MsgUpdate { string project_admin = 2; // metadata is any arbitrary string that includes or references additional - // information about the contract such as estimated total supply, forward - // contract supply, and estimated price per credit type unit. + // information about the contract including the initial amount of funds to + // collect, the initial volume percentage offered, estimated total supply, + // forward contract supply, and estimated price per credit type unit. string metadata = 3; // funds_to_collect is the denom and amount the project is collecting. From 9259e513d35c6d86405312dca6144734f24dfdd9 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Wed, 11 Jan 2023 20:30:06 -0800 Subject: [PATCH 03/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 59 ++++++++++++----------- 1 file changed, 32 insertions(+), 27 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index f2e47e04f4..01d52b955d 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -1,10 +1,10 @@ # RFC-003: Forward Contract -- Created: YYYY-MM-DD -- Status: __DRAFT__ | __IN REVIEW__ | __ACCEPTED__ | __REJECTED__ | __SUPERSEDED__ | __ABANDONED__ -- Superseded By: -- RFC PR: [#]() -- Authors: +- Created: 2023-01-12 +- Status: __IN REVIEW__ +- Superseded By: NA +- RFC PR: [#1474](https://github.com/regen-network/regen-ledger/pull/1474) +- Authors: @ryanchristo ### Table of Contents @@ -21,15 +21,15 @@ This RFC aims to lay out a high-level architecture and feature set for forward contract functionality. -... - ## Need -Regen Ledger enables entities (individuals or organizations) to design and issue credits for ecosystem services in the form of on-chain assets. Ecosystem service credits represent positive ecological outcomes and are issued after those outcomes have been measured and quantified. Project developers receive payment for their services after buyers purchase credits and are therefore responsible for covering upfront costs or seeking out financial support from off-chain sources. +Regen Ledger enables entities (individuals or organizations) to design and issue credits for ecosystem services in the form of on-chain assets. Ecosystem service credits represent positive ecological outcomes and are issued after those outcomes have been measured and quantified. Project developers receive payment for their services only after buyers purchase their credits and projects are therefore responsible for covering upfront costs or seeking out financial support to start or continue providing ecosystem services. -Forward contract functionality would enable project developers to offer a percentage of future credits issued and receive funding before those credits have been measured and quantified. Project developers would work alongside credit class issuers to design a forward contract that would offer a percentage of future credits issued in exchange for funding. After the contract has been approved, investors would be able to fund the project in exchange for a percentage of future credits issued from the project. +Forward contract functionality would enable project developers to offer a percentage of future credits issued and receive funding before those credits have been measured and quantified. Project developers would work alongside credit class issuers to submit a forward contract that would offer a percentage of future credits issued in exchange for upfront funding. After the contract has been approved, investors would be able to provide upfront funding for the project in exchange for a percentage of future credits issued from the project. + +### Fast Forward Pilot ... @@ -37,27 +37,27 @@ Forward contract functionality would enable project developers to offer a percen ... -### Another Use Case +## Approach -... + -### Another Use Case +Forward contract functionality would be implemented as a `contract` submodule within the existing `ecocredit` module. For reference, [(x/ecocredit): forward contract proof-of-concept][2] was submitted as an initial proof-of-concept to help illustrate this architecture. -... +This proposal separates the approach into multiple stages of implementation. The initial stage (i.e. [Stage 1](#stage-1) is designed to serve the needs of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2) is designed to serve the remaining needs of the [Earthbanc Use Case](#earthbanc-use-case). -## Approach +### Stage 1 - +The first stage includes the implementation of direct credit issuance and support for forward contracts that are specific to a single project whereby the project is properly vetted by a credit class issuer and the risk is shared by the credit class (a risk in reserve and reputation) and the investor(s) (a risk in investment). -Forward contract functionality would be implemented as a `contract` submodule within the ecocredit module. For reference, [(x/ecocredit): forward contract proof-of-concept][2] was submitted as an initial proof-of-concept to help with framing forward contract functionality within the existing ecocredit module. +In this initial implementation, there is only one option for receiving future credits issued, which is the direct issuance of credits to the account that has a claim on the forward contract. The credits are delivered over-time as they are issued from the project; the account that has a claim to future credits (i.e. the investor) receives a percentage of each credit batch issuance that has a monitoring period within the timeframe of the contract. The percentage of credits delivered with each credit batch issuance is based on the percentage of the claim to future credits and enforced by on-chain functionality. -... +Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s) and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer (either an individual or group account) that approves the contract will be responsible for following that process and assessing the risk of the project. -Investors would have the option of either receiving direct issuance of credits when credits are issued from the project or receiving tokens that would represent their claim on the contract and later be used to redeem credits from a claim account (i.e. an account managed by the submodule). Direct issuance would enable investors to optionally receive credits in a retired state upon issuance and investors would not have the ability to transfer their claim. Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to redeem credits at a later point in time. +The price and volume estimates for the credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the price and volume estimates are calculated are outside the scope of the on-chain functionality outlined within this proposal but additional information about how the calculations were made can and should be stored within the forward contract as metadata. -1. The direct issuance of credits would be managed by an issuance policy and the policy would be added at the time of funding the project including the address of the investor and the percent of credits to be issued to the investor. +To mitigate the risk of the project under-delivering and therefore the risk in investment, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be transferred by the credit class issuer. The reserve pool can only receive credits once the contract has been approved and the credits in the reserve pool would be held escrow until the end of the contract. The reserve pool can only receive credits from the same credit class and up to the volume of future credits being sold via the forward contract and the credits can only be transferred by the credit class issuer or the project admin defined in the contract. Whether the reserve pool backs the total volume of future credits being sold is up to the credit class issuer with more credits providing less risk for the investor(s) and more likelihood of the project receiving pre-financing. -2. When receiving tokens that represent a claim, the amount of tokens received would be calculated based on the percent of credits that the investor has a claim to and the tokens would be specific to the project and the most recent batch claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created (or updated) using a claim account as the recipient. Investor would then be free to transfer the tokens and the owner(s) of the tokens would then be able to claim the credits at a time of their choosing. When credits are claimed, the owner of the tokens would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to redeem credits. The token denom for claim tokens would include the batch sequence number of the most recent batch claimed and redeeming credits would burn the tokens used to claim the credits and return new tokens with an updated denom. +The accepted form of funds (the token denomination) is decided by the project admin and approved by the credit class issuer. There are no restrictions on which token denomination the project chooses to receive funding but a stable coin would be the most probably choice. ### Create Contract @@ -184,7 +184,7 @@ Rule: An issuance policy is created for tradable credits and the submodule addre ### Fund Project -Any account can view available contracts and fund a project. When an account funds a project, the account has a claim to credits issued from the project. The funds are transferred to the project admin. +Any account can view available contracts and fund a project. When an account funds a project, the account has a claim to credits issued from the project. The funds are transferred directly to the project admin. When an account funds a project and therefore owns a claim on future credits issued from the project, an issuance policy is automatically created and managed programmatically (i.e. no account has the authority to update the issuance policy and issuance policies would require a property that distinguishes policies managed programmatically from those managed by accounts with authority). @@ -289,14 +289,11 @@ message Contract { ### Contract Expiration -How does contract expiration work? - -- (1) The issuance policy is removed on the end date and therefore no further credits are issued as a result of the contract. -- (2) The issuance policy is never removed. The issuance policy defines a range of dates within which the policy is valid and the amount of credits issued is calculated based on the batch end date and contract end date. +The contract will automatically expire once the contracted credit volume has been delivered or when the contract end date is reached. If the end date is reached before the volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. ### Automated Credit Issuance -The credits issued to funders or to the claim account would be enforced programmatically. The functionality to support this will be explored as a separate feature set. +Direct credit issuance to investor will be enforced with on-chain functionality. At the time of funding the project, investors would have the option of choosing to receive credits in a retired or tradable state upon issuance. This functionality will be handled by "issuance policies" and explored as a separate feature set built alongside the initial implementation of forward contract functionality. See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. @@ -310,6 +307,14 @@ The existing credit class and project functionality can be used to accomplish th See [(x/ecocredit): independent projects proof-of-concept][4] for more information. +### Stage 2 + +Investors would have the option of receiving tokens that would represent their claim on the contract and later be used to redeem credits from a claim account (i.e. an account managed by the submodule). Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to redeem credits at a later point in time. + +When receiving tokens that represent a claim, the amount of tokens received would be calculated based on the percent of credits that the investor has a claim to and the tokens would be specific to the project and the most recent batch claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created (or updated) using a claim account as the recipient. Investor would then be free to transfer the tokens and the owner(s) of the tokens would then be able to claim the credits at a time of their choosing. + +When credits are claimed, the owner of the tokens would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to redeem credits. The token denom for claim tokens would include the batch sequence number of the most recent batch claimed and redeeming credits would burn the tokens used to claim the credits and return new tokens with an updated denom. + ## Rationale @@ -332,4 +337,4 @@ See [(x/ecocredit): independent projects proof-of-concept][4] for more informati -- [](#) First draft submitted by +- [#1474](https://github.com/regen-network/regen-ledger/pull/1474) First draft submitted by @ryanchristo From 8b2593f4d9227b7c209a0fc81e54999d8fde857f Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Wed, 11 Jan 2023 22:51:27 -0800 Subject: [PATCH 04/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 94 ++++++++++------------- 1 file changed, 42 insertions(+), 52 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index 01d52b955d..b46d6fb9be 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -1,7 +1,7 @@ # RFC-003: Forward Contract - Created: 2023-01-12 -- Status: __IN REVIEW__ +- Status: __DRAFT__ - Superseded By: NA - RFC PR: [#1474](https://github.com/regen-network/regen-ledger/pull/1474) - Authors: @ryanchristo @@ -25,9 +25,9 @@ This RFC aims to lay out a high-level architecture and feature set for forward c -Regen Ledger enables entities (individuals or organizations) to design and issue credits for ecosystem services in the form of on-chain assets. Ecosystem service credits represent positive ecological outcomes and are issued after those outcomes have been measured and quantified. Project developers receive payment for their services only after buyers purchase their credits and projects are therefore responsible for covering upfront costs or seeking out financial support to start or continue providing ecosystem services. +Regen Ledger enables entities (individuals or organizations) to design and issue credits for ecosystem services in the form of on-chain assets. Ecosystem service credits represent positive ecological outcomes and are issued after those outcomes have been measured and quantified. Project developers receive payment for their services after buyers purchase their credits and projects are therefore responsible for covering upfront costs or seeking out financial support to start or continue providing ecosystem services. -Forward contract functionality would enable project developers to offer a percentage of future credits issued and receive funding before those credits have been measured and quantified. Project developers would work alongside credit class issuers to submit a forward contract that would offer a percentage of future credits issued in exchange for upfront funding. After the contract has been approved, investors would be able to provide upfront funding for the project in exchange for a percentage of future credits issued from the project. +Forward contract functionality would enable project developers to offer a percentage of future credits issued and receive funding before those credits have been measured and quantified. A Project developer would work alongside a credit class issuer to estimate the volume and price of the future credits and then submit a forward contract to be approved by the credit class issuer. Investors would then be able to claim a future percentage of credits issued from the project in exchange for upfront funding. ### Fast Forward Pilot @@ -41,23 +41,23 @@ Forward contract functionality would enable project developers to offer a percen -Forward contract functionality would be implemented as a `contract` submodule within the existing `ecocredit` module. For reference, [(x/ecocredit): forward contract proof-of-concept][2] was submitted as an initial proof-of-concept to help illustrate this architecture. +Forward contract functionality would be implemented as a `contract` submodule within the `ecocredit` module. For reference, [(x/ecocredit): forward contract proof-of-concept][2] was submitted as an initial proof-of-concept to help illustrate this architecture. -This proposal separates the approach into multiple stages of implementation. The initial stage (i.e. [Stage 1](#stage-1) is designed to serve the needs of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2) is designed to serve the remaining needs of the [Earthbanc Use Case](#earthbanc-use-case). +This proposal separates the approach into multiple stages. The initial stage (i.e. [Stage 1](#stage-1) is designed to serve the needs of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2) is designed to serve the remaining needs of the [Earthbanc Use Case](#earthbanc-use-case). The first version of this document focuses on Stage 1 and only introduces Stage 2. Stage 2 (and additional stages) will be further explored in subsequent versions. ### Stage 1 -The first stage includes the implementation of direct credit issuance and support for forward contracts that are specific to a single project whereby the project is properly vetted by a credit class issuer and the risk is shared by the credit class (a risk in reserve and reputation) and the investor(s) (a risk in investment). +The first stage includes the implementation of direct credit issuance and support for forward contracts that are specific to a single project whereby the project is vetted by a credit class issuer and the risk of the project under-delivering is either shared by the credit class (a risk in reserve and reputation) and the investor(s) (a risk in investment) or held solely by the credit class (the credit class provides a reserve pool that fully backs the future credits issued). -In this initial implementation, there is only one option for receiving future credits issued, which is the direct issuance of credits to the account that has a claim on the forward contract. The credits are delivered over-time as they are issued from the project; the account that has a claim to future credits (i.e. the investor) receives a percentage of each credit batch issuance that has a monitoring period within the timeframe of the contract. The percentage of credits delivered with each credit batch issuance is based on the percentage of the claim to future credits and enforced by on-chain functionality. +There is only one option for receiving future credits issued, which is the direct issuance of credits to the account that has a claim on the forward contract (i.e. the investor). In this case, the credits are delivered as they are issued from the project; the investor receives a percentage of each credit batch issuance that has a monitoring period that meets the date criteria of the contract. The percentage of credits delivered with each credit batch issuance is based on the percentage of the claim to future credits and enforced by on-chain functionality. -Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s) and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer (either an individual or group account) that approves the contract will be responsible for following that process and assessing the risk of the project. +Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s) and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project or working with a third party or other members of the credits class to do so. The price and volume estimates for the credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the price and volume estimates are calculated are outside the scope of the on-chain functionality outlined within this proposal but additional information about how the calculations were made can and should be stored within the forward contract as metadata. -To mitigate the risk of the project under-delivering and therefore the risk in investment, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be transferred by the credit class issuer. The reserve pool can only receive credits once the contract has been approved and the credits in the reserve pool would be held escrow until the end of the contract. The reserve pool can only receive credits from the same credit class and up to the volume of future credits being sold via the forward contract and the credits can only be transferred by the credit class issuer or the project admin defined in the contract. Whether the reserve pool backs the total volume of future credits being sold is up to the credit class issuer with more credits providing less risk for the investor(s) and more likelihood of the project receiving pre-financing. +To mitigate the risk of the investor and therefore improve the likelihood of investment, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be transferred. The reserve pool can only receive credits once the contract has been approved and the credits in the reserve pool will be held in escrow until the end of the contract. The reserve pool can only receive credits from the same credit class and the credits can only be transferred to the reserve pool by the credit class issuer. Whether the reserve pool backs the total volume of future credits being sold is up to the credit class issuer - more credits providing less risk for the investor(s) and more likelihood of the project receiving pre-financing. -The accepted form of funds (the token denomination) is decided by the project admin and approved by the credit class issuer. There are no restrictions on which token denomination the project chooses to receive funding but a stable coin would be the most probably choice. +The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer. There are no restrictions on which token denomination the project chooses to receive funding but the token denomination cannot be updated and a stable coin would be the most probable choice. ### Create Contract @@ -82,20 +82,20 @@ message MsgCreate { // funds_to_collect is the denom and amount the project is collecting. cosmos.base.v1beta1.Coin funds_to_collect = 4; - // volume_percentage is the percent of all credits issued that will be + // volume_percentage is the percent of future credits issued that will be // available to purchase. string volume_percentage = 5; - // start_date is the delivery start date. + // start_date is the contract start date. google.protobuf.Timestamp start_date = 6; - // end_date is the delivery end date. + // end_date is the contract end date. google.protobuf.Timestamp end_date = 7; } ``` ```feature -Rule: Only a project admin can create a contract for their project +Rule: Only the project admin can create a contract ``` ### Update Contract @@ -121,20 +121,20 @@ message MsgUpdate { // funds_to_collect is the denom and amount the project is collecting. cosmos.base.v1beta1.Coin funds_to_collect = 4; - // volume_percentage is the percent of all credits issued that will be + // volume_percentage is the percent of future credits issued that will be // available to purchase. string volume_percentage = 5; - // start_date is the delivery start date. + // start_date is the contract start date. google.protobuf.Timestamp start_date = 6; - // end_date is the delivery end date. + // end_date is the contract end date. google.protobuf.Timestamp end_date = 7; } ``` ```feature -Rule: Only a project admin can update a contract for their project +Rule: Only the project admin can update the contract ``` ### Cancel Contract @@ -154,7 +154,7 @@ message MsgCancel { ``` ```feature -Rule: Only a project admin can cancel a contract for their project +Rule: Only a project admin can cancel the contract ``` ### Approve Contract @@ -178,15 +178,11 @@ message MsgApprove { Rule: The volume percentage cannot exceed the sum percentage of existing issuance policies ``` -```feature -Rule: An issuance policy is created for tradable credits and the submodule address is the recipient -``` - ### Fund Project -Any account can view available contracts and fund a project. When an account funds a project, the account has a claim to credits issued from the project. The funds are transferred directly to the project admin. +Any account can view available contracts and fund a project. When an account funds a project, the account has a claim to future credits issued from the project. The funds are transferred directly to the project admin. -When an account funds a project and therefore owns a claim on future credits issued from the project, an issuance policy is automatically created and managed programmatically (i.e. no account has the authority to update the issuance policy and issuance policies would require a property that distinguishes policies managed programmatically from those managed by accounts with authority). +When an account funds a project and therefore owns a claim on future credits issued from the project, an issuance policy is automatically created and managed programmatically (i.e. no account has the authority to update the issuance policy and the issuance policy would only expire when the contract has ended). ```protobuf // MsgFundProject is the Msg/FundProject request type. @@ -204,24 +200,17 @@ message MsgFundProject { string volume_percentage = 3; // funds is the token denom and amount the funder is providing in return for - // the specified volume percentage. + // the specified volume percentage. The required amount is determined based on + // the volume percentage provided and only the required amount is sent. cosmos.base.v1beta1.Coin funds = 4; - // direct_issuance determines whether the credits will be automatically issued - // to the funder (i.e. the funder account will be assigned as the recipient of - // the issuance policy) or whether the funder will receive claim tokens (i.e. - // the contract submodule will be assigned as the recipient of the issuance - // policy and the credits can be claimed at a later point in time). - bool direct_issuance = 5; - // auto_retire determines whether the credits will be automatically retied upon - // issuance (i.e. the issuance policy will be set to auto-retire). This option - // only applies if direct issuance is enabled. - bool auto_retire = 6; + // issuance (i.e. the issuance policy will be set to auto-retire). + bool auto_retire = 5; // retirement_jurisdiction is the jurisdiction of the funder. A jurisdiction is - // only required if auto-reture is enabled. - string retirement_jurisdiction = 7; + // only required if auto-retire is enabled. + string retirement_jurisdiction = 6; } ``` @@ -238,18 +227,17 @@ Rule: The funds amount must be greater than or equal to the calculated cost ``` ```feature -Rule: The funds are deducted from the funder +Rule: The funds are deducted from the token balance of the funder ``` ```feature -Rule: The funds are added to the project admin +Rule: The funds are added to the token balance of the project admin ``` ### Contract State ```protobuf -// Contract defines a forward contract and the table within which the forward -// contract is stored. +// Contract defines a forward contract and the forward contract table. message Contract { option (cosmos.orm.v1alpha1.table) = { id : 1, @@ -279,41 +267,43 @@ message Contract { // is collecting. cosmos.base.v1beta1.Coin funds_to_collect = 6; - // start_date is the delivery start date. + // start_date is the contract start date. google.protobuf.Timestamp start_date = 7; - // end_date is the delivery end date. + // end_date is the contract end date. google.protobuf.Timestamp end_date = 8; } ``` ### Contract Expiration -The contract will automatically expire once the contracted credit volume has been delivered or when the contract end date is reached. If the end date is reached before the volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. +The contract will automatically expire once the contracted credit volume has been delivered or when the contract end date is reached. If the end date is reached before the contracted credit volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. ### Automated Credit Issuance -Direct credit issuance to investor will be enforced with on-chain functionality. At the time of funding the project, investors would have the option of choosing to receive credits in a retired or tradable state upon issuance. This functionality will be handled by "issuance policies" and explored as a separate feature set built alongside the initial implementation of forward contract functionality. +Direct credit issuance to the investor(s) will be enforced with on-chain functionality. At the time of funding the project, an investor has the option of choosing to receive credits in a retired or tradable state upon issuance. This functionality will be handled by "issuance policies" and explored as a separate feature set built alongside the initial implementation stage of forward contract functionality. See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. ### Project Approval Process -In additional to forward contract functionality, the [Forward Contract Bond Module][1] document describes a set of features around a project approval process. The contract approval process only partially fulfills the outlined approval process. Additional functionality is being explored independently of the functionality described within this document and, although these features might be built in parallel, one is not dependent on the other. +In additional to forward contract functionality, the [Forward Contract Bond Module][1] document describes a set of features around a project approval process. The contract approval process only partially fulfills the requested approval process. Additional functionality to support independent projects and a project application process is being explored separately. That being said, the existing credit class and project functionality can be used to accomplish the project approval process manually. -The existing credit class and project functionality can be used to accomplish the project approval process outlined in [Forward Contract Bond Module][1]. In the current implementation, a project can only be created within a credit class by an approved issuer of the credit class. An organization that intends to audit projects would need to administer a credit class and designate issuers to manage project audits. The application process would be handled off chain and the issuer would approve a project by creating a project on chain. +In the current implementation, a project can only be created within a credit class by an approved issuer of the credit class. An organization that intends to audit projects would need to administer a credit class and designate issuers to manage the audits. The application process would be handled off chain and the issuer would approve a project by creating a project on chain. -See [(x/ecocredit): independent projects proof-of-concept][4] for more information. +See [(x/ecocredit): independent projects proof-of-concept][4] for more information about the on-chain solution. ### Stage 2 -Investors would have the option of receiving tokens that would represent their claim on the contract and later be used to redeem credits from a claim account (i.e. an account managed by the submodule). Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to redeem credits at a later point in time. +Following the initial implementation, additional functionality could be added to support the liquidity of claims on future credits issued from a project enabling investors to receive tradable assets representing such claims. + +Investors would have the option of receiving tokens immediately instead of credits over time and the tokens would represent their claim on the contract and later be used to redeem credits from a claim account (i.e. an account managed programmatically by the submodule). Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to redeem credits at a later point in time. -When receiving tokens that represent a claim, the amount of tokens received would be calculated based on the percent of credits that the investor has a claim to and the tokens would be specific to the project and the most recent batch claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created (or updated) using a claim account as the recipient. Investor would then be free to transfer the tokens and the owner(s) of the tokens would then be able to claim the credits at a time of their choosing. +When receiving tokens that represent a claim, the amount of tokens received would be calculated based on the percent of future credits issued that the investor has a claim to and the tokens would be specific to the project and the most recent batch claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created (or updated) using the claim account as the recipient. -When credits are claimed, the owner of the tokens would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to redeem credits. The token denom for claim tokens would include the batch sequence number of the most recent batch claimed and redeeming credits would burn the tokens used to claim the credits and return new tokens with an updated denom. +When the owner of tokens claim credits from the claim account, the owner would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to redeem credits. The token denom for the claim tokens would include the batch sequence number of the most recent batch claimed and redeeming credits would burn the tokens received and return new tokens with an updated denom. This would enable token owners to claim credits at a time of their choosing. ## Rationale From 3f3c8a05abf62b00833c733902336347436ee709 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Wed, 11 Jan 2023 23:10:10 -0800 Subject: [PATCH 05/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index b46d6fb9be..eebede36b7 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -43,7 +43,9 @@ Forward contract functionality would enable project developers to offer a percen Forward contract functionality would be implemented as a `contract` submodule within the `ecocredit` module. For reference, [(x/ecocredit): forward contract proof-of-concept][2] was submitted as an initial proof-of-concept to help illustrate this architecture. -This proposal separates the approach into multiple stages. The initial stage (i.e. [Stage 1](#stage-1) is designed to serve the needs of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2) is designed to serve the remaining needs of the [Earthbanc Use Case](#earthbanc-use-case). The first version of this document focuses on Stage 1 and only introduces Stage 2. Stage 2 (and additional stages) will be further explored in subsequent versions. +This proposal separates the approach into multiple stages. The initial stage (i.e. [Stage 1](#stage-1) is designed to serve the requirements of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2) is designed to serve the remaining requirements of the [Earthbanc Use Case](#earthbanc-use-case). + +The first version of this document focuses on Stage 1 and only introduces Stage 2. Stage 2 (and additional stages) will be further explored in subsequent versions. ### Stage 1 @@ -53,11 +55,11 @@ There is only one option for receiving future credits issued, which is the direc Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s) and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project or working with a third party or other members of the credits class to do so. -The price and volume estimates for the credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the price and volume estimates are calculated are outside the scope of the on-chain functionality outlined within this proposal but additional information about how the calculations were made can and should be stored within the forward contract as metadata. +The price and volume estimates for the credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the credit price and volume estimates are calculated are outside the scope of the on-chain functionality outlined within this proposal but additional information about how the calculations were made can and should be stored within the forward contract as metadata. -To mitigate the risk of the investor and therefore improve the likelihood of investment, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be transferred. The reserve pool can only receive credits once the contract has been approved and the credits in the reserve pool will be held in escrow until the end of the contract. The reserve pool can only receive credits from the same credit class and the credits can only be transferred to the reserve pool by the credit class issuer. Whether the reserve pool backs the total volume of future credits being sold is up to the credit class issuer - more credits providing less risk for the investor(s) and more likelihood of the project receiving pre-financing. +To mitigate the risk of the investor and therefore improve the likelihood of investment, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be transferred. The reserve pool can only receive credits once the contract has been approved and the credits in the reserve pool will be held in escrow until the end of the contract. The reserve pool can only receive credits from the same credit class and the credits can only be transferred to the pool by the credit class issuer. Whether the reserve pool backs the total volume of future credits being sold is up to the credit class issuer with more credits providing less risk for the investor(s) and more likelihood of the project receiving pre-financing. -The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer. There are no restrictions on which token denomination the project chooses to receive funding but the token denomination cannot be updated and a stable coin would be the most probable choice. +The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer. There are no restrictions on which token denomination the project chooses to receive funding but the token denomination and amount cannot be updated once the contract has been approved, therefore a stable coin would be the most probable choice. ### Create Contract @@ -286,15 +288,6 @@ Direct credit issuance to the investor(s) will be enforced with on-chain functio See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. -### Project Approval Process - -In additional to forward contract functionality, the [Forward Contract Bond Module][1] document describes a set of features around a project approval process. The contract approval process only partially fulfills the requested approval process. Additional functionality to support independent projects and a project application process is being explored separately. That being said, the existing credit class and project functionality can be used to accomplish the project approval process manually. - -In the current implementation, a project can only be created within a credit class by an approved issuer of the credit class. An organization that intends to audit projects would need to administer a credit class and designate issuers to manage the audits. The application process would be handled off chain and the issuer would approve a project by creating a project on chain. - - -See [(x/ecocredit): independent projects proof-of-concept][4] for more information about the on-chain solution. - ### Stage 2 Following the initial implementation, additional functionality could be added to support the liquidity of claims on future credits issued from a project enabling investors to receive tradable assets representing such claims. From 2700e6e25a44c4b8e4edff50fc7c8e5f058146a2 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Wed, 11 Jan 2023 23:26:49 -0800 Subject: [PATCH 06/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index eebede36b7..6d7c48d2d8 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -292,11 +292,11 @@ See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. Following the initial implementation, additional functionality could be added to support the liquidity of claims on future credits issued from a project enabling investors to receive tradable assets representing such claims. -Investors would have the option of receiving tokens immediately instead of credits over time and the tokens would represent their claim on the contract and later be used to redeem credits from a claim account (i.e. an account managed programmatically by the submodule). Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to redeem credits at a later point in time. +Investors would have the option of receiving tokens immediately instead of receiving credits directly over time. The tokens would then be used to redeem credits from a claim account (i.e. an account managed programmatically by the `contract` submodule). Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to redeem credits at a time of their choosing. -When receiving tokens that represent a claim, the amount of tokens received would be calculated based on the percent of future credits issued that the investor has a claim to and the tokens would be specific to the project and the most recent batch claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created (or updated) using the claim account as the recipient. +The amount of tokens sent to the investor upon funding a project would be calculated based on the percent of the claim. The tokens would be specific to the project and the denomination would include information about the most recent credits redeemed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created using the claim account as the recipient and the credits would be held by the claim account until redeemed by the token owner. -When the owner of tokens claim credits from the claim account, the owner would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to redeem credits. The token denom for the claim tokens would include the batch sequence number of the most recent batch claimed and redeeming credits would burn the tokens received and return new tokens with an updated denom. This would enable token owners to claim credits at a time of their choosing. +When a token owner redeems credits from the claim account, the owner would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to redeem credits. The denomination of the tokens would include the batch sequence number of the most recent batch from which the credits were redeemed and redeeming credits would burn the tokens sent to the claim account and return tokens with an updated denomination. ## Rationale From bd1413eee2833714feb6a368cc2169df45c65046 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Thu, 12 Jan 2023 12:36:47 -0800 Subject: [PATCH 07/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 68 ++++++++++++++++++++++- 1 file changed, 65 insertions(+), 3 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index 6d7c48d2d8..aa31e4d880 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -180,15 +180,51 @@ message MsgApprove { Rule: The volume percentage cannot exceed the sum percentage of existing issuance policies ``` -### Fund Project +### Reserve Credits + +A credit class issuer can reserve credits in a reserve specifically for the forward contract to help mitigate the risk of investment by providing credits that will be distributed to the investor in the event the project under-delivers. + +```protobuf +// MsgReserve is the Msg/Reserve request type. +message MsgReserve { + option (cosmos.msg.v1.signer) = "issuer"; + + // contract_id is the unique identifier of the contract. + uint64 contract_id = 1; + + // issuer is the address of the issuer that approved the contract. Only the + // issuer in the contract can send credits to the contract reserve. + string issuer = 2; + + // batch_denom is the batch denom of the credits being sent. + string batch_denom = 3; + + // tradable_amount is the amount of tradable credits being sent. + string tradable_amount = 4; +} +``` + +```feature +Rule: Only the credit class issuer in the contract can send credits to the reserve +``` + +```feature +Rule: The reserve can only receive credits from the same credit class as the project +``` + +```feature +Rule: The reserve cannot receive more credits than the total volume of contracted credits +``` + +### Invest in Contract Any account can view available contracts and fund a project. When an account funds a project, the account has a claim to future credits issued from the project. The funds are transferred directly to the project admin. When an account funds a project and therefore owns a claim on future credits issued from the project, an issuance policy is automatically created and managed programmatically (i.e. no account has the authority to update the issuance policy and the issuance policy would only expire when the contract has ended). ```protobuf -// MsgFundProject is the Msg/FundProject request type. -message MsgFundProject { +// MsgInvest is the Msg/Invest request type. +message MsgInvest { // id is the unique identifier of the contract. uint64 id = 1; @@ -277,6 +313,32 @@ message Contract { } ``` +### Contract Reserve State + +```protobuf +message ContractReserve { + option (cosmos.orm.v1alpha1.table) = { + id : 2, + primary_key : {fields : "contract_id"} + }; + + // contract_id is the table row identifier of the contract. + uint64 contract_id = 1; + + // balances is the list of credit batch balances held in the reserve. + repeated Balances balances = 2; + + message Balances { + + // batch_denom is the amount of tradable credits in the reserve. + string batch_denom = 1; + + // tradable_amount is the amount of tradable credits in the reserve. + string tradable_amount = 2; + } +} +``` + ### Contract Expiration The contract will automatically expire once the contracted credit volume has been delivered or when the contract end date is reached. If the end date is reached before the contracted credit volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. From 91be1236f99fc4cbe69465533a83df934af34653 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Thu, 12 Jan 2023 12:43:50 -0800 Subject: [PATCH 08/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index aa31e4d880..07c2ee4ecc 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -316,6 +316,8 @@ message Contract { ### Contract Reserve State ```protobuf +// ContractReserve defines a forward contract reserve (aka "buffer pool") +// and the table within which forward contract reserves are stored. message ContractReserve { option (cosmos.orm.v1alpha1.table) = { id : 2, @@ -326,9 +328,10 @@ message ContractReserve { uint64 contract_id = 1; // balances is the list of credit batch balances held in the reserve. - repeated Balances balances = 2; + repeated Balance balances = 2; - message Balances { + // Balance defines a balance of credits held in the reserve. + message Balance { // batch_denom is the amount of tradable credits in the reserve. string batch_denom = 1; From 5a978ebc4ba4a771349741044d7126444a528de2 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Wed, 25 Jan 2023 22:28:55 -0800 Subject: [PATCH 09/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 32 +++++++++++++---------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index 07c2ee4ecc..cd59715732 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -1,6 +1,6 @@ # RFC-003: Forward Contract -- Created: 2023-01-12 +- Created: 2023-01-26 - Status: __DRAFT__ - Superseded By: NA - RFC PR: [#1474](https://github.com/regen-network/regen-ledger/pull/1474) @@ -25,12 +25,14 @@ This RFC aims to lay out a high-level architecture and feature set for forward c -Regen Ledger enables entities (individuals or organizations) to design and issue credits for ecosystem services in the form of on-chain assets. Ecosystem service credits represent positive ecological outcomes and are issued after those outcomes have been measured and quantified. Project developers receive payment for their services after buyers purchase their credits and projects are therefore responsible for covering upfront costs or seeking out financial support to start or continue providing ecosystem services. +Regen Ledger provides a framework that enables individuals or organizations to design and issue credits for ecosystem services in the form of on-chain assets. Ecosystem service credits represent positive ecological outcomes and are issued after those outcomes have been measured and quantified. Projects providing ecosystem services usually receive payment after individuals or organizations purchase credits leaving projects responsible for paying upfront costs or seeking out financial support to start, continue, or expand their operations. -Forward contract functionality would enable project developers to offer a percentage of future credits issued and receive funding before those credits have been measured and quantified. A Project developer would work alongside a credit class issuer to estimate the volume and price of the future credits and then submit a forward contract to be approved by the credit class issuer. Investors would then be able to claim a future percentage of credits issued from the project in exchange for upfront funding. +Forward contract functionality would enable projects to offer a percentage of future credits issued and receive funding before those credits have been measured and quantified. A Project would work alongside a credit class issuer to estimate the volume and price of credits and then submit a forward contract to be approved by the credit class issuer. Once the contract has been approved, individuals and organizations would then be able to provide upfront funding for projects in exchange for a percentage of future credits issued. ### Fast Forward Pilot +The "Fast Forward Pilot" described within this document is potentially one of many pilots that are being developed as a part of the Fast Forward working group. The pilot described here involves UNDO Carbon (the supplier), Spirals Protocol (the buyer), and Regen Network Development (the infrastructure provider). + ... ### Earthbanc Use Case @@ -41,25 +43,27 @@ Forward contract functionality would enable project developers to offer a percen -Forward contract functionality would be implemented as a `contract` submodule within the `ecocredit` module. For reference, [(x/ecocredit): forward contract proof-of-concept][2] was submitted as an initial proof-of-concept to help illustrate this architecture. +This proposal separates the approach into two stages. The initial stage (i.e. [Stage 1](#stage-1)) is designed to serve the requirements of [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2)) is designed to serve the remaining requirements of [Earthbanc Use Case](#earthbanc-use-case) and is left open-ended for further specification in a later version of this document or a subsequent proposal. + +### Stage 1 -This proposal separates the approach into multiple stages. The initial stage (i.e. [Stage 1](#stage-1) is designed to serve the requirements of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2) is designed to serve the remaining requirements of the [Earthbanc Use Case](#earthbanc-use-case). +The first stage includes the implementation of direct credit issuance and support for forward contracts that are specific to a single project whereby the project is vetted by a credit class issuer and the risk of the project under-delivering is either shared by the credit class (a risk in reserve credits and reputation) and the investor(s) (a risk in investment) or held solely by the credit class (the credit class provides reserve credits that fully back the future credits issued). -The first version of this document focuses on Stage 1 and only introduces Stage 2. Stage 2 (and additional stages) will be further explored in subsequent versions. +In the initial implementation, there would only be one option for receiving credits, which is the direct issuance of credits to the account that has a claim on future credits (i.e. the investor). In this case, the credits are delivered over time as they are issued; the investor receives a percentage of each credit issuance that has a monitoring period within the date criteria of the contract. The percentage of credits delivered with each credit issuance is based on the percentage of credits the investor purchased and enforced by on-chain functionality. -### Stage 1 +Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s), and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project or working with a third party or other members of the credits class to do so. -The first stage includes the implementation of direct credit issuance and support for forward contracts that are specific to a single project whereby the project is vetted by a credit class issuer and the risk of the project under-delivering is either shared by the credit class (a risk in reserve and reputation) and the investor(s) (a risk in investment) or held solely by the credit class (the credit class provides a reserve pool that fully backs the future credits issued). +The price and volume estimates for the credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the credit price and volume estimates are calculated are outside the scope of on-chain functionality but additional information about how the calculations were made can and should be stored within the forward contract as verifiable supporting data. -There is only one option for receiving future credits issued, which is the direct issuance of credits to the account that has a claim on the forward contract (i.e. the investor). In this case, the credits are delivered as they are issued from the project; the investor receives a percentage of each credit batch issuance that has a monitoring period that meets the date criteria of the contract. The percentage of credits delivered with each credit batch issuance is based on the percentage of the claim to future credits and enforced by on-chain functionality. +To mitigate the risk taken by the investor, and to therefore improve the likelihood of a project receiving funding, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be deposited. The reserve pool would only accept credits once the contract has been approved and the credits would be held in the reserve pool until the end of the contract or until the reserve pool has more credits what remains in the contract (in which case the difference could be withdrawn). -Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s) and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project or working with a third party or other members of the credits class to do so. +The reserve pool can only receive credits from the same credit class and the credits can only be transferred to the reserve pool by the credit class issuer. Whether the reserve pool backs the total volume of future credits being sold is up to the credit class issuer; the more credits held in the reserve pool providing less risk for the investor(s) and more likelihood of the project receiving pre-financing. -The price and volume estimates for the credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the credit price and volume estimates are calculated are outside the scope of the on-chain functionality outlined within this proposal but additional information about how the calculations were made can and should be stored within the forward contract as metadata. +The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer. There would be no restrictions on what token denomination the project chooses but the token denomination and amount would not be updatable once the contract has been approved, therefore a stable coin would be the most probable choice. -To mitigate the risk of the investor and therefore improve the likelihood of investment, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be transferred. The reserve pool can only receive credits once the contract has been approved and the credits in the reserve pool will be held in escrow until the end of the contract. The reserve pool can only receive credits from the same credit class and the credits can only be transferred to the pool by the credit class issuer. Whether the reserve pool backs the total volume of future credits being sold is up to the credit class issuer with more credits providing less risk for the investor(s) and more likelihood of the project receiving pre-financing. +### Contract Submodule -The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer. There are no restrictions on which token denomination the project chooses to receive funding but the token denomination and amount cannot be updated once the contract has been approved, therefore a stable coin would be the most probable choice. +Forward contract functionality would be implemented as a `contract` submodule within the existing `ecocredit` module. For reference, [(x/ecocredit): forward contract proof-of-concept][2] was submitted as an initial proof-of-concept to help illustrate this architecture. ### Create Contract @@ -295,7 +299,7 @@ message Contract { // information about the contract including the initial amount of funds to // collect, the initial volume percentage offered, estimated total supply, // forward contract supply, and estimated price per credit type unit. - google.protobuf.Timestamp metadata = 4; + string metadata = 4; // volume_percentage is the remaining percent of all credits issued that // are be available to claim. From 0c674c0e4193c3661771ccd932102474877c29aa Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Wed, 25 Jan 2023 23:01:35 -0800 Subject: [PATCH 10/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 32 ++++++++++++++--------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index cd59715732..1e25fb9cf1 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -43,23 +43,23 @@ The "Fast Forward Pilot" described within this document is potentially one of ma -This proposal separates the approach into two stages. The initial stage (i.e. [Stage 1](#stage-1)) is designed to serve the requirements of [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2)) is designed to serve the remaining requirements of [Earthbanc Use Case](#earthbanc-use-case) and is left open-ended for further specification in a later version of this document or a subsequent proposal. +This proposal separates the approach into two stages. The initial stage (i.e. [Stage 1](#stage-1)) is designed to serve the requirements of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2)) is designed to serve the remaining requirements of the [Earthbanc Use Case](#earthbanc-use-case) and is left open-ended for further specification in subsequent version or separate proposal. ### Stage 1 The first stage includes the implementation of direct credit issuance and support for forward contracts that are specific to a single project whereby the project is vetted by a credit class issuer and the risk of the project under-delivering is either shared by the credit class (a risk in reserve credits and reputation) and the investor(s) (a risk in investment) or held solely by the credit class (the credit class provides reserve credits that fully back the future credits issued). -In the initial implementation, there would only be one option for receiving credits, which is the direct issuance of credits to the account that has a claim on future credits (i.e. the investor). In this case, the credits are delivered over time as they are issued; the investor receives a percentage of each credit issuance that has a monitoring period within the date criteria of the contract. The percentage of credits delivered with each credit issuance is based on the percentage of credits the investor purchased and enforced by on-chain functionality. +In the initial implementation, there would only be one option for receiving credits, which is the direct issuance of credits to the account that purchases credits via the forward contract (i.e. the investor). The credits are delivered over time as they are issued; the investor receives a percentage of each credit issuance from the project where the monitoring period meets the date criteria of the contract. The percentage of credits delivered with each credit issuance is based on the percentage the investor purchased and enforced by on-chain functionality. -Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s), and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project or working with a third party or other members of the credits class to do so. +Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s), and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project and/or work with a third party or other issuers of the credits class to do so. -The price and volume estimates for the credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the credit price and volume estimates are calculated are outside the scope of on-chain functionality but additional information about how the calculations were made can and should be stored within the forward contract as verifiable supporting data. +The price and volume estimates for future credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the credit price and volume estimates are calculated are outside the scope of on-chain functionality but additional information about how the calculations were made should be stored on chain within the forward contract as verifiable supporting data. -To mitigate the risk taken by the investor, and to therefore improve the likelihood of a project receiving funding, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be deposited. The reserve pool would only accept credits once the contract has been approved and the credits would be held in the reserve pool until the end of the contract or until the reserve pool has more credits what remains in the contract (in which case the difference could be withdrawn). +To mitigate the risk of investment, and to therefore improve the likelihood of a project receiving funding, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be deposited. The reserve pool would only accept credits once the contract has been approved and the credits would be held in the reserve pool until the end of the contract or until the reserve pool has more credits than what remains in the contract (in which case the difference could be withdrawn). -The reserve pool can only receive credits from the same credit class and the credits can only be transferred to the reserve pool by the credit class issuer. Whether the reserve pool backs the total volume of future credits being sold is up to the credit class issuer; the more credits held in the reserve pool providing less risk for the investor(s) and more likelihood of the project receiving pre-financing. +The reserve pool would only accept credits from the same credit class and from the credit class issuer that approved the contract. Whether the reserve pool backs a partial amount or the total amount of credits being sold is up to the credit class issuer; the more credits held in the reserve pool providing less risk for the investor(s) and more likelihood of the project receiving funds. -The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer. There would be no restrictions on what token denomination the project chooses but the token denomination and amount would not be updatable once the contract has been approved, therefore a stable coin would be the most probable choice. +The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer. There would be no restrictions on what token denomination the project chooses but the token denomination and amount would be unalterable after the contract has been approved, therefore a stable coin would be the most probable choice. ### Contract Submodule @@ -165,7 +165,7 @@ Rule: Only a project admin can cancel the contract ### Approve Contract -A credit class issuer can approve a contract. Once the contract is "approved", the contract cannot be updated and any account can fund the project. +A credit class issuer can approve a contract. Once the contract is "approved", the contract cannot be updated. ```protobuf // MsgApprove is the Msg/Approve request type. @@ -186,7 +186,7 @@ Rule: The volume percentage cannot exceed the sum percentage of existing issuanc ### Reserve Credits -A credit class issuer can reserve credits in a reserve specifically for the forward contract to help mitigate the risk of investment by providing credits that will be distributed to the investor in the event the project under-delivers. +The credit class issuer can reserve credits in a reserve pool specifically for the forward contract to help mitigate the risk of investment by providing credits that will be distributed to the investor if the project under-delivers. ```protobuf // MsgReserve is the Msg/Reserve request type. @@ -314,6 +314,12 @@ message Contract { // end_date is the contract end date. google.protobuf.Timestamp end_date = 8; + + // buffer_window is the duration after the end date in which credits may + // still be issued with a monitoring period that falls within the start + // and end data of the contract. The credits held in the reserve pool are + // not distributed or returned until end data + buffer window. + google.protobuf.Duration buffer_window = 9; } ``` @@ -337,10 +343,10 @@ message ContractReserve { // Balance defines a balance of credits held in the reserve. message Balance { - // batch_denom is the amount of tradable credits in the reserve. + // batch_denom is the denom of the credits in the reserve. string batch_denom = 1; - // tradable_amount is the amount of tradable credits in the reserve. + // tradable_amount is the amount of the credits in the reserve. string tradable_amount = 2; } } @@ -348,11 +354,11 @@ message ContractReserve { ### Contract Expiration -The contract will automatically expire once the contracted credit volume has been delivered or when the contract end date is reached. If the end date is reached before the contracted credit volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. +The contract will automatically expire once the contracted credit volume has been delivered or when the contract end date (with an optional buffer window) has been reached. If the end date (plus the optional buffer window) is reached before the contracted credit volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. ### Automated Credit Issuance -Direct credit issuance to the investor(s) will be enforced with on-chain functionality. At the time of funding the project, an investor has the option of choosing to receive credits in a retired or tradable state upon issuance. This functionality will be handled by "issuance policies" and explored as a separate feature set built alongside the initial implementation stage of forward contract functionality. +Direct credit issuance to the investor(s) will be enforced with on-chain functionality. At the time of funding the project, an investor has the option of choosing to receive credits in a retired or tradable state upon issuance. This functionality will be handled by "issuance policies" and explored as a separate feature set built alongside the initial implementation of forward contract functionality. See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. From e73b30c448bc49755ff20d0a030078da5489ceb1 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Thu, 26 Jan 2023 09:11:44 -0800 Subject: [PATCH 11/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 45 ++++++++++++++++++++++- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index 1e25fb9cf1..d375c9a50a 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -33,10 +33,51 @@ Forward contract functionality would enable projects to offer a percentage of fu The "Fast Forward Pilot" described within this document is potentially one of many pilots that are being developed as a part of the Fast Forward working group. The pilot described here involves UNDO Carbon (the supplier), Spirals Protocol (the buyer), and Regen Network Development (the infrastructure provider). +The following expectations were discussed and the "✓" indicates what we aligned on for an initial implementation: + +**Initial payment** + +1. Buyer pays full upfront cost for future credits ✓ +2. Buyer pays partial upfront cost for future credits +3. Buyer payment is held in escrow for future credits +4. Buyer pays no upfront cost for future credits + +**Payment amount** + +1. Discount from current market price based on years out +2. Discount from current market price based on risk +3. Discount from current market price based on combination ✓ + +**Representation** + +1. Buyer receives no asset and contract is baked into the protocol ✓ +2. Buyer receives a liquid asset representing the percent of future credits + 1. The asset is tradable + 2. The asset is not tradable +3. Buyer receives vouchers for credits that will mature (i.e. ex-ante) + +**Credit delivery (time)** + +1. Buyer receives credits as they are issued (percent of each issuance) ✓ +2. Buyer receives credits at the end of the contract (total percent/credits) +3. Buyer receives vouchers at the time of purchase (i.e. ex-ante) + +**Credit delivery (quantity)** + +1. Buyer receives percentage in the contract (no insurance) + 1. If more/less credits are issued, buyer receives more/less + 2. Once expected credit amount issued, buyer receives no more ✓ +2. Buyer receives percentage in the contract (with insurance) + 1. Previously issued credits are held in a reserve pool ✓ + 2. Future credits issued if credits not delivered within time-frame +3. Buyer receives exact credits that mature (i.e. ex-ante) + ... ### Earthbanc Use Case +See [Forward Contract Bond Module][1]. + ... ## Approach @@ -317,8 +358,8 @@ message Contract { // buffer_window is the duration after the end date in which credits may // still be issued with a monitoring period that falls within the start - // and end data of the contract. The credits held in the reserve pool are - // not distributed or returned until end data + buffer window. + // and end date of the contract. The credits held in the reserve pool are + // not distributed or returned until end date + buffer window. google.protobuf.Duration buffer_window = 9; } ``` From 104efc718cf7dfe55e9115980ec74fc4585a3904 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Fri, 27 Jan 2023 09:18:59 -0800 Subject: [PATCH 12/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index d375c9a50a..c6c763b490 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -84,7 +84,7 @@ See [Forward Contract Bond Module][1]. -This proposal separates the approach into two stages. The initial stage (i.e. [Stage 1](#stage-1)) is designed to serve the requirements of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2)) is designed to serve the remaining requirements of the [Earthbanc Use Case](#earthbanc-use-case) and is left open-ended for further specification in subsequent version or separate proposal. +This proposal separates the approach into two stages. The initial stage (i.e. [Stage 1](#stage-1)) is designed to serve the requirements of the [Fast Forward Pilot](#fast-forward-pilot) and lay the foundation for the [Earthbanc Use Case](#earthbanc-use-case). The second stage (i.e. [Stage 2](#stage-2)) is designed to serve the remaining requirements of the [Earthbanc Use Case](#earthbanc-use-case) and is left open-ended for further specification in a subsequent version or separate proposal. ### Stage 1 @@ -92,15 +92,15 @@ The first stage includes the implementation of direct credit issuance and suppor In the initial implementation, there would only be one option for receiving credits, which is the direct issuance of credits to the account that purchases credits via the forward contract (i.e. the investor). The credits are delivered over time as they are issued; the investor receives a percentage of each credit issuance from the project where the monitoring period meets the date criteria of the contract. The percentage of credits delivered with each credit issuance is based on the percentage the investor purchased and enforced by on-chain functionality. -Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s), and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project and/or work with a third party or other issuers of the credits class to do so. +Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s), and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project and/or work with a third party or other credit class issuers to do so. -The price and volume estimates for future credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the credit price and volume estimates are calculated are outside the scope of on-chain functionality but additional information about how the calculations were made should be stored on chain within the forward contract as verifiable supporting data. +The price and volume estimates for future credits issued from the project within the timeframe of the contract will be set by the project admin and approved by the credit class issuer through an on-chain contract creation and review process. How the credit price and volume estimates are calculated are outside the scope of on-chain functionality but additional information about how the calculations were made can and should be stored on chain within the forward contract as verifiable supporting data. To mitigate the risk of investment, and to therefore improve the likelihood of a project receiving funding, each contract will have a reserve pool specifically for the contract where previously issued credits from the project or an equivalent project can be deposited. The reserve pool would only accept credits once the contract has been approved and the credits would be held in the reserve pool until the end of the contract or until the reserve pool has more credits than what remains in the contract (in which case the difference could be withdrawn). The reserve pool would only accept credits from the same credit class and from the credit class issuer that approved the contract. Whether the reserve pool backs a partial amount or the total amount of credits being sold is up to the credit class issuer; the more credits held in the reserve pool providing less risk for the investor(s) and more likelihood of the project receiving funds. -The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer. There would be no restrictions on what token denomination the project chooses but the token denomination and amount would be unalterable after the contract has been approved, therefore a stable coin would be the most probable choice. +The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer during the contract creation and review process. There would be no restrictions on what token denomination the project chooses but the token denomination and amount would be unalterable after the contract has been approved, therefore a stable coin would be the most probable choice. ### Contract Submodule @@ -138,6 +138,12 @@ message MsgCreate { // end_date is the contract end date. google.protobuf.Timestamp end_date = 7; + + // buffer_window is the duration after the end date in which credits may + // still be issued with a monitoring period that falls within the start + // and end date of the contract. The credits held in the reserve pool are + // not distributed or returned until end date + buffer window. + google.protobuf.Duration buffer_window = 8; } ``` From abf394305082f14d49653431191ef842574df214 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Fri, 27 Jan 2023 10:41:18 -0800 Subject: [PATCH 13/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 136 +++++++++++++--------- 1 file changed, 80 insertions(+), 56 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index c6c763b490..856034badf 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -100,7 +100,7 @@ To mitigate the risk of investment, and to therefore improve the likelihood of a The reserve pool would only accept credits from the same credit class and from the credit class issuer that approved the contract. Whether the reserve pool backs a partial amount or the total amount of credits being sold is up to the credit class issuer; the more credits held in the reserve pool providing less risk for the investor(s) and more likelihood of the project receiving funds. -The accepted form of funds (i.e. the accepted token denomination) is decided by the project admin and approved by the credit class issuer during the contract creation and review process. There would be no restrictions on what token denomination the project chooses but the token denomination and amount would be unalterable after the contract has been approved, therefore a stable coin would be the most probable choice. +The accepted form of funds (i.e. token denomination) is decided by the project admin and approved by the credit class issuer during the contract creation and review process. There would be no restrictions on what token denomination the project chooses but the token denomination and amount would be unalterable after the contract has been approved, therefore a stable coin would be the most probable choice. ### Contract Submodule @@ -121,29 +121,35 @@ message MsgCreate { string project_admin = 2; // metadata is any arbitrary string that includes or references additional - // information about the contract including the initial amount of funds to - // collect, the initial volume percentage offered, estimated total supply, - // forward contract supply, and estimated price per credit type unit. + // information about the contract such as calculations made to determine + // the volume of credits and the price per credit. string metadata = 3; - // funds_to_collect is the denom and amount the project is collecting. - cosmos.base.v1beta1.Coin funds_to_collect = 4; + // ask_price is the token denomination and amount the project is asking + // for per credit. + cosmos.base.v1beta1.Coin ask_price = 4; - // volume_percentage is the percent of future credits issued that will be - // available to purchase. - string volume_percentage = 5; + // amount is the amount of future credits issued that will be available to + // purchase. The amount is a decimal value with a precision determined by + // the credit type of the credit class. + string amount = 5; + + // volume_percentage is the percentage of future credits issued that will be + // available to purchase. The percentage is used to determine the amount of + // credits issued to investors with each credit issuance. + string volume_percentage = 6; // start_date is the contract start date. - google.protobuf.Timestamp start_date = 6; + google.protobuf.Timestamp start_date = 7; // end_date is the contract end date. - google.protobuf.Timestamp end_date = 7; + google.protobuf.Timestamp end_date = 8; // buffer_window is the duration after the end date in which credits may // still be issued with a monitoring period that falls within the start // and end date of the contract. The credits held in the reserve pool are // not distributed or returned until end date + buffer window. - google.protobuf.Duration buffer_window = 8; + google.protobuf.Duration buffer_window = 9; } ``` @@ -166,23 +172,35 @@ message MsgUpdate { string project_admin = 2; // metadata is any arbitrary string that includes or references additional - // information about the contract including the initial amount of funds to - // collect, the initial volume percentage offered, estimated total supply, - // forward contract supply, and estimated price per credit type unit. + // information about the contract such as calculations made to determine + // the volume of credits and the price per credit. string metadata = 3; - // funds_to_collect is the denom and amount the project is collecting. - cosmos.base.v1beta1.Coin funds_to_collect = 4; + // ask_price is the token denomination and amount the project is asking + // for per credit. + cosmos.base.v1beta1.Coin ask_price = 4; + + // amount is the amount of future credits issued that will be available to + // purchase. The amount is a decimal value with a precision determined by + // the credit type of the credit class. + string amount = 5; - // volume_percentage is the percent of future credits issued that will be - // available to purchase. - string volume_percentage = 5; + // volume_percentage is the percentage of future credits issued that will be + // available to purchase. The percentage is used to determine the amount of + // credits to be issued to investors with each credit issuance. + string volume_percentage = 6; // start_date is the contract start date. - google.protobuf.Timestamp start_date = 6; + google.protobuf.Timestamp start_date = 7; // end_date is the contract end date. - google.protobuf.Timestamp end_date = 7; + google.protobuf.Timestamp end_date = 8; + + // buffer_window is the duration after the end date in which credits may + // still be issued with a monitoring period that falls within the start + // and end date of the contract. The credits held in the reserve pool are + // not distributed or returned until end date + buffer window. + google.protobuf.Duration buffer_window = 9; } ``` @@ -233,7 +251,7 @@ Rule: The volume percentage cannot exceed the sum percentage of existing issuanc ### Reserve Credits -The credit class issuer can reserve credits in a reserve pool specifically for the forward contract to help mitigate the risk of investment by providing credits that will be distributed to the investor if the project under-delivers. +The credit class issuer can reserve credits in a reserve pool that backs the forward contract to help mitigate the risk of investment by providing credits that will be distributed to the investor if the project under-delivers. ```protobuf // MsgReserve is the Msg/Reserve request type. @@ -267,11 +285,9 @@ Rule: The reserve can only receive credits from the same credit class as the pro Rule: The reserve cannot receive more credits than the total volume of contracted credits ``` -### Invest in Contract +### Invest in Project -Any account can view available contracts and fund a project. When an account funds a project, the account has a claim to future credits issued from the project. The funds are transferred directly to the project admin. - -When an account funds a project and therefore owns a claim on future credits issued from the project, an issuance policy is automatically created and managed programmatically (i.e. no account has the authority to update the issuance policy and the issuance policy would only expire when the contract has ended). +Any account can view available contracts and fund a project. When an account funds a project, funds are transferred directly to the project admin and an issuance policy is created and managed programmatically with the investor as the recipient. ```protobuf // MsgInvest is the Msg/Invest request type. @@ -280,25 +296,27 @@ message MsgInvest { // id is the unique identifier of the contract. uint64 id = 1; - // funder is the address of the account funding the project and receiving a - // share of future credits issued from the project. - string funder = 2; - - // volume_percentage is the percent of all credits issued that the funder will - // receive. - string volume_percentage = 3; + // investor is the address of the account funding the project and receiving a + // percentage of future credits issued from the project. + string investor = 2; - // funds is the token denom and amount the funder is providing in return for - // the specified volume percentage. The required amount is determined based on - // the volume percentage provided and only the required amount is sent. - cosmos.base.v1beta1.Coin funds = 4; + // bid_price is the price per credit the investor is paying in return for + // the specified amount of future credits issued. The bid price must be + // greater than or equal to the ask price defined within the contract and + // only the ask price will be charged at the time of investment. + cosmos.base.v1beta1.Coin bid_price = 3; + // amount is the total amount of future credits issued that the investor is + // purchasing and will receive over time with each credit issuance based on + // the volume percentage defined within the contract. + string amount = 4; + // auto_retire determines whether the credits will be automatically retied upon // issuance (i.e. the issuance policy will be set to auto-retire). bool auto_retire = 5; - // retirement_jurisdiction is the jurisdiction of the funder. A jurisdiction is - // only required if auto-retire is enabled. + // retirement_jurisdiction is the jurisdiction of the investor. A jurisdiction + // is only required if auto-retire is enabled. string retirement_jurisdiction = 6; } ``` @@ -316,7 +334,7 @@ Rule: The funds amount must be greater than or equal to the calculated cost ``` ```feature -Rule: The funds are deducted from the token balance of the funder +Rule: The funds are deducted from the token balance of the investor ``` ```feature @@ -343,30 +361,36 @@ message Contract { ContractStatus status = 3; // metadata is any arbitrary string that includes or references additional - // information about the contract including the initial amount of funds to - // collect, the initial volume percentage offered, estimated total supply, - // forward contract supply, and estimated price per credit type unit. + // information about the contract such as calculations made to determine + // the volume of credits and the price per credit. string metadata = 4; - // volume_percentage is the remaining percent of all credits issued that - // are be available to claim. - string volume_percentage = 5; + // ask_price is the token denomination and amount the project is asking + // for per credit. + cosmos.base.v1beta1.Coin ask_price = 5; + + // amount is the amount of future credits issued that are available to + // purchase. The amount will decrease with each investment, therefore + // representing the remaining amount of credits available. + string amount = 6; - // funds_to_collect is the denom and remaining amount of funds the project - // is collecting. - cosmos.base.v1beta1.Coin funds_to_collect = 6; + // volume_percentage is the percentage of future credits issued that was + // made available to purchase. The volume percentage is used to determine + // the percentage of future credits issued in each credit issuance based + // on the amount of credits purchased by an investor. + string volume_percentage = 7; // start_date is the contract start date. - google.protobuf.Timestamp start_date = 7; + google.protobuf.Timestamp start_date = 8; // end_date is the contract end date. - google.protobuf.Timestamp end_date = 8; + google.protobuf.Timestamp end_date = 9; // buffer_window is the duration after the end date in which credits may // still be issued with a monitoring period that falls within the start // and end date of the contract. The credits held in the reserve pool are // not distributed or returned until end date + buffer window. - google.protobuf.Duration buffer_window = 9; + google.protobuf.Duration buffer_window = 10; } ``` @@ -414,11 +438,11 @@ See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. Following the initial implementation, additional functionality could be added to support the liquidity of claims on future credits issued from a project enabling investors to receive tradable assets representing such claims. -Investors would have the option of receiving tokens immediately instead of receiving credits directly over time. The tokens would then be used to redeem credits from a claim account (i.e. an account managed programmatically by the `contract` submodule). Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to redeem credits at a time of their choosing. +Investors would have the option of receiving tokens immediately instead of receiving credits directly over time. The tokens would then be used to claim credits from a claim account (i.e. an account managed programmatically by the `contract` submodule). Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to claim credits at a time of their choosing. -The amount of tokens sent to the investor upon funding a project would be calculated based on the percent of the claim. The tokens would be specific to the project and the denomination would include information about the most recent credits redeemed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created using the claim account as the recipient and the credits would be held by the claim account until redeemed by the token owner. +The amount of tokens sent to the investor upon funding a project would be calculated based on the percent of the claim. The tokens would be specific to the project and the denomination would include information about the most recent credits claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created using the claim account as the recipient and the credits would be held by the claim account until claimed by the token owner. -When a token owner redeems credits from the claim account, the owner would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to redeem credits. The denomination of the tokens would include the batch sequence number of the most recent batch from which the credits were redeemed and redeeming credits would burn the tokens sent to the claim account and return tokens with an updated denomination. +When a token owner claims credits from the claim account, the owner would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to claim credits. The denomination of the tokens would include the batch sequence number of the most recent batch from which the credits were claimed and claiming credits would burn the tokens sent to the claim account and return tokens with an updated denomination. ## Rationale From b9299727f449b6226c9ab5023036f97d4af93c2d Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Fri, 27 Jan 2023 10:47:32 -0800 Subject: [PATCH 14/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index 856034badf..caaa3aa0ee 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -100,7 +100,7 @@ To mitigate the risk of investment, and to therefore improve the likelihood of a The reserve pool would only accept credits from the same credit class and from the credit class issuer that approved the contract. Whether the reserve pool backs a partial amount or the total amount of credits being sold is up to the credit class issuer; the more credits held in the reserve pool providing less risk for the investor(s) and more likelihood of the project receiving funds. -The accepted form of funds (i.e. token denomination) is decided by the project admin and approved by the credit class issuer during the contract creation and review process. There would be no restrictions on what token denomination the project chooses but the token denomination and amount would be unalterable after the contract has been approved, therefore a stable coin would be the most probable choice. +The accepted form of funds (i.e. token denomination) is decided by the project admin and approved by the credit class issuer during the contract creation and review process. There would be no restrictions on what the project chooses but the token denomination and amount would be unalterable after the contract has been approved, therefore a stable coin would be the most probable choice. ### Contract Submodule @@ -423,11 +423,11 @@ message ContractReserve { } ``` -### Contract Expiration +### Contract Termination -The contract will automatically expire once the contracted credit volume has been delivered or when the contract end date (with an optional buffer window) has been reached. If the end date (plus the optional buffer window) is reached before the contracted credit volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. +The contract will end once the contracted credit volume has been delivered or when the contract end date (with an optional buffer window) has been reached. If the end date (plus the optional buffer window) is reached before the contracted credit volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. -### Automated Credit Issuance +### Credit Issuance Direct credit issuance to the investor(s) will be enforced with on-chain functionality. At the time of funding the project, an investor has the option of choosing to receive credits in a retired or tradable state upon issuance. This functionality will be handled by "issuance policies" and explored as a separate feature set built alongside the initial implementation of forward contract functionality. From 2b5e4d64840de89beb932c3bf7880cb28da8905e Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Fri, 27 Jan 2023 11:13:03 -0800 Subject: [PATCH 15/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index caaa3aa0ee..cb095e0582 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -27,7 +27,7 @@ This RFC aims to lay out a high-level architecture and feature set for forward c Regen Ledger provides a framework that enables individuals or organizations to design and issue credits for ecosystem services in the form of on-chain assets. Ecosystem service credits represent positive ecological outcomes and are issued after those outcomes have been measured and quantified. Projects providing ecosystem services usually receive payment after individuals or organizations purchase credits leaving projects responsible for paying upfront costs or seeking out financial support to start, continue, or expand their operations. -Forward contract functionality would enable projects to offer a percentage of future credits issued and receive funding before those credits have been measured and quantified. A Project would work alongside a credit class issuer to estimate the volume and price of credits and then submit a forward contract to be approved by the credit class issuer. Once the contract has been approved, individuals and organizations would then be able to provide upfront funding for projects in exchange for a percentage of future credits issued. +Forward contract functionality would enable projects to offer future credits issued and receive funding before those credits have been measured and quantified. A Project would work alongside a credit class issuer to estimate the volume and price of credits and then submit a forward contract to be approved by the credit class issuer. Once the contract has been approved, individuals and organizations would then be able to provide upfront funding for projects in exchange for future credits issued. ### Fast Forward Pilot @@ -90,7 +90,7 @@ This proposal separates the approach into two stages. The initial stage (i.e. [S The first stage includes the implementation of direct credit issuance and support for forward contracts that are specific to a single project whereby the project is vetted by a credit class issuer and the risk of the project under-delivering is either shared by the credit class (a risk in reserve credits and reputation) and the investor(s) (a risk in investment) or held solely by the credit class (the credit class provides reserve credits that fully back the future credits issued). -In the initial implementation, there would only be one option for receiving credits, which is the direct issuance of credits to the account that purchases credits via the forward contract (i.e. the investor). The credits are delivered over time as they are issued; the investor receives a percentage of each credit issuance from the project where the monitoring period meets the date criteria of the contract. The percentage of credits delivered with each credit issuance is based on the percentage the investor purchased and enforced by on-chain functionality. +In the initial implementation, there would only be one option for receiving credits, which is the direct issuance of credits to the account that purchases credits via the forward contract (i.e. the investor). The credits are delivered over time as they are issued; the investor receives a percentage of each credit issuance from the project where the monitoring period meets the date criteria of the contract. The percentage of credits delivered with each credit issuance is based on the amount the investor purchased and enforced by on-chain functionality. Each forward contract is specific to a single project. The project should be properly vetted by the credit class issuer(s), and the investor(s) will need to trust the credit class and/or vet the project themselves. The admin and issuer(s) of a credit class are responsible for defining their own vetting process for projects and the issuer that approves the contract will be responsible for following that process and assessing the risk of the project and/or work with a third party or other credit class issuers to do so. @@ -311,8 +311,8 @@ message MsgInvest { // the volume percentage defined within the contract. string amount = 4; - // auto_retire determines whether the credits will be automatically retied upon - // issuance (i.e. the issuance policy will be set to auto-retire). + // auto_retire determines whether the credits will be automatically retied + // upon issuance (i.e. the issuance policy will be set to auto-retire). bool auto_retire = 5; // retirement_jurisdiction is the jurisdiction of the investor. A jurisdiction @@ -346,7 +346,7 @@ Rule: The funds are added to the token balance of the project admin ```protobuf // Contract defines a forward contract and the forward contract table. message Contract { - option (cosmos.orm.v1alpha1.table) = { + option (cosmos.orm.v1.table) = { id : 1, primary_key : {fields : "id", auto_increment : true} }; @@ -400,7 +400,7 @@ message Contract { // ContractReserve defines a forward contract reserve (aka "buffer pool") // and the table within which forward contract reserves are stored. message ContractReserve { - option (cosmos.orm.v1alpha1.table) = { + option (cosmos.orm.v1.table) = { id : 2, primary_key : {fields : "contract_id"} }; @@ -436,11 +436,11 @@ See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. ### Stage 2 -Following the initial implementation, additional functionality could be added to support the liquidity of claims on future credits issued from a project enabling investors to receive tradable assets representing such claims. +Following the initial implementation, additional functionality could be added to support the liquidity of claims on future credits issued from a project enabling investors to receive tradable assets representing their investment. -Investors would have the option of receiving tokens immediately instead of receiving credits directly over time. The tokens would then be used to claim credits from a claim account (i.e. an account managed programmatically by the `contract` submodule). Receiving tokens would enable investors to transfer their claim and the owner(s) of those tokens would then be able to claim credits at a time of their choosing. +Investors would have the option of receiving tokens immediately instead of receiving credits directly over time. The tokens would then be used to claim credits from a claim account (i.e. an account managed programmatically by the `contract` submodule). Receiving tokens would enable investors to transfer their investment and the owner(s) of those tokens would then be able to claim credits at a time of their choosing. -The amount of tokens sent to the investor upon funding a project would be calculated based on the percent of the claim. The tokens would be specific to the project and the denomination would include information about the most recent credits claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created using the claim account as the recipient and the credits would be held by the claim account until claimed by the token owner. +The amount of tokens sent to the investor upon funding a project would be calculated based on the investment. The tokens would be specific to the project and the denomination would include information about the most recent credits claimed. Rather than an issuance policy being created using the investor account as the recipient, an issuance policy would be created using the claim account as the recipient and the credits would be held by the claim account until claimed by the token owner. When a token owner claims credits from the claim account, the owner would exchange the tokens for the credits issued from the project and receive new tokens equal to the amount of tokens used to claim credits. The denomination of the tokens would include the batch sequence number of the most recent batch from which the credits were claimed and claiming credits would burn the tokens sent to the claim account and return tokens with an updated denomination. From dcb3144a765252ed1509e186773cddd23c81c186 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Fri, 27 Jan 2023 11:19:40 -0800 Subject: [PATCH 16/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index cb095e0582..a5d4c77739 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -423,7 +423,7 @@ message ContractReserve { } ``` -### Contract Termination +### Contract End The contract will end once the contracted credit volume has been delivered or when the contract end date (with an optional buffer window) has been reached. If the end date (plus the optional buffer window) is reached before the contracted credit volume has been delivered, credits from the reserve pool will be delivered in place of the contracted credits up to the amount available in the reserve pool. @@ -436,7 +436,7 @@ See [(x/ecocredit): issuance policy proof-of-concept][3] for more information. ### Stage 2 -Following the initial implementation, additional functionality could be added to support the liquidity of claims on future credits issued from a project enabling investors to receive tradable assets representing their investment. +Following the initial implementation, additional functionality could be added to support the liquidity of future credits enabling investors to receive tradable assets representing their investment. Investors would have the option of receiving tokens immediately instead of receiving credits directly over time. The tokens would then be used to claim credits from a claim account (i.e. an account managed programmatically by the `contract` submodule). Receiving tokens would enable investors to transfer their investment and the owner(s) of those tokens would then be able to claim credits at a time of their choosing. From c8b19b3a3eef3b992cbc38fe08b8eaa9b9da9cc7 Mon Sep 17 00:00:00 2001 From: ryanchristo <12519942+ryanchristo@users.noreply.github.com> Date: Fri, 27 Jan 2023 11:34:38 -0800 Subject: [PATCH 17/17] docs: add RFC for forward contract functionality --- specs/rfcs/003-forward-contract/README.md | 30 +++++++++-------------- 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/specs/rfcs/003-forward-contract/README.md b/specs/rfcs/003-forward-contract/README.md index a5d4c77739..a8bbe8d4d8 100644 --- a/specs/rfcs/003-forward-contract/README.md +++ b/specs/rfcs/003-forward-contract/README.md @@ -125,9 +125,9 @@ message MsgCreate { // the volume of credits and the price per credit. string metadata = 3; - // ask_price is the token denomination and amount the project is asking - // for per credit. - cosmos.base.v1beta1.Coin ask_price = 4; + // price is the token denomination and amount the project is asking for + // per credit. + cosmos.base.v1beta1.Coin price = 4; // amount is the amount of future credits issued that will be available to // purchase. The amount is a decimal value with a precision determined by @@ -176,9 +176,9 @@ message MsgUpdate { // the volume of credits and the price per credit. string metadata = 3; - // ask_price is the token denomination and amount the project is asking - // for per credit. - cosmos.base.v1beta1.Coin ask_price = 4; + // price is the token denomination and amount the project is asking for + // per credit. + cosmos.base.v1beta1.Coin price = 4; // amount is the amount of future credits issued that will be available to // purchase. The amount is a decimal value with a precision determined by @@ -300,24 +300,18 @@ message MsgInvest { // percentage of future credits issued from the project. string investor = 2; - // bid_price is the price per credit the investor is paying in return for - // the specified amount of future credits issued. The bid price must be - // greater than or equal to the ask price defined within the contract and - // only the ask price will be charged at the time of investment. - cosmos.base.v1beta1.Coin bid_price = 3; - // amount is the total amount of future credits issued that the investor is // purchasing and will receive over time with each credit issuance based on // the volume percentage defined within the contract. - string amount = 4; + string amount = 3; // auto_retire determines whether the credits will be automatically retied // upon issuance (i.e. the issuance policy will be set to auto-retire). - bool auto_retire = 5; + bool auto_retire = 4; // retirement_jurisdiction is the jurisdiction of the investor. A jurisdiction // is only required if auto-retire is enabled. - string retirement_jurisdiction = 6; + string retirement_jurisdiction = 5; } ``` @@ -365,9 +359,9 @@ message Contract { // the volume of credits and the price per credit. string metadata = 4; - // ask_price is the token denomination and amount the project is asking - // for per credit. - cosmos.base.v1beta1.Coin ask_price = 5; + // price is the token denomination and amount the project is asking for + // per credit. + cosmos.base.v1beta1.Coin price = 5; // amount is the amount of future credits issued that are available to // purchase. The amount will decrease with each investment, therefore