# Constellation Protocol: Proof of Intent Follow-up
Responses to SDF feedback (*in italics*).
[Original Proof of Intent Submission](https://hackmd.io/@captain-deploy/r16pAEORn).

Github repo for code samples: https://github.com/captain-deploy/constellation-pseudocode

### 1. Detailed Technical Specification & Design:

> *Smart Contracts & Functions: A deeper explanation of the ConstellationToken and ConstellationTokenCreator contracts and their interactions within the ecosystem is needed. Exploring how they interact with other contracts, interfaces, and libraries in the protocol would be beneficial.*

The [ConstellationToken](https://github.com/captain-deploy/constellation-pseudocode/blob/main/constellation-token/src/contract.rs) contract is an extension of a standard Soroban Token implementation. Unlike standard tokens, the Constellation Token stores balances of other tokens which are referred to as "components". These components can be Stellar assets that are wrapped by the SAC, but they don't have to be. For example, a ConstellationToken `cUSD` could be deployed & initialized with two components on Testnet:

1. Wrapped USD `CDSJ7EDWJUX77APNVPJ2SXB6FOXXBRNQAQPD2EQUFFMYPOZLEG5JCSLU`
2. Wrapped yUSDC `CAYSXAAFPQZEZOTWN3CQIIY3RMIZ4EFCHWI5PH35OGO7YQUXDIS2BDXT`

These two tokens were deployed via the `soroban lab token wrap` CLI command, but ideally the wrap step could also be done as part of the Constellation Token deploy function. Note that Stellar assets with authorization flags set cannot be used as components.

The resulting `cUSD` token will have privileged mint() and burn() functions that must be called through a special [ConstellationMinterBurner](https://github.com/captain-deploy/constellation-pseudocode/blob/main/constellation-minter-burner/src/lib.rs) contract that gets initialized as the token's admin.

impl ConstellationMinterBurner {
    // Swap component tokens for newly minted Constellation tokens
    // Function could also be called "issue()", but that might cause confusion with Stellar asset issuance
    pub fn mint(
        env: Env,
        from: Address,
        to: Address,
        ctoken: Address,
        ctoken_amount: i128,
    ) {
        // Verify 'from' has enough of each component token for ctoken_amount
        // Verify 'from' has approved allowances for each component token 
        from.require_auth();
        // Transfer component tokens from 'from' to the ConstellationToken contract
        // Mint ctoken_amount of Constellation tokens to 'to' address
        let ctoken = constellation_token::Client::new(&env, &ctoken);
        ctoken.mint(&to, &ctoken_amount);
    }

    // Swap user's Constellation tokens for components, and burn Constellation tokens
    // Function could also be called "redeem()"
    pub fn burn(
        env: Env,
        from: Address,
        ctoken: Address,
        ctoken_amount: i128,
    ) {
        // Verify 'from' user has approved ctoken_amount
        // Transfer component tokens from ConstellationToken contract to 'from' address
        // Burn ctoken_amount of Constellation tokens from user
        let ctoken = constellation_token::Client::new(&env, &ctoken);
        ctoken.burn(&from, &ctoken_amount);
    }
}

The [ConstellationTokenCreator](https://github.com/captain-deploy/constellation-pseudocode/blob/main/constellation-token-creator/lib.rs) is a simple factory contract, similar to the "Deploy" Soroban code example.

impl ConstellationTokenCreator {
    pub fn deploy(
        env: Env,
        decimal: u32,
        components: Vec<Address>,
        amounts: Vec<u32>,
        admin: Address, // ConstellationMinterBurner contract ID
        manager: Address, // For future use; manager can rebalance and charge fees
        name: String,
        symbol: Symbol
        wasm_hash: BytesN<32>,
        salt: BytesN<32>,
    ) -> (Address) {
    ...
    }

### 2. Description of Key Contract Functions w/Pseudocode:
> *Pseudocode: Including pseudocode for key contract functions, particularly those related to issuance and redemption mechanisms, would provide clarity on the operational logic of the system.*
>
> *Human-Readable Documentation: Expanding on the inputs and outputs of key functions, especially issue and redeem, would enhance understanding.*

See above and this github repo: https://github.com/captain-deploy/constellation-pseudocode.

### 3. Additional Notes:
> *Rebalancing Mechanism: A clearer explanation or a basic model of how the rebalancing mechanism would work in future versions, without compromising security, would be insightful.*

Rebalancing a Constellation Token index happens in three key steps:
1. Token Manager calls an Auction contract with new target components and amounts for the index, along with auction parameters.
2. The Auction contract starts a Dutch auction for each component, priced in an intermediate token (ex. wrapped USD)
3. 3rd parties fill the auctions by swapping (target amount - current amount) of component for an acceptable amount of intermediate token.

See https://github.com/captain-deploy/constellation-pseudocode/blob/8dd891da77074df418f494725b3c5dee4f4cfebf/constellation-token/src/contract.rs#L109

> *User Incentives: A brief on what would motivate users to deposit liquidity into the index, and how they benefit from holding the index token, would add depth to the proposal.*

This is a good line of inquiry for on-chain indexes in general, regardless of blockchain. It's still early days for tokenized indexes, and much of their value to users is yet to be realized. In principle there are at least 3 reasons why users would be motivated to deposit liquidity into indexes.

1. Diversification. As more assets are brought on chain, the value of "1 click" diversification grows. For example, an index could represent tokenized deposits in 10 different FDIC insured banks. This type of diversification became popular after Silicon Valley Bank collapsed. It's much easier to buy a single token instead of opening 10 different savings accounts (or even 1 account for that matter).
2. Tokenized investment strategies. An index token could be actively or algorithmically managed to make investments on behalf the holder. For example, a token could represent a leveraged staking strategy, like [icETH](https://indexcoop.com/products/interest-compounding-eth-index) on Ethereum.
3. Index tokens as collateral in DeFi. Because index tokens can be cheaply redeemed for their underlying assets, they can serve as collateral for loans, or be locked in escrow contracts.

It's reasonable to believe that if DeFi on Stellar grows rapidly after Soroban's public release, adoption of tokenized indexes will grow as well.

> *Legal Concerns: Although not a promised deliverable, addressing how the redemption of underlying assets will work, considering potential legal and regulatory challenges, would be valuable.*

It's possible that Constellation Tokens are later deemed securities in the U.S. While this is uncertain, a conservative approach is for any user-facing apps that use to block U.S. persons from buying/holding Constellation Tokens. As for the protocol itself, it should respect any authorization rules of the underlying assets. Stellar assets have a lot of features to help with compliance, and these shouldn’t be lost when wrapping them into Constellation Tokens. However, the protocol will initially only support wrapped Stellar assets that do not have authorization flags.

> *Security Concerns: The use of a Token Manager with privileged roles raises security questions. Exploring and explaining a more decentralized and secure approach to manage rebalancing or other administrative functions would be prudent.*

The Token Manager can be either a single party, or a more decentralized setup like a multi-sig or an on-chain governance contract. Users should understand the potential risks of a highly privileged Token Manager, and accept they are trusting the Token Manager to act in good faith. If the Token Manager were to act maliciously, they could rebalance an index into a bogus token, or unilaterally charge high fees without notifying users (if/when fees are implemented).

Building additional contracts into the protocol to enable responsible governance and decentralization of key functions could give users better trust guarantees, and should be considered for future upgrades. A simple timelock on admin functions would also mitigate counterparty risks.