Per-encryptor fee model rules

[arjunhassard]

Adjustable parameters are denoted by x and will vary on a per-adopter and per-partner basis.

Node rental ('base fee') $x / node / day Base fee increases by 5% per year

Encryptor credit ('user fee') $x per encryptor credit per year. Note that encrypting privileges can be added and removed from addresses at will, without charge, provided the sponsor has pre-paid for sufficient credits and there are slots available.

There is no charge, payment gate or limit on:

• encryptions.
• types or combinations of conditions specified.
• unique requestor identities.
• throughput/number of requests.
• decryptions.
• condition validations/invalidations.
• additions/removals of addresses to/from the authAdmin list.
• additions/removals of addresses to/from the encryptor allowlist.
• any other communication with the network or API.

Payment rules

• Both fees must be paid in advance of service commencement.
• Both fees must be paid for a minimum duration x months ('one cycle').
• Both fees must be paid in advance of the recurring annual renewal date, which will be the same date for both fees.
• If extra encryptor credits are required before the next renewal date, they may be added at will, anytime. The price point will be pro rata, calculated from the moment the request is submitted until the next recurring annual renewal date.
• Hence payments can be one of two types:
  • Transaction 1: to renew a subscription, for both fees, once per cycle
  • Transaction 2: to add more encryptor credits, at any time
• The total number of cycles a sponsor can pay for in advance is capped at x, but this may increase in the future for certain long-term use cases (may require a non-upgradeable contract or failsafes added to the DAO).
• If the encryptor credit is maxed out, it will not be possible bestow encrypting privileges to a new address (authorize a new encryptor).
• Total encryptor credits can be reduced, but only at the next renewal date. I.e. a sponsor can choose to pay less than the previous cycle, which will result in fewer credits for the next cycle. They can still re-add credits at any point during that year.
  • If a sponsor reduces the number of encryptor credits to a point where there are more addresses authorized than there are credits, the subscription will automatically enter into the first grace period (yellow), detailed below – with the exception of being able to deauthorize addresses (or pay for more) until the number of credits matches the number of addresses with encrypting privileges.
• If a renewal payment occurs after the renewal date (during one of the two grace periods), the renewal date will reset to the day after the payment is received).

Grace periods – see https://github.com/nucypher/nucypher-contracts/issues/262

Summary: If fees are not paid ahead of renewal, the service will enter into the first of two grace periods (each 3 months). In the first grace period, existing end-users will not be affected, but it will not be possible to add new users. In the second grace period, nothing will work for end-users, but the ritual remains recoverable if the sponsor (or another sponsor) steps in and pays the fees. If the second grace period lapses with no payment, the cohort will irreversibly disband and data will not be retrievable.

If either fee is not paid by the renewal date, the following will occur:

• First, the cohort & ritualID will enter into a 'primary grace period' of 3 months. During this time:
  • Encryptors will be able to encrypt using the public key (ritualID).
  • Requestors will still be able to submit access requests, fulfill conditions and receive decryption material from nodes.
  • However, all allow lists and allow logic will be unusable. Cohort admins and auth admins will not be able to add or remove encryptor addresses to the allow list, regardless of how many credits are available.
  • In later versions, cohort admins will also be unable to make changes to the cohort; e.g. change the size, threshold, composition, or handover sampling method.
• Second, if either fee remains unpaid after the primary grace period elapses (renewal date + 3 months), the cohort & ritualID will enter into a 'secondary grace period'. During this time:
  • Requestors will not be able to receive decryption material (i.e. access) to any data encrypted under this public key (ritualID), regardless of when it was encrypted.
  • Encryptors can technically still encrypt using the public key, but that data will not be accessible by anyone.
• Third, if either fee remains unpaid after the secondary grace period elapses (renewal date + 6 months), the cohort & ritualID will be irreversibly destroyed – i.e:
  • The cohort will disband.
  • Nodes will forget key material.

[arjunhassard]

Finalized rules for first paid dual-fee subscription contract

Adjustable parameters are denoted by x and will vary on a per-adopter and per-partner basis.

Fee Types

Node rental ('base fee') $x / node / day Base fee increases by 5% per year

Encryptor credit ('user fee') $x per encryptor credit per year. Note that encrypting privileges can be added and removed from addresses at will, without charge, provided the sponsor has pre-paid for sufficient credits and there are slots available.

There is no charge, payment gate or limit on:

• encryptions.
• types or combinations of conditions specified.
• unique requestor identities.
• throughput/number of requests.
• decryptions.
• condition validations/invalidations.
• additions/removals of addresses to/from the authAdmin list.
• additions/removals of addresses to/from the encryptor allowlist.
• any other communication with the network or API.

Payment Terms

• Both fees must be paid in advance of service commencement.
• Both fees must be paid for a minimum duration of 6 months ('one cycle').
• Refunds are not supported. Once a fee transaction is complete, it is irreversible.
• Both fees must be paid in advance of the recurring annual renewal date, which will be the same date for both fees.
• If extra encryptor credits are required before the next renewal date, they may be added at will, anytime. The price point will be pro rata, calculated from the moment the request is submitted until the next recurring annual renewal date.
  • Hence payments can be one of two types: Transaction 1: to renew a subscription, for both fees, once per cycle Transaction 2: to add more encryptor credits, at any time
• Renewal fees (Transaction 1) can be paid at any time before the expiry date, but once these have been paid, one cannot add more encryptor credits until after the next renewal date.
• The total number of cycles a sponsor can pay for in advance is capped at 1, but this may increase in the future. If the encryptor credit is maxed out, it will not be possible to bestow encrypting privileges to a new address.
• Total encryptor credits can be reduced, but only at the next renewal date.
  • A sponsor can choose to pay less than the previous cycle, which will result in fewer credits for the next cycle. They can still re-add credits at any point during that year.
  • If a sponsor reduces the number of encryptor credits to a point where there are more addresses authorized than there are credits, the cohort & ritualID will enter into a special grace period known as the Orange Period. In this period, similar to the Red Period below, requestors will not be able to receive decryption material.
    • Cohort admins will be restricted to two actions: (1) removing encrypting privileges from addresses and/or (2) paying for more credits, until the number of credits matches the number of addresses with encrypting privileges, at which point the cohort & ritualID will return to normal functionality.
    • However, unlike the Red Period, the Orange Period is indefinite as long as the base fee continues to be paid (i.e. the cohort and ritualID will not enter into the Gray Period due to a lack of encryptor credits).
• If a renewal payment occurs after the renewal date (during either the Yellow or Red Periods), the renewal date will reset to the day after the payment is received.

If either fee is not paid by the renewal date, the following will occur:

• First, the cohort & ritualID will enter into a primary grace period of 3 months known as the Yellow Period. During this time:
  • Encryptors will be able to encrypt using the public key (ritualID). Requestors will still be able to submit access requests, fulfill conditions and receive decryption material from nodes.
  • However, all allow lists and allow logic will be unusable. Cohort admins and auth admins will not be able to add or remove encryptor addresses to the allow list, regardless of how many credits are available.
  • In later versions, cohort admins will also be unable to make changes to the cohort; e.g. change the size, threshold, composition, or handover sampling method.
• Second, if either fee remains unpaid after the Yellow Period elapses (renewal date + 3 months), the cohort & ritualID will enter into a secondary grace period of 3 months known as the Red Period. During this time:
  • Requestors will not be able to receive decryption material (i.e. access) to any data encrypted under this public key (ritualID), regardless of when it was encrypted. Encryptors can technically still encrypt using the public key, but that data will not be accessible by anyone.
• Third, if either fee remains unpaid after the Red Period elapses (renewal date + 6 months), the cohort & ritualID enter into a permanent Gray Period will be irreversibly destroyed – i.e:
  • The cohort will disband.
  • Nodes will forget key material.