See instruction specification outlined in instruction.rs and processor/initialize2.rs.

• Atomic task for #10 (see for additional details)
• In instruction.rs add a public wrapper function that makes it easier for other programs building on buoyant to create an instruction for Initialize when performing a cross program invocation

• Maybe do a meme-y intro of us trying to find a project and just picking some random one off the riptide ideas list lol
• Maybe make some basic slides just for transitions and stuff
• Use website and/or docs to flow through an overview of what it is and how it works
• Use frontend demo app to demo functionality/basic product built on the protocol

• For Riptide you can submit slides or a video - to show functionality I think a small frontend dashboard/control panel would be helpful to show it, and we can run a crank from a node.js script
• Film with loom

• Atomic task for #10 (see for additional details)
• In instruction.rs add a public wrapper function that makes it easier for other programs building on buoyant to create an instruction for Renew when performing a cross program invocation

Now that gitbook docs are launched, we can change readme to more of a basic overview and contribution guidelines

• still keep basic description
• links to website, twitter, docs
• how to build and deploy program
• overview of scripts and how to run
• running our website - look in head tag for a helpful comment, also its literally an html file lmao
• contributing - basically our engineering flow: assign yourself an issue, create new branch, dummy commit, draft PR, make changes, change PR to be ready for review, request review, iterate, merge
• Also add a part on why we went with raw solana and not anchor - mainly we wanted to build and hadn't learned anchor yet but we had alr gotten started with raw SOL for fundamentals/intuition

becoming a sort of dev ux standard + saves on compute inside program instructions, which is something we could feasibly care about - rn a full renew takes up ~15k/20k compute units

main tasks here:

• for all existing PDAs (besides token/mint accounts)
  • add a bump field in the state.rs
  • if the program initializes the PDA, make sure to initialize it with enough space to hold the bump
  • whenever that PDA is passed into an instruction and validated, use create_program_address and include the bump as a seed
    • change the current check_pda helper to maybe take in another with_bump: bool parameter and use create_program_address or find_program_address based on that
    • OR add a check_pda_with_bump function

note:

• for Subscription metadata, please add the bump at the end of the struct because my initialize.js script deserializes some stuff with kinda hardcoded values so adding it at the beginning would break that, but at the end its all good.
• also for subscription metadata, store the count seed

also:

• if whoever's implementing this has the time, throw in changes to check_initialized_ata to 1) be renamed to check_ata_initialized and run check_ata within it so you don't have to run both

• Realized that because we can just mark the active flag and set a new next_renewal_time, we don't really need to create a new mint to "revoke" the subscription
• Also in this case, you should make sure to initialize the mint/token in initialize
• See #56 for related info

Would be nice to have this before launch/video demo

Basic outline

• two accounts - 1 holding a long ass list, 1 holding count
• data is just straight bytes denoting parameters (32 for payee key, 8 for amount, 8 for duration = 48 bytes total per entry)
• start with just one account (max size = 10MB = 10,000,000B = ~200,000 48B entries), can upgrade later if needed
• all the function does is
  • validates the pda
  • takes current list, withdraws rent from account to signer, allocates new account with space for a new entry (payer is signer), appends new entry to list and populates new account data

PDA seed schemes:

let registry_seeds = &[
    b"subscription_registry",
    &count.to_le_bytes(),
];

let counter_seeds = &[
    b"registry_counter",
];

Question

• Should subscriptions just be automatically be added to registry upon the first creation of one? (default: no)
  • would mean that literally every subscription is on the registry but also could clog registry with dummy/test subscriptions that don't actually need to be stored
  • also ig if products wanted to limit renewals to their own cranks opting out of the registry is helpful ig... but if ppl paying then the info is out there...

Checking

• Check if the subscription is actually initialized when they go to add it by taking in the count as an input
• This way someone cannot just bullshit a list

To Do

• Constant time lookup (prevent duplicating a subscription using hash map)
• Also possible solution to previous question, could allow user the option to add a subscription to registry with an input bool

Didn't realize this till it was already up - 2 lines for "tradable subscriptions" makes the cards uneven - fix by making font smaller or smth..? Maybe even change back to "liquid subscriptions"

Basic examples showcasing the usage of our protocol + APIs. See linked issues.

Make a new folder called examples and put them in here.

• When withdrawing rent upon expiry, we expect the runtime to delete the account, however this is only valid between transactions. If someone where to insert an instruction after this that uses the dormant account data in a malicious way, this could be bad.

Action:
In the renew instruction code, when it expires a subscription (sets lamports to 0), also zero out the data.

See instruction specification outlined in instruction.rs and processor/renew2.rs.

Currently a bunch of helpers are defined in rust-client that should be moved to inside program

rust-client should import the buoyant crate as answered here: https://stackoverflow.com/questions/45519176/how-do-i-use-or-import-a-local-rust-file

• Noted in #16 - need to add links to docs and frontend demo before launch
• Also change "Liquid Subscriptions" to "Tradable Subscriptions"
• Make the background color get darker faster as you scroll
• Also add description head tag for basic SEO
• Change tab titile from "Buoyant Protocol" to "Buoyant"

• Atomic task for #9
• Setting up the this API is composed of a few main things
  • Configuring typescript
  • Setting up to publish an npm package - how do you structure things, export things, etc. such that someone can use everything they need to easily when they install note modules
  • How to actually publish to npm package registry

Possibly helpful resources:
General setup: https://www.tsmean.com/articles/how-to-write-a-typescript-library/
Unit testing: https://www.tsmean.com/articles/how-to-write-a-typescript-library/unit-testing/
Example in practice: https://github.com/solana-labs/solana-program-library/tree/master/token/js

When subscriptions expire, the rent from the deposit vault and metadata accounts are withdrawn, so if someone wants to use that subscription again, they need to reinitialize it. To differentiate subscriptions of the same type (i.e. payee, amount, duration) we store a count in a separate account and increment it every time we create a new subscription. If we reinitialize a subscription, we don't want to increment.

2 things to do

1. Have count be passed into the instruction as an argument
2. If count != latest count, don't increment

Status: awaiting #15 before we'll be able to test this fully

• Atomic task for #10 (see for additional details)
• In instruction.rs add a public wrapper function that makes it easier for other programs building on buoyant to create an instruction for Withdraw when performing a cross program invocation

Status: awaiting #26 before will be able to test/implement fully

• Atomic task for #10 (see for additional details)
• In instruction.rs add a public wrapper function that makes it easier for other programs building on buoyant to create an instruction for [whatever the registry instruction is going to be called] when performing a cross program invocation

• Seems unnecessary/bad devx to get rid of the metadata upon an expire
• Change this so that crank is only compensated by closing deposit account (if not enough funds left)
• Note: upon reinitialization, a new mint/token will be created, and if there are funds left in deposit vault, they'll be transferred to current owner - will need to change tests/APIs to make this seemless

• Atomic task for #43
  In Solana, NFT metadata is updatable, so we can just use the existing standard for our subscription data (as long as it's on-chain --- need to look more into this)

Need to add two more accounts to the list - the current mint token account of the payer and the payer themselves - you want to mint the next token to the current owner of the subscription, which is denoted by the possession of a token in a token account matching the mint specified in the subscription metadata

In the case that it's the first time a subscription is being paid, the client can pass in either an arbitrary account as the mint token account, or we can define the instruction to make this account optionally. The payer is necessary for all renewals for the creation of the new mint token account.

Also buffer for renewing before expiry??

Given subscriptions are transferrable, should the original creator of a subscription be allowed to close/withdraw rent from the metadata account? (even if it's expired?) Or really the current owner of the subscription should be allowed to close/withdraw rent

Don't know if it's really a problem but this would have PDA fragmentation, as the count of subscriptions is just incremented - maybe this could be good, if people close a subscription, they could be reused? would add a little complexity to client side (would need to loop through all PDAs to check if they're closed to find one) and would need to add a check program side to accomodate for previously initialized instructions

• Similar to #9 but for on-chain programs (and in Rust)
• Should make it easy to use CPIs for other on-chain programs to interface with our protocol
• Will involve publishing our program + api as a crate

Note for implementing: SPL libraries are a great resource as always! The token program does exactly what we're looking to do - link to their instructions + wrappers: https://docs.rs/spl-token/latest/src/spl_token/instruction.rs.html#1-1522

Need to add an account to this instruction: the payer's token account for the token denoting ownership of the subscription. This is to ensure only the rightful owner of the subscription is able to withdraw funds from the deposit vault.

Implementing this check: 1. check that this token account's mint matches the mint specified in the subscription metadata 2. check the amount in the token account is > 0 3. bam

Example script for cranks to use. Written in Rust.

Allow two options: 1) run crank for a certain subscription type 2) run crank over registry.

Ideas for implementation

Brute force: Basically just loops through registry, for each subscription type, it finds the total count, loops through each address, sends renew instruction
Time sensitive: Loops through everything and retrieves next renew times, sorts the next renew times earliest to latest, sleeps until that time, then sends tx.

Initially when creating a test script for the initialize instruction I had set the PDA seed scheme to be ["subscription_metadata", user, payee, amount, duration], but now I'm thinking otherwise:

• reason to include user is to have seed ensure account was created by this user, mainly for closing later, but doesn't seem necessary
• with just "...", payee, amount, duration, we need a way to differentiate many of the same kind of subscription - atm you'd only be able to initialize 1 subscription with these params, and then you'd run into an "already initialized" error

Ideas for new scheme:

• Just these seeds + a counter number at the end
  • having these params as seeds is wicked - products will easy lookups when running cranks as subscriptions of the same kind will all have these seeds
  • downside is to have this number, we need to make another account to store this (and would check + increment everytime initialize is called) - a lil clunky ux on the dev side (clients initializing would have to check the counter account to get the latest number whenever initializing) but idrk another way, and it's not thaat much of a hassle, also could be abrastracted away if we provide our own wrappers/API

https://github.com/neodyme-labs/solana-security-txt
https://explorer.solana.com/address/Fpwgc9Tq7k2nMzVxYqPWwKGA7FbCQwo2BgekpT69Cgbf?cluster=devnet

We really launching a product 💪

• Expose an interface to make it easier for people to build on top of this
• This would include...
  • Classes for accounts and deserialization methods
  • Instruction wrappers
  • Other helper functions
• Would involve publishing an npm package

Basically this file but on steroids - also some of the following are already implemented in the previously mentioned file, just need to separate, add types, comments/documentation, and figure out file structure for npm package

Outline

• Constants: BUOYANT_PROGRAM_ID, FEE, FEE_DECIMALS etc.
• Subscription class
  • Metadata fields
  • Deserialization through constructor - given account data bytes (Uint8Array), or normal necessary fields
• Instruction wrappers
  • Initialize
  • Withdraw
  • Renew
  • [Registry instr]
• Other helper functions
  • getSubscriptionPDA(payee, amount, duration, count)
  • helpers to retrieve certain accounts needed for instructions when you only have certain data

• Atomic task for #50
• Create a minimal full-stack web app that interfaces with our protocol
• Frontend - button to create subscription of a required type, button to send request to backend to view some data
• Backend - stores some file with an arbitrary message, exposes a GET endpoint that will only return the file's contents if the sender has an active subscription of the given type

• Atomic task for #43

• Atomic task for #50
• Create a minimal on-chain program + dapp that interfaces with our program
• Frontend - button to create subscription of required type, button to mint an NFT
• Program - single instruction, checks a provided subscription metadata, if it's the required type and it's active, then mint an NFT to the user (and create necessary associated token account if needed)

Right now people are incentivized to enforce renewals because when funds are transferred, a proportion of that fund is paid to the caller. This is not the case for expiry!

On expiry, it's possible that there are no funds left in the deposit vault, so the caller can only be paid by withdrawing rent from either the deposit vault account or the metadata account, effectively closing the subscription. See #13

Actions:

• Problem: don't want to withdraw rent/close account if there are tokens left, need some way to get paid. Solution...
  • In Renew, if number of tokens in deposit vault is 0, withdraw rent from subscription and call CloseAccount on token program to close deposit vault
  • In Renew, if number of tokens in deposit vault is >0, take same amount of tokens that you would've taken upon a renewal - if there are less than that, just take whatever's left.
• Problem: expired accounts that had their rent taken from them need/need not be reinitialized?
  • Option 1: don't let people reinitialize them, whenever initialized is called it only initializes new account (default)
  • Option 2: reinitialize old account
    • reinitialize, need user to pass in count seed
    • Don't increment counter

Also:

• Add in check_initialized_ata for the payee and caller token accounts if they are already initialized

High Level

Current design: 1 of 1 NFTs representing ownership of every single subscription, new mint/NFT for every renew, raw on-chain subscription metadata
New design: 1 mint per subscription type, no new mint per renew, metaplex NFT metadata as subscription metadata

Other stuff - write it in anchor, include bumps in account data

Order of Execution

1. no new mint per renew
2. metaplex NFT metadata as subscription metadata
3. 1 mint per subscription type

With the new initialize and renew (#66), it is required that a minimum of the renewal fee is present in the deposit vault such that callers are still incentivized to expire accounts (and you don't have to withdraw rent to compensate the caller).

Need to modify withdraw so that the user cannot withdraw past this minimum amount. Should a user want to withdraw the full amount, they can call the Close instruction.