Implementation Idea

[olasunkanmi-SE]

School Account

Fields:

• authority: Public key of the school administrator.
• enrollmentFee: The cost to enroll in the school (in SOL or lamports).
• classRegistry: A mapping of class names to their NFT metadata.
• bookRegistry: A mapping of book names to their NFT metadata.

Student Account

Fields:

• studentId: Unique identifier for the student (can be generated using a counter in the School account).
• studentNft: The address of the student's ID NFT.
• enrolledClasses: A list of class names the student is enrolled in.
• ownedBooks: A list of book names the student owns.

Program Functions

enroll

Inputs:

• authority: Public key of the student enrolling.
• payment: Amount of SOL (or lamports) to pay the enrollment fee.

Logic:

1. Verify the payment is sufficient.
2. Mint a new student ID NFT and assign it to the student.
3. Store the student's information (studentId, studentNft) in the School account.
4. Transfer ownership of the NFT to the student.

registerClass

Inputs:

• authority: Public key of the student.
• className: The name of the class to register for.

Logic:

1. Verify the student is enrolled in the school (check the School account).
2. Check if the class exists in the classRegistry.
3. Update the student's enrolledClasses list.
4. Optionally, mint a class NFT and transfer it to the student.

requestBook

Inputs:

• authority: Public key of the student.
• bookName: The name of the book to request.

Logic:

1. Verify the student is enrolled in the school.
2. Check if the book exists in the bookRegistry.
3. Check if the student meets the requirements (e.g., enrolled in a specific class, has completed a certain module).
4. Mint the book NFT and transfer it to the student.

updateClassRegistry

Inputs:

• authority: Public key of the school administrator.
• className: Name of the class.
• classMetadata: Metadata for the class (e.g., description, teacher, schedule).

Logic:

1. Only allow the school administrator to perform this action.
2. Add or update the class information in the classRegistry.

updateBookRegistry

Inputs:

• authority: Public key of the school administrator.
• bookName: Name of the book.
• bookMetadata: Metadata for the book (e.g., title, author, subject).

Logic:

1. Only allow the school administrator to perform this action.
2. Add or update the book information in the bookRegistry.

[olasunkanmi-SE]

Documentation diagram https://mermaid.live/view#pako:eNqNVMFy2jAQ_RWNTu4MYQzBBnzoDGAgJKHtlLSHhh5UW8EabInK8jQE8--VJRuEgaY-eLS7b7Vvn1bawYCFGHpwxdEmAk_-kgL5DZ4HYULoT3Bz8zGfUSIIiskbBosgYizOwdDSqw8aPlS4BRZgTDmL4wRTASYY52BknXpOEkYcI4HBKEZpCr7iFUkF3-bAt049l3KGjK2NlLF14pAZOmfyvBBZKGvrTjQXSb-MKucXtD2nbZacE-ku9wGfJk85mFqGWdKbaq3SNMMH8MzPwZ11tEronZZLMH6E-kigHMws0z62oRJ0d5hrwaROOuir4HfMycu21HL8WgBpIDu5t2quksO9yhqEYZkiWEVFsqjX_Z3hVCjNpdQ6NDarKvGNog_Wqaes-XCUU8WVlo9WtS5Rjwo15aiCff5DMU8jsjGYDRTo2ya8OEAXMPWBqTZKs1969CvhB4EgjKY6OjPGBhBaU352XR5Mw_MK6soAdbMKGqgoZFKdI4pW77RTYs7buVZVCgsWW3kOyTszbZ5r_Yyub1_MKShGWbIyVanNtTmqV_rTlf-_sWHMgnUQIULNC6huVQgYNeKH5h7_ATF7LBbFHzZggnmCSChfyF3hWUIR4QQvoSeXIeLrJVzSvcShTLDFlgbQEzzDDchZtoqg94LiVFqZGkKfIEk9qSA4JJLJXL-_6hluwA2iPxhLDonSht4OvkLPtZtuv3Xbtl231bYdu9eAW-jdtpxmp9vtOj3Hdvtuv71vwDe1gd3sOT236_Z6TrfTcWTS_i92N9-d

[somthn0somthn]

I like this a lot and think it is the general direction we should go.

Personally, I'm still grappling with Anchor design patterns so I'd prefer to start more simply. If everyone else is already comfortable with Anchor design, then we can ignore this and I'll play catchup.

If people want to take this route, I'd suggest we make a simple first iteration just to ensure it works, is at least modestly secure and we have basic frontend connectivity:

---

School Account

Fields:

• authority: Public key of the school administrator.
• enrollmentFee: The cost to enroll in the school (in SOL or lamports).
• classRegistry: A Vec of Strings indicating registered classes
• bookRegistry: A Vec of Strings indicating class books .

Student Account

Fields:

• studentId: Unique identifier for the student (can be generated using a counter in the School account).
• studentNft: The address of the student's ID NFT.
• enrolledClasses: A list of class names the student is enrolled in.
• ownedBooks: A list of book names the student owns.

Program Functions

enroll

Inputs:

• authority: Public key of the student enrolling.
• payment: Amount of SOL (or lamports) to pay the enrollment fee.

Logic:

Verify the payment is sufficient. Mint a new student ID NFT and assign it to the student. Store the student's information (studentId, studentNft, student pubkey) in the School account. Transfer ownership of the NFT to the student.

---

Also, there were a few things I thought of here:

• Would it be easier for a first pass to just lazily indicate the class & book registries as a Vec of strings?
• If we iterate successfully, perhaps enrolledClasses and ownedBooks could be part of the NFT metadata, something which I understood to be more lightweight?
• I'd take the basic assumption that one wallet pubkey == one IRL student. If this is a good assumption, how can we ensure that one IRL student (e.g. wallet) isn't minting multiple studentID NFTs? First thought is to log the wallet pubkey

Anyway, these are my first thoughts. I'd be able to allocate some time to this over the weekend if we like this direction so far.

[maplerichie]