[borbose]

No description provided.

[matiwinnetou]

That is not typically how it works, we maintain old versions. I would rather say can you check old version - if it is correct, if not fix it and then add a new version. In DeFi, versions stay forever because liquidity maybe locked still with older versions (no?), unless of course Indigio has admin keys and moves all the liquidity... (which I assume is not the case?)

[borbose]

That is not typically how it works, we maintain old versions. I would rather say can you check old version - if it is correct, if not fix it and then add a new version. In DeFi, versions stay forever because liquidity maybe locked still with older versions (no?), unless of course Indigo has admin keys and moves all the liquidity... (which I assume is not the case?)

There is not liquidity in any old version script, and that is not because Indigo has admin keys, but because Indigo has upgrade procedures in place where liquidity migrates following on-chain rules governed by the DAO...

In any case, here is what I have done: I have mostly added new records to the old versions (as many authentication minting policies that are used throughout all the versions, even from v1, were not registered) but haven't deleted any old scripts were liquidity lived. It might seem so as the scripts for the v2 release are "deleted", but in reality they are just added as a second version of the v1 scripts, instead of new scripts with "version 1". So, for example, before there was a CDP script for v1 (with "version: 1") and another CDP script for v2 (also with "version: 1"). Since the script serves the same purpose and share the same name (and liquidity migrated from one to the other), I thought it would be better to have it as a new version instead of a brand new script. You can check that all the v2 script hashes are still preserved.

This also allows to build on top of it and add the v2.1 and v3 releases, keeping things more tidy. If this is a problem and the old v1 and v2 releases are to be treated as immutable (even if they are not as accurate as they could be), then I can keep the old records and strictly add new releases to them.

[matiwinnetou]

If you use upgradable smart contracts and liquidity is automatically migrated, I see no big issue, speaking as a purist, I would still like to have a full history on this, because this repository is also used for cases where some old transaction interacted with former version of Indigio, so yes, if this is not too much trouble on your side. Lets have this as separate versions and assume it is immutable - for historical reasons. Let me know if this is an issue, I hope not...

For instance Eternl wallet uses this repo and people may have old transactions with older Indigio contracts.

[borbose]

Before we make any further changes, and because the changes made here so far can be a bit confusing, we would like to try our best to communicate them so we are on the same page and there are no misunderstandings. This will be as detailed of an explanation as possible, so it might be a bit long, but we hope this will help bring clarity and better advise on next steps.

These are the changes made in this PR:

For release number 1 (V1):

• Added scripts XfzHu6, q2EgWs, e5smYm, GlG5aF, 7Ch6z7, pjJKs3, NfaOD8 and 5VmIkY. These scripts correspond to various minting policies such as INDY and authentication tokens used throughout the protocol. For completeness, we are adding those to the V3 release record, but as they were there from V1 and seeing they were not included there, we are also adding them to the V1 record. Again, this is because they are not new scripts from V3, but scripts that were used from the first iteration of the protocol.

• Modified the name of the script IGx8dF. It was incorrectly named Stability Pool when in reality it should have been named Fee Collector, as this is not the script that locks the stability pools and set the rules for interacting with them, but rather the script that controls fee collection when interacting with some parts of the protocol. The script hashes and address are left untouched, it's just that the name is changed for better accuracy.

• Modified the name of the script U1TRVE. Previously it was named Stability pool account to differentiate it from script script IGx8dF (Stability Pool). As script IGx8dF was incorrectly named, script U1TRVE can take the more general and appropriate name Stability Pool. This is because it does not only lock and controls stability pool accounts, but also the stability pool themselves. The script hashes and address are left untouched, no changes there.

• Modified the name of scripts xRcvDg (Poll Manager) and Kee1gS (Poll Manager upgrade) to Poll Shard and Poll Manager respectively as the new names are more descriptive and is how they are named in newer versions of the protocol. The script hashes and address are left untouched, no changes there.

• Added the scripts 6RFaex and 8yiBHh. They are scripts used in V1 that were not registered. As for the newer version V3 the corresponding scripts are being registered, for consistency and completeness we think it is better to update the V1 record too.

• Removed the scripts KuAAJc, YMLObk and TvFLk3. This might seem more controversial as it is deleting records, but there was never liquidity in them and they are just the price oracles used for the initial iAssets present when the protocol launched. As we do not update the registry every time a new iAsset is listed (there are new iAssets being listed between protocol releases too) and it is not part of the core protocol, we are not including these kind of scripts for the V3 registry record. In order to keep things as clean and consistent as possible, seeing that it is not part of the core Indigo Protocol, and that in any case those records are incomplete as they are not including all iAssets, we think it is better to remove these kind of scripts from the registry.

• Reordered the script entries so that they are grouped in a more intuitive way (for example, all minting policies first and spending validators later).

• Removed the contracts and audits links as they do no longer exist or are no longer relevant.

For release number 2 (V2):

• Removed the script 5VPVq and moved the script hashes and address as a second version of script IGx8dF. This is because it is not conceptually a new script (with a new name and description) but rather the upgraded version of the Fee Collector used in V1. Instead of adding a new script reference with the same script name, we believe it is cleaner and conceptually more intuitive to understand if it is placed as a second version of the original script.

• Removed the script VC5xGL and moved the script hashes and address as a second version of script HWzqk7. This is because it is not conceptually a new script (with a new name and description) but rather the upgraded version of the INDY staking used in V1. Instead of adding a new script reference with the same script name, we believe it is cleaner and conceptually more intuitive to understand if it is placed as a second version of the original script.

• Removed the script tNJGzu and moved the script hashes and address as a second version of script BWdicZ. This is because it is not conceptually a new script (with a new name and description) but rather the upgraded version of the CDP used in V1. Instead of adding a new script reference with the same script name, we believe it is cleaner and conceptually more intuitive to understand if it is placed as a second version of the original script.

• Removed the script hUv99s and moved the script hashes and address as a second version of script U1TRVE. This is because it is not conceptually a new script (with a new name and description) but rather the upgraded version of the Stability Pool used in V1. Instead of adding a new script reference with the same script name, we believe it is cleaner and conceptually more intuitive to understand if it is placed as a second version of the original script.

• Removed the script d6PYKd and moved the script hashes and address as a second version of script WlL90Y. This is because it is not conceptually a new script (with a new name and description) but rather the upgraded version of the CDP Creator used in V1. Instead of adding a new script reference with the same script name, we believe it is cleaner and conceptually more intuitive to understand if it is placed as a second version of the original script.

• Removed the script t1mLuw and moved the script hashes and address as a second version of script Kee1gS. This is because it is not conceptually a new script (with a new name and description) but rather the upgraded version of the Poll Manager used in V1. Instead of adding a new script reference with the same script name, we believe it is cleaner and conceptually more intuitive to understand if it is placed as a second version of the original script.

• Removed the script RaXF2E and moved the script hashes and address as a second version of script 5x7zd1. This is because it is not conceptually a new script (with a new name and description) but rather the upgraded version of the Upgrade used in V1. Instead of adding a new script reference with the same script name, we believe it is cleaner and conceptually more intuitive to understand if it is placed as a second version of the original script.

• Removed the contracts and audits links as they do no longer exist or are no longer relevant.

Therefore, the changes made for V2 are so that the structure of the Indigo Protocol entry in the registry is the following for upgraded but conceptually equivalent scripts:

    Script A:
       - version 1 (corresponding to release 1, V1) with script hash X
       - version 2 (corresponding to release 2, V2) with script hash Y

Instead of:

   Script A:
      - version 1 (corresponding to release 1, V1) with script hash X
   
   Script B:
      - version 2 (corresponding to release 2, V2) with script hash Y

This allows us to add newer versions of the protocol such as V3 by adding a new version instead of a whole new script:

      Script A:
       - version 1 (corresponding to release 1, V1) with script hash X
       - version 2 (corresponding to release 2, V2) with script hash Y
       - version 3 (corresponding to release 2.1, V2.1) with script hash Z
       - version 4 (corresponding to release 3, V3) with script hash U

Instead of:

   Script A:
      - version 1 (corresponding to release 1, V1) with script hash X
   
   Script B:
      - version 2 (corresponding to release 2, V2) with script hash Y
   
   Script C:
      - version 3 (corresponding to release 2.1, V2.1) with script hash Z
  
   Script D:
      - version 4 (corresponding to release 3, V3) with script hash U

As the protocol evolves and new releases are added, it gets messier and harder to navigate and understand if we add a whole new script reference for each upgraded script. This is why we are restructuring the registry entry. History is not being deleted, as the old hashes from outdated versions are still kept, just reorganised as newer versions instead of new scripts.

So our natural question for you is the following: is this new approach messing up with your maintained records and the display for users of old versions of the Indigo Protocol, or is it fine as the script hashes are still being registered, just under a different structure?

Finally, following this new structure, releases 2.1 and 3 are added, with new scripts being newer versions of old scripts when applicable or brand new scripts for new functionalities of the protocol.

Please let us know if this explanation changes your view on the appropriateness or correctness of this PR or if you still would like to see further changes made.