Registry for 3rd party apps building on top of Anchor

Anchor and Terra is a great product and it is doing its intended job-- attract mainstream adoption through savings as a service.
There are a quite a few applications that are building on top of anchor to try to bring these Defi savings interest to the mainstream “normie”. This is a great thing and I think what the protocol was intended to do. (Forgive me if this is a duplicated idea-- I am fairly new to this forum).

An example of such applications;,,, etc.
There are likely many more ‘hiding in the shadows’

**My proposal is that there should be an official registry for these projects **
I think it would be in these applications self-interest to register, but it should be optional.
This registry could be an additional section within the governance page.

1. Forecast Earn Demand
Projects could state their intentions in an open way and provide a forecast of user activity so that the total future earn demand can be estimated/forecasted. If there is some idea of what is coming; and we/developers can gauge the level of deposits coming and adjust the protocol accordingly. Ie: if one of these apps becomes and overnight sensation and 10 billion dollars is deposited quickly and unexpectedly — the collateralization/money market mechanism could get unbalanced and might not be able to attract borrowers quickly enough to maintain equilibrium. If borrowers had a better idea of the earn demand coming; they might be incentivized to borrow more ahead of time.

2. Master/Sub wallet: A registered project could have a ‘master wallet’ whereby the 3rd party application can interact with anchor on behalf of their sub users.

Most projects would probably do this themselves and control user deposits/actions with a series of master wallets rather than individual wallets. If it is possible to link master/sub wallets some projects may opt for this model. For their end users having and individual sub-wallet, whether self custody or application controlled custody, may be more secure, transparent and desired.
The Sub wallets could simply contain the user’s earn deposits, while the master wallet could interact with the protocol’s governance on behalf of their user’s sub wallets. This could allow applications and anchor itself to adjust to future governance/protocol changes in a more robust/agile way.

For example; if the stake anchor for tiered interest rates idea on this form is implemented, the master wallet could be designated as the ANC stake on behalf of it’s sub users. If a percentage ANC vs deposit model is used, the master wallet for the application would be incentivized to increase ANC stake relative to the sum earn deposit of its sub users.

I don’t know what other future protocol/governance changes will occur in the future but setting up such a master/sub wallet system might be beneficial for any such future changes.

The applications master key can be used for governance voting as these applications will have a much larger vested interest in the protocol.

Additionally it might be useful to allow master wallets to ‘set’ their sub user’s interest rates up to the protocol maximum. Any difference in the interest could be paid into the master wallet to fund their operational costs. (ie issuing debit cards, admin costs, etc.)

Without this master/sub wallet; I would presume the applications would only have a series of master wallets and maintain their own ledger elsewhere.

  1. Other benefits:
  • Projects can state their intended launch dates and project status

  • Provide an easy way for discovery of these applications

  • Allow for ANC governance proposals for community funding of these applications to increase protocol usage

Thanks! ~~~

What’s in it for the project teams?

Free advertising. 20 characters.