Add the per-token buffer accounts described in DESIGN.md: SPL token accounts the settlement program controls, used to collect/send user funds and accrue fees. This wires up the buffer addressing scheme and a `CreateBuffer` instruction that allocates and initializes the token account at the buffer PDA. Right now, these buffers can't be deallocated. Also, sending tokens there means that the tokens are lost. Actually using them means that the funds are lost. Using buffers will be part of the following PR. ## Decisions worth calling out Buffer authority is the settlement state PDA. We could use a dedicated account, but this will eventually decrease the number of accounts used in a settlement. Buffers are token accounts at our own PDA, not associated token accounts. The alternative would be to define each buffer as the associated token account of the state PDA and let the Associated Token Account program allocate-and-initialize it in a single CPI. I played with this and you can see the (unpolished) changes compared to this PR in commit 8f7c76c. Overall I prefer the current approach: it requires two accounts less and we have more control over the generated PDAs (we don't need to understand ATAs at all). Also, the main benefit of using ATA is having a canonical address for a user to use in various protocols, but for the settlement account this won't really be needed and managing a standard token account in code is actually easier. `InitializeAccount3`, not `InitializeAccount`/`2`. It seems simpler this way. You can take a look [here](https://solana.stackexchange.com/questions/18252/difference-between-initializeaccount-initializeaccount2-and-initializeaccount3) for a comparison. The three differ only by how token information is passed in, and the third is the handiest for us since we've got already all accounts we need. Legacy SPL Token only, Token-2022 yet. **Pre-funding a buffer PDA blocks its creation (known limitation).** The buffer is allocated with the system `CreateAccount`, which fails with `AccountAlreadyInUse` if the address already holds lamports. This applies to all PDAs so far. I added issue #30 to make sure we don't forget to address this later. ## New dependencies This PR adds three crates, each from the official upstream project. You can see they are subcrates of three projects we already depend on. | Crate | Project | Repository (→ crate `Cargo.toml`) | | --------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------- | | `litesvm-token` | LiteSVM | [LiteSVM/litesvm](https://github.com/LiteSVM/litesvm/blob/v0.12.0/crates/token/Cargo.toml) | | `pinocchio-token` | Pinocchio (Anza) | [anza-xyz/pinocchio](https://github.com/anza-xyz/pinocchio/blob/pinocchio-token@v0.6.0/programs/token/Cargo.toml) | | `spl-token-interface` | SPL Token (Anza) | [solana-program/token](https://github.com/solana-program/token/blob/interface@v2.0.0/interface/Cargo.toml) | ## How to test CI.

Uh oh!

PDA creation can be DoSed by sending 1 lamport to the expected PDA address #30

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions