Welcome to my Luma Profile!

Blog Posts

I send an email recap of my week on Sunday evenings. 

The Weekly Update

Jamie XX — Rejkjavik

Purity Ring — Montreal

Skillex — Shanghai

ZHU — Japan

Alison Wonderland — Los Angeles

RÜFÜS DU SOL - Joshua Tree

Favorite DJ Sets

My Website

Luma Homepage

Around the Web

Events

Winter Gala

Championship Game

Pickup Basketball

Sunset

Apple Developer Happy Hour

Melon

Climate Meetup at Dusty Owl

Demo Happy Hour

zoom

example event

Test Event

ivy-presto

My Event Yay Hi

party

St P

clover

Nuevo Evento

Victor's Coding Class

8pm Hawaii X Y

Ferry Building 1pm

Desc

Test

paid

Really

test

Winter Wonderland

Test Soon

desc

Paid

test offline

Forest

new event

workshop b

workshop a

benguiat

Thanksgiving Dinner

Figma Happy Hour

Summer

free multi tix

All Hands - Nov 20

capped event

cheap event

new virtual class

snow theme

event w/ coupon

test for notifications

ghoulish

halloween party

selling weed and gambling

event xx

new ev

one one

another

fb preview

Ticketed Event

req approval

Alo Yoga Class

xxyy

asdf

halloween pumpkin

fall fun

require approval

spooky

East River Track Run

Victor and Marissa 2 Year

example event submitted to solana

Mom Meetup in Brooklyn

Birthday Dinner

Storytelling Festival

Pop Up at UPenn

Dog Night Denver

Happy Hour at the Empire State

Breadcrumb Test Event

Daily Sync

test event

Host Delightful Events with Luma

Test Vic + Marissa Event - Updated

Slot with Anatoly

Bridal Show NJ

Official Kickoff

Bridal Show Manhattan

Writing on the Wall (Invite Only)

Meet the Brotherhood Grill Out

Warehouse Rush Party

Games Night

Josie's Night

Happy Hour

Alumni Panel

DEI Panel

Za With the Zetes

AI Hackathon

Ben + Victor Notion Demo

Time Trial Mile

Daddies Pizza

West Village Dinner Party

Public Event

Victor Pontis

test post

hi test

At Luma / Glow, we run most of our infrastructure on AWS. Our main services are a database on Aurora and a website and API running on ECS. 
While AWS does a good job of running these jobs, we've had a really hard time running cron jobs, data backfill tasks, and one-off scripts on AWS. That's where Airplane comes in. 
Airplane.dev Overview
Airplane is awesome because it gives you nice infrastructure around running your own code. 
We give Airplane our main backend Docker image and then every Airplane task calls that one Dockerfile with a different command. This is nice since I didn't have to learn anything special to use Airplane, I can use what we are already deploying to AWS. 
This did take some time to set up the first time since I was a very early Airplane customer. But it sounds like the onboarding has gotten a lot easier. 
Below is what our Airplane dashboard looks like:

I've redacted the task names, but you can think about them in a few different categories:
Support Scripts
Before Airplane, if we wanted to delete a user or add a flag, we would have to SSH into one of our production machines. This was really annoying in that it was error prone, we didn't have auditing, and it required an engineer with access to production. 
Airplane lets you run scripts from their dashboard. And the logging if f'ing incredible. You can always click into an old script and see who ran it, what the parameters were, and look at the logs. You even get an email / Slack if the task fails!
I really really love the built in logging. Managing scheduled tasks and one off scripts on AWS is a nightmare and I was planning on building a whole system around this until I found Airplane!

Here is what one of the task detail pages looks like. And if I click into any run I can see exactly what happened. It's incredible. 
Tip for Airplane — It would be sweet if I could define a result of the the task and then see it in this list. 
Cron Jobs
For Glow, we use this to periodically backfill data that changes on a daily basis. For Luma, we use this to send guest email reminders for events. 
Airplane has a pretty nice scheduler that lets you define the task either in Cron format or a more humane way. 

Backfilling Data 
For Glow, we are pulling in and processing a ton of data. While new data gets added by a service on AWS, Airplane gives us an incredible interface for running tasks to populate old data. 
Again this benefits from the increased logging I mentioned above. If we are backfilling in a few months of data, I can trigger a month at a time since Airplane makes it easy for me to see the status of previous jobs. 

Thank you to the Airplane team!

<div class="mirror-content">​At <a href="https://lu.ma/" target="_blank" rel="nofollow noopener">Luma</a> / <a href="https://glow.app/" target="_blank" rel="nofollow noopener">Glow</a>, we run <a href="https://lu.ma/p/zPamspcICt0f3q9/Lumas-Tech-Stack" target="_blank" rel="nofollow noopener">most of our infrastructure</a> on AWS. Our main services are a database on Aurora and a website and API running on ECS. ​While AWS does a good job of running these jobs, we&#x27;ve had a really hard time running cron jobs, data backfill tasks, and one-off scripts on AWS. That&#x27;s where Airplane comes in. <h1>​<a href="http://Airplane.dev" target="_blank" rel="nofollow noopener">Airplane.dev</a> Overview</h1>​Airplane is awesome because it gives you nice infrastructure around running your own code. ​We give Airplane our main backend Docker image and then every Airplane task calls that one Dockerfile with a different command. This is nice since I didn&#x27;t have to learn anything special to use Airplane, I can use what we are already deploying to AWS. ​This did take some time to set up the first time since I was a very early Airplane customer. But it sounds like the onboarding has gotten a lot easier. ​Below is what our Airplane dashboard looks like:<img alt="Image" class="image" src="https://cdn.lu.ma/cdn-cgi/image/format=auto,dpr=2,quality=85,width=800/editor-images/1f/f4a2bfc3-66c1-4a83-bf0c-309208bab949" style="display:block;max-width:100%;max-height:400px;margin:24px auto"/>​I&#x27;ve redacted the task names, but you can think about them in a few different categories:<h2>​Support Scripts</h2>​Before Airplane, if we wanted to delete a user or add a flag, we would have to SSH into one of our production machines. This was really annoying in that it was error prone, we didn&#x27;t have auditing, and it required an engineer with access to production. ​Airplane lets you run scripts from their dashboard. And the logging if f&#x27;ing incredible. You can always click into an old script and see who ran it, what the parameters were, and look at the logs. You even get an email / Slack if the task fails!​I really really love the built in logging. Managing scheduled tasks and one off scripts on AWS is a nightmare and I was planning on building a whole system around this until I found Airplane!<img alt="Image" class="image" src="https://cdn.lu.ma/cdn-cgi/image/format=auto,dpr=2,quality=85,width=460/editor-images/ot/4e5e11e2-21df-4d42-8b53-52825e44bd0c" style="display:block;max-width:100%;max-height:100%;margin:24px auto"/>​Here is what one of the task detail pages looks like. And if I click into any run I can see exactly what happened. It&#x27;s incredible. ​Tip for Airplane — It would be sweet if I could define a result of the the task and then see it in this list. <h2>​Cron Jobs</h2>​For Glow, we use this to periodically backfill data that changes on a daily basis. For Luma, we use this to send guest email reminders for events. ​Airplane has a pretty nice scheduler that lets you define the task either in Cron format or a more humane way. <img alt="Image" class="image" src="https://cdn.lu.ma/cdn-cgi/image/format=auto,dpr=2,quality=85,width=800/editor-images/ie/72982485-6336-4b20-aba2-a8964f8bc535" style="display:block;max-width:100%;max-height:400px;margin:24px auto"/><h2>​Backfilling Data </h2>​For Glow, we are pulling in and processing a ton of data. While new data gets added by a service on AWS, Airplane gives us an incredible interface for running tasks to populate old data. ​Again this benefits from the increased logging I mentioned above. If we are backfilling in a few months of data, I can trigger a month at a time since Airplane makes it easy for me to see the status of previous jobs. ​​Thank you to the Airplane team!</div>

 on AWS. Our main services are a database on Aurora and a website and API running on ECS. 

While AWS does a good job of running these jobs, we've had a really hard time running cron jobs, data backfill tasks, and one-off scripts on AWS. That's where Airplane comes in. 

Airplane is awesome because it gives you nice infrastructure around running your own code. 

We give Airplane our main backend Docker image and then every Airplane task calls that one Dockerfile with a different command. This is nice since I didn't have to learn anything special to use Airplane, I can use what we are already deploying to AWS. 

This did take some time to set up the first time since I was a very early Airplane customer. But it sounds like the onboarding has gotten a lot easier. 

Below is what our Airplane dashboard looks like:

I've redacted the task names, but you can think about them in a few different categories:

Before Airplane, if we wanted to delete a user or add a flag, we would have to SSH into one of our production machines. This was really annoying in that it was error prone, we didn't have auditing, and it required an engineer with access to production. 

Airplane lets you run scripts from their dashboard. And the logging if f'ing incredible. You can always click into an old script and see who ran it, what the parameters were, and look at the logs. You even get an email / Slack if the task fails!

I really really love the built in logging. Managing scheduled tasks and one off scripts on AWS is a nightmare and I was planning on building a whole system around this until I found Airplane!

Here is what one of the task detail pages looks like. And if I click into any run I can see exactly what happened. It's incredible. 

Tip for Airplane — It would be sweet if I could define a 

of the the task and then see it in this list. 

For Glow, we use this to periodically backfill data that changes on a daily basis. For Luma, we use this to send guest email reminders for events. 

Airplane has a pretty nice scheduler that lets you define the task either in Cron format or a more humane way. 

For Glow, we are pulling in and processing a ton of data. While new data gets added by a service on AWS, Airplane gives us an incredible interface for running tasks to populate old data. 

Again this benefits from the increased logging I mentioned above. If we are backfilling in a few months of data, I can trigger a month at a time since Airplane makes it easy for me to see the status of previous jobs. 

How we use Airplane to simplify our tech infrastructure

Current Issues
The current NFT spec is pretty bad for a few reasons:
every NFT requires multiple accounts (3+)
the token account address can change (and the token account is not always the associated token account of the current NFT owner)
the NFT holder can transfer the NFT to a diff token account which can make any existing escrow / marketplace accounts invalid
it’s hard to get all of the NFTs for a given wallet
the editions part of the spec is very confusing
it’s hard to group collections — not built into the original version of the spec and slow to query
it’s really hard to get all of the activity (transfers / etc) for one NFT since one tx may include the mint while another tx includes the token account
This all stems from the first problem — an NFT is a bunch of different accounts but it should really be just one account.
A Path Forwards
NFToken + One Account
In this new spec, we will have an NFToken program that we will use instead of the Tokenkeg program.
An NFT will be represented by an account that is a PDA of the NFToken program and it will have the following fields:
address — the ID of the NFT will be it’s address on the Solana blockchain
data — the rest of the fields will be stored in the dataholder — address (notice how I didn’t call this owner)
delegate — has ability to transfer the NFT to someone else
metadata_url — max 128 characters, you will want to use short URLs. the URL will store offchain metadata‚ spec https://docs.opensea.io/docs/metadata-standards
name — max 32 utf-8 characters
image_url — max 128 characters, name and image_url are nice to have on chain since this is the basics of what’s required for most NFTs
collection — points to the address of the collection (explained below)
creator / update_authority — the account used to sign the message to mint this NFT
Common Queries
Get All NFTs for a Wallet
getProgramAccountsprogram = NftToken
memcmp: holder = wallet
Transfer NFT
NFToken will have a transfer instruction that can be signed by either the holder or the delegate. After the transfer ix, the delegate is zero’d out.
Set Delegate
The holder can sign an instruction to set the delegate of the NFT.
Mint New NFT as Creator
To create a new NFT, you will call the mint instruction on the NFToken program and you pass in all of the data for the newly created NFT.
Update NFT
The update_authority has permissions to update the following fields:
name
image_url
metadata_url
Marketplace Actions
List NFT
To list an NFT, you will:
update the NFT delegate to the marketplace custody account
create a listing account that represents the sale information
An NFT will still show up in your wallet while it is listed on the NFT marketplace.
Update Listing
To update a listing, you update the listing account on the NFT marketplace. You don’t need to interact with NFToken
Cancel Listing
You can delete the listing account which should zero out the delegate field.
You can also zero out the delegate field yourself without getting permission from the NFT marketplace. They would have to update the listing account on their side and delete it.
Execute Sale
The delegate which is controlled by the marketplace can transfer the holder field after which the delegate field is zerod out.
So the NFT marketplace will make the transfer after seeing that a sale is executable.
Collections
We want to support collections from the inception of this protocol. While we support collections, not every NFT needs to be on a collection.
The NFToken program will also create PDAs that represent collections:
address — this is the ID of the collection
dataname — 32 characters
image_url — 32 characters
metadata_url — 128 characters
update_authority
Update Collection
The update_authority can update the name and metadata_url for the collection
Add NFT to Collection
To add an NFT, we will need signatures from the NFT update_authority and the collection update_authority.
Remove NFT from Collection
The collection update_authority can remove an NFT from its collection. This does not require permission from the NFT update_authority.
Further Work
If you're interested in pushing this spec forwards, @-me on Twitter.

<div class="mirror-content"><h2>​Current Issues</h2>​The current NFT spec is pretty bad for a few reasons:<ul><li>​every NFT requires multiple accounts (3+)</li><li>​the token account address can change (and the token account is not always the associated token account of the current NFT owner)</li><li>​the NFT holder can transfer the NFT to a diff token account which can make any existing escrow / marketplace accounts invalid</li><li>​it’s hard to get all of the NFTs for a given wallet</li><li>​the editions part of the spec is very confusing</li><li>​it’s hard to group collections — not built into the original version of the spec and slow to query</li><li>​it’s really hard to get all of the activity (transfers / etc) for one NFT since one tx may include the mint while another tx includes the token account</li></ul>​This all stems from the first problem — an NFT is a bunch of different accounts but it should really be just one account.<h1>​A Path Forwards</h1><h2>​<code>NFToken</code> + One Account</h2>​In this new spec, we will have an <code>NFToken</code> program that we will use instead of the <code>Tokenkeg</code> program.​An NFT will be represented by an account that is a PDA of the <code>NFToken</code> program and it will have the following fields:<ul><li>​<code>address</code> — the ID of the NFT will be it’s address on the Solana blockchain</li><li>​<code>data</code> — the rest of the fields will be stored in the data<ul><li>​<code>holder</code> — address (notice how I didn’t call this <code>owner</code>)</li><li>​<code>delegate</code> — has ability to transfer the NFT to someone else</li><li>​<code>metadata_url</code> — max 128 characters, you will want to use short URLs. the URL will store offchain metadata‚ spec <a href="https://docs.opensea.io/docs/metadata-standards" target="_blank" rel="nofollow noopener">https://docs.opensea.io/docs/metadata-standards</a></li><li>​<code>name</code> — max 32 utf-8 characters</li><li>​<code>image_url</code> — max 128 characters, <code>name</code> and <code>image_url</code> are nice to have on chain since this is the basics of what’s required for most NFTs</li><li>​<code>collection</code> — points to the address of the collection (explained below)</li><li>​<code>creator</code> / <code>update_authority</code> — the account used to sign the message to mint this NFT</li></ul></li></ul><h2>​Common Queries</h2>​Get All NFTs for a Wallet<ul><li>​<code>getProgramAccounts</code><ul><li>​<code>program = NftToken</code></li><li>​<code>memcmp: holder = wallet</code></li></ul></li></ul>​Transfer NFT​<code>NFToken</code> will have a transfer instruction that can be signed by either the <code>holder</code> or the <code>delegate</code>. After the transfer ix, the <code>delegate</code> is zero’d out.​Set Delegate​The <code>holder</code> can sign an instruction to set the <code>delegate</code> of the NFT.​Mint New NFT as Creator​To create a new NFT, you will call the <code>mint</code> instruction on the <code>NFToken</code> program and you pass in all of the data for the newly created NFT.​Update NFT​The <code>update_authority</code> has permissions to update the following fields:<ul><li>​<code>name</code></li><li>​<code>image_url</code></li><li>​<code>metadata_url</code></li></ul><h2>​Marketplace Actions</h2>​List NFT​To list an NFT, you will:<ul><li>​update the NFT <code>delegate</code> to the marketplace custody account</li><li>​create a <code>listing</code> account that represents the sale information</li></ul>​An NFT will still show up in your wallet while it is listed on the NFT marketplace.​Update Listing​To update a listing, you update the <code>listing</code> account on the NFT marketplace. You don’t need to interact with <code>NFToken</code>​Cancel Listing​You can delete the <code>listing</code> account which should zero out the <code>delegate</code> field.​You can also zero out the <code>delegate</code> field yourself without getting permission from the NFT marketplace. They would have to update the <code>listing</code> account on their side and delete it.​Execute Sale​The <code>delegate</code> which is controlled by the marketplace can <code>transfer</code> the <code>holder</code> field after which the <code>delegate</code> field is zerod out.​So the NFT marketplace will make the transfer after seeing that a sale is executable.<h2>​Collections</h2>​We want to support collections from the inception of this protocol. While we support collections, not every NFT needs to be on a collection.​The <code>NFToken</code> program will also create PDAs that represent collections:<ul><li>​<code>address</code> — this is the ID of the collection</li><li>​<code>data</code><ul><li>​<code>name</code> — 32 characters</li><li>​<code>image_url</code> — 32 characters</li><li>​<code>metadata_url</code> — 128 characters</li><li>​<code>update_authority</code></li></ul></li></ul>​Update Collection​The <code>update_authority</code> can update the <code>name</code> and <code>metadata_url</code> for the collection​Add NFT to Collection​To add an NFT, we will need signatures from the NFT <code>update_authority</code> and the collection <code>update_authority</code>.​Remove NFT from Collection​The collection <code>update_authority</code> can remove an NFT from its collection. This does not require permission from the NFT <code>update_authority</code>.<h2>​Further Work</h2>​If you&#x27;re interested in pushing this spec forwards, @-me <a href="https://twitter.com/victorpontis" target="_blank" rel="nofollow noopener">on Twitter</a>.</div>

The current NFT spec is pretty bad for a few reasons:

This all stems from the first problem — an NFT is a bunch of different accounts but it should really be just one account.

 program that we will use instead of the 

An NFT will be represented by an account that is a PDA of the 

 program and it will have the following fields:

 will have a transfer instruction that can be signed by either the 

 program and you pass in all of the data for the newly created NFT.

 has permissions to update the following fields:

An NFT will still show up in your wallet while it is listed on the NFT marketplace.

 account on the NFT marketplace. You don’t need to interact with 

 field yourself without getting permission from the NFT marketplace. They would have to update the 

 which is controlled by the marketplace can 

So the NFT marketplace will make the transfer after seeing that a sale is executable.

We want to support collections from the inception of this protocol. While we support collections, not every NFT needs to be on a collection.

 program will also create PDAs that represent collections:

To add an NFT, we will need signatures from the NFT 

 can remove an NFT from its collection. This does not require permission from the NFT 

If you're interested in pushing this spec forwards, @-me 

Proposal: New Solana NFT Spec

Solana often takes a while for people to wrap their heads around. I find this happens for a few reasons:
While there is some good content, it's scattered across many websites and blogs.
Solana is often explained in relation to Ethereum. But you don't need to understand Ethereum to understand Solana. This just confuses things.
There are some concepts in Solana (like the NFT token model) which are more complicated than they need to be.
As with everything in crypto, the majority of explainers are non-technical that use hard to understand metaphors.
Solana is a Key / Value Database
I've spent a few months banging my head at this and I think I have a mental model that makes sense now...
Solana is a huge key  value data database. Each Solana node stores this key  value database in memory (and is why nodes have to be so big).
In Solana nomenclature, the key is called an address and the value is called the account. Each address points to an account where data is stored.
And everything on Solana is an address / account pair. For example, each program has an address and stores the code for the program at the associated account. (It's actually a bit more complex than this but we don't need to get into that...)

Regular Accounts and Storage Accounts
Now let’s talk about addresses. On Solana an address is a 256 bit number that is most often encoded with base58, so it looks something like this CXk5NCtYva7h4BcGXg5BDBDtZDwgBuWZcwmWt5ReY1yA.
There are two different types of accounts — let’s call them Regular accounts and Storage accounts.

Regular Accounts
Regular accounts are what you think of when you think of crypto addresses.
Bitcoin, Ethereum, and Solana all use Elliptic Curve cryptography which allows a public  private keypair to sign messages. If you have a public  private keypair, you can sign a message with your private key and other people can verify the message is signed correctly.
This public / private keypair mechanism allows wallets to sign transactions that authorize some action. The Bitcoin code won’t execute a transaction that sends Bitcoin unless that account has signed the transaction.
On Solana, the regular account corresponds to the public key. You hold the private key securely in your wallet and you can share your public key.
In this system, a public key is a 256 bit number which lies on an elliptic curve. So a valid Solana Regular Account is one which lies on the elliptic curve.
Regular accounts are used for a couple things:
Wallets — If you want to have an account that stores SOL, you will create a regular account. SOL is stored directly in your wallet. (Tokens / NFTs are stored on Storage Accounts associated with your wallet.)
Programs — Every program is a regular account. It stores data in the account that is executed when the program is called.

Storage Accounts (PDAs)
Storage accounts allow you to store data associated with programs. A program can do anything from storing the state of an NFT listing, allowing an escrow between two parties, to acting as a domain registry.
You know an account is a storage account because its address is not on the elliptic curve that we mentioned above. That means a storage account address is not part of a public / private keypair, it’s just a number.
Regular accounts can sign messages with their private key to authorize transactions. Storage accounts can’t do this since they don’t have a private key. Instead storage accounts are linked to a controller program.
So if you are creating a program that will take a poll of where everyone wants to go on vacation, that program will store information about the different vacation destinations and votes at storage programs that are linked to the program.

How NFTs Work
If you ask me, the NFT spec in Solana is as complicated as possible (and I really want to rewrite it...). You can’t actually understand the NFT spec without understanding the coin spec.
A coin (aka a token) on Solana has a few characteristics:
An ID — This is called the Mint and is stored at the Mint account. The Mint account is a Storage Account that is controlled by the Solana Token Program.
Metadata — Name, symbol, price, etc. This information is stored in accounts on chain and places off chain.
Total Supply — Let’s say there are 1 million VIC coin. This VIC could be stored on one account or spread out across a bunch of different accounts. Each account stores a certain number of VIC and points to the owner. So I could have multiple accounts that store VIC. My overall balance is the sum of the VIC in these accounts.
Now that we understand how coins work, we turn to NFTs. An NFT is just a coin with a supply of 1. So each NFT has the following accounts (which are all Storage Accounts):
Mint — This is the ID of the NFT and stores some basic metadata.
Metadata — This has even more Metadata about the NFT. For historical reasons, it’s another storage account...
Token — This stores who owns the NFT. This can be super confusing since the address of the token account can change over time.
So if you own an NFT, what that means is the Token account for the NFT says that you are the owner.

<div class="mirror-content">​Solana often takes a while for people to wrap their heads around. I find this happens for a few reasons:<ul><li>​While there is some good content, it&#x27;s scattered across many websites and blogs.</li><li>​Solana is often explained in relation to Ethereum. But you don&#x27;t need to understand Ethereum to understand Solana. This just confuses things.</li><li>​There are some concepts in Solana (like the NFT token model) which are more complicated than they need to be.</li><li>​As with everything in crypto, the majority of explainers are non-technical that use hard to understand metaphors.</li></ul><h1>​Solana is a Key / Value Database</h1>​I&#x27;ve spent a few months banging my head at this and I think I have a mental model that makes sense now...​Solana is a huge key value data database. Each Solana node stores this key value database in memory (and is why nodes have to be so big).​In Solana nomenclature, the key is called an address and the value is called the account. Each address points to an account where data is stored.​And everything on Solana is an address / account pair. For example, each program has an address and stores the code for the program at the associated account. (It&#x27;s actually a <a href="https://www.notion.so/Program-deploys-29780c48794c47308d5f138074dd9838" target="_blank" rel="nofollow noopener">bit more complex than this</a> but we don&#x27;t need to get into that...)​<h1>​Regular Accounts and Storage Accounts</h1>​Now let’s talk about addresses. On Solana an address is a 256 bit number that is most often encoded with base58, so it looks something like this <code>CXk5NCtYva7h4BcGXg5BDBDtZDwgBuWZcwmWt5ReY1yA</code>.​There are two different types of accounts — let’s call them Regular accounts and Storage accounts.​<h2>​Regular Accounts</h2>​Regular accounts are what you think of when you think of crypto addresses.​Bitcoin, Ethereum, and Solana all use Elliptic Curve cryptography which allows a public private keypair to sign messages. If you have a public private keypair, you can sign a message with your private key and other people can verify the message is signed correctly.​This public / private keypair mechanism allows wallets to sign transactions that authorize some action. The Bitcoin code won’t execute a transaction that sends Bitcoin unless that account has signed the transaction.​On Solana, the regular account corresponds to the public key. You hold the private key securely in your wallet and you can share your public key.​In this system, a public key is a 256 bit number which lies <a href="https://www.youtube.com/watch?v=NF1pwjL9-DE&amp;ab_channel=Computerphile" target="_blank" rel="nofollow noopener">on an elliptic curve</a>. So a valid Solana Regular Account is one which lies on the elliptic curve.​Regular accounts are used for a couple things:<ul><li>​Wallets — If you want to have an account that stores SOL, you will create a regular account. SOL is stored directly in your wallet. (Tokens / NFTs are stored on Storage Accounts associated with your wallet.)</li><li>​Programs — Every program is a regular account. It stores data in the account that is executed when the program is called.</li></ul>​<h2>​Storage Accounts (PDAs)</h2>​Storage accounts allow you to store data associated with programs. A program can do anything from storing the state of an NFT listing, allowing an escrow between two parties, to acting as a domain registry.​You know an account is a storage account because its address is not on the elliptic curve that we mentioned above. That means a storage account address is not part of a public / private keypair, it’s just a number.​Regular accounts can sign messages with their private key to authorize transactions. Storage accounts can’t do this since they don’t have a private key. Instead storage accounts are linked to a controller program.​So if you are creating a program that will take a poll of where everyone wants to go on vacation, that program will store information about the different vacation destinations and votes at storage programs that are linked to the program.​<h2>​How NFTs Work</h2>​If you ask me, the NFT spec in Solana is as complicated as possible (and I really want to rewrite it...). You can’t actually understand the NFT spec without understanding the coin spec.​A coin (aka a <a href="https://spl.solana.com/token" target="_blank" rel="nofollow noopener">token</a>) on Solana has a few characteristics:<ul><li>​An ID — This is called the Mint and is stored at the Mint account. The Mint account is a Storage Account that is controlled by the Solana Token Program.</li><li>​Metadata — Name, symbol, price, etc. This information is stored in accounts on chain and places off chain.</li><li>​Total Supply — Let’s say there are 1 million VIC coin. This VIC could be stored on one account or spread out across a bunch of different accounts. Each account stores a certain number of VIC and points to the owner. So I could have multiple accounts that store VIC. My overall balance is the sum of the VIC in these accounts.</li></ul>​Now that we understand how coins work, we turn to NFTs. An NFT is just a coin with a supply of 1. So each NFT has the following accounts (which are all Storage Accounts):<ul><li>​Mint — This is the ID of the NFT and stores some basic metadata.</li><li>​Metadata — This has even more Metadata about the NFT. For historical reasons, it’s another storage account...</li><li>​Token — This stores who owns the NFT. This can be super confusing since the address of the token account can change over time.</li></ul>​So if you own an NFT, what that means is the Token account for the NFT says that you are the owner.</div>

Solana often takes a while for people to wrap their heads around. I find this happens for a few reasons:

I've spent a few months banging my head at this and I think I have a mental model that makes sense now...

 value data database. Each Solana node stores this key 

 value database in memory (and is why nodes have to be so big).

In Solana nomenclature, the key is called an address and the value is called the account. Each address points to an account where data is stored.

And everything on Solana is an address / account pair.

 For example, each program has an address and stores the code for the program at the associated account. (It's actually a 

Now let’s talk about addresses. On Solana an address is a 256 bit number that is most often encoded with base58, so it looks something like this 

CXk5NCtYva7h4BcGXg5BDBDtZDwgBuWZcwmWt5ReY1yA

There are two different types of accounts — let’s call them Regular accounts and Storage accounts.

Regular accounts are what you think of when you think of crypto addresses.

Bitcoin, Ethereum, and Solana all use Elliptic Curve cryptography which allows a public 

 private keypair to sign messages. If you have a public 

 private keypair, you can sign a message with your private key and other people can verify the message is signed correctly.

This public / private keypair mechanism allows wallets to sign transactions that authorize some action. The Bitcoin code won’t execute a transaction that sends Bitcoin 

 that account has signed the transaction.

On Solana, the regular account corresponds to the public key. You hold the private key securely in your wallet and you can share your public key.

In this system, a public key is a 256 bit number which lies 

. So a valid Solana Regular Account is one which lies on the elliptic curve.

Regular accounts are used for a couple things:

Storage accounts allow you to store data associated with programs. A program can do anything from storing the state of an NFT listing, allowing an escrow between two parties, to acting as a domain registry.

You know an account is a storage account because its address is not on the elliptic curve that we mentioned above. That means a storage account address is not part of a public / private keypair, it’s just a number.

Regular accounts can sign messages with their private key to authorize transactions. Storage accounts can’t do this since they don’t have a private key. Instead storage accounts are linked to a controller program.

So if you are creating a program that will take a poll of where everyone wants to go on vacation, that program will store information about the different vacation destinations and votes at storage programs that are linked to the program.

If you ask me, the NFT spec in Solana is as complicated as possible (and I really want to rewrite it...). You can’t actually understand the NFT spec without understanding the coin spec.

Now that we understand how coins work, we turn to NFTs. An NFT is just a coin with a supply of 1. So each NFT has the following accounts (which are all Storage Accounts):

So if you own an NFT, what that means is the Token account for the NFT says that you are the owner.

The Solana Programming Model

Ethereum is Hard
On Ethereum, it's incredibly difficult to figure out what NFTs someone owns.
Each Ethereum NFT is linked to a smart contract that minted the NFT. But since every NFT collection deploys their own smart contract, there are millions (?) of smart contracts that you need to scan over and check. 
When implementing token gated events for Luma, we used the Opensea's API to query for the NFTs that an address owns. Opensea has already done the hard work for us by scanning over all of Ethereum's contracts and blocks. 
But this kinda sucks, doesn't it? The blockchain is supposed to be a decentralized database and we just ended up querying a centralized provider...
Solana is Different
On Solana, we store data across the blockchain in key / value pairs. The terminology is kind of confusing, but each key / value pair is called an account. And everything is an account... But let's not get too sidetracked. 
When you mint a Solana NFT, you have a few different accounts involved in the transaction:
your Wallet
the Solana Token Program — This is part of the Solana Program Library (the standard library for Solana) and is the program we are running to mint the NFT.
the Mint account — This account serves as the ID of the NFT and it owns the metadata about the NFT.
the Associated Token Account — This is generated by combining your Wallet address with the Mint. As a consequence, you will have at most one Associated Token Account for each type of token. 
The last account is the most interesting. That's where we will store that you own the NFT. 
So if wanted to check if wallet WALRUS owns an NFT with the mint PUNK, we would look up the Associated Token Account by combining WALRUS and PUNK with a special function, let's say that outputs WALPUNK. Then we would read the data in WALPUNK to see if WALRUS owns PUNK. 
Now we are at parity with Ethereum. Given an NFT and a wallet, we can see who owns it. But we can do so much more...
On Solana, each validator node stores the full state of the system. This state is stored in what Solana calls the Accounts DB. The Accounts DB lets us do queries that would be impossible on Ethereum. 
In this case, we can easily go from a Wallet address to a list of all of the Associated Token Programs associated with that Wallet. 
Tada! On Solana, we can quickly find all the NFTs (and other tokens) that someone owns. And we don't have to rely on a centralized service like Opensea. 

Appendix: Diving into the Technical Details
This covers how we go from a Wallet address to all of the Associated Token Accounts associated with the Wallet. From those accounts, it's relatively straightforward to find information on the NFTs someone owns (although, I can write about that if people are interested...). 
web3
Using Solana's web3 library, you call getParsedTokenAccountsByOwner.
This makes a getTokenAccountsByOwner  RPC request to the URL that you specified when creating the collection. 
Solana Runtime
This request gets processed by a node running the Solana Runtime. The runtime interprets the request and calls a Rust function get_token_accounts_by_owner. This in turn calls several functions: 
get_token_accounts_by_owner
get_filtered_spl_token_accounts_by_owner
get_filtered_indexed_accounts
accounts.load_by_index_key_with_filter
accounts_db.index_scan_accounts
accounts_index.index_scan_accounts
That last step is interesting! That's the Accounts DB that we mentioned above. Each node running Solana keeps the full Account DB in memory which makes it easy to query and find data. 

OK, so I'm sure that a lot of that went over your head. A lot of it is still pretty confusing to me and I'm sure that I'm getting some of the details wrong. So if you have questions, ping me on Twitter!
And if you want to build dope, meaningful stuff on top of Solana, join us!

<div class="mirror-content" data-reactroot=""><h1>​Ethereum is Hard</h1>​On Ethereum, it&#x27;s incredibly difficult to figure out what NFTs someone owns.​Each Ethereum NFT is <a href="https://eips.ethereum.org/EIPS/eip-721" target="_blank" rel="nofollow noopener">linked to a smart contract</a> that minted the NFT. But since every NFT collection deploys their own smart contract, there are millions (?) of smart contracts that you need to scan over and check. ​When implementing <a href="https://lu.ma/crypto" target="_blank" rel="nofollow noopener">token gated events</a> for Luma, we used the <a href="https://docs.opensea.io/reference/api-overview" target="_blank" rel="nofollow noopener">Opensea&#x27;s API</a> to query for the NFTs that an address owns. Opensea has already done the hard work for us by scanning over all of Ethereum&#x27;s contracts and blocks. ​But this kinda sucks, doesn&#x27;t it? The blockchain is supposed to be a decentralized database and we just ended up querying a centralized provider...<h1>​Solana is Different</h1>​On Solana, we store data across the blockchain in key / value pairs. The terminology is kind of confusing, but each key / value pair is called an account. And everything is an account... But let&#x27;s not get too sidetracked. ​When you mint a Solana NFT, you have a few different accounts involved in the transaction:<ul><li>​your Wallet</li><li>​the <a href="https://spl.solana.com/token" target="_blank" rel="nofollow noopener">Solana Token Program</a> — This is part of the Solana Program Library (the standard library for Solana) and is the program we are running to mint the NFT.</li><li>​the Mint account — This account serves as the ID of the NFT and it owns the metadata about the NFT.</li><li>​the <a href="https://spl.solana.com/associated-token-account" target="_blank" rel="nofollow noopener">Associated Token Account</a> — This is generated by combining your Wallet address with the Mint. As a consequence, you will have at most one Associated Token Account for each type of token. </li></ul>​The last account is the most interesting. That&#x27;s where we will store that you own the NFT. ​So if wanted to check if wallet <code>WALRUS</code> owns an NFT with the mint <code>PUNK</code>, we would look up the Associated Token Account by combining <code>WALRUS</code> and <code>PUNK</code> with a special function, let&#x27;s say that outputs <code>WALPUNK</code>. Then we would read the data in <code>WALPUNK</code> to see if <code>WALRUS</code> owns <code>PUNK</code>. ​Now we are at parity with Ethereum. Given an NFT and a wallet, we can see who owns it. But we can do so much more...​On Solana, each validator node stores the full state of the system. This state is stored in what Solana calls the Accounts DB. The Accounts DB lets us do queries that would be impossible on Ethereum. ​In this case, we can easily go from a Wallet address to a list of all of the Associated Token Programs associated with that Wallet. ​Tada! On Solana, we can quickly find all the NFTs (and other tokens) that someone owns. And we don&#x27;t have to rely on a centralized service like Opensea. <hr/><h1>​Appendix: Diving into the Technical Details</h1>​This covers how we go from a Wallet address to all of the Associated Token Accounts associated with the Wallet. From those accounts, it&#x27;s relatively straightforward to find information on the NFTs someone owns (although, I can write about that if people are interested...). <h2>​web3</h2>​Using Solana&#x27;s web3 library, you call <a href="https://github.com/solana-labs/solana-web3.js/blob/10548b82e08ba865c36e2d86974fe15bce3fc566/src/connection.ts#L2333" target="_blank" rel="nofollow noopener">getParsedTokenAccountsByOwner</a>.​This makes a <code>getTokenAccountsByOwner</code> RPC request to the URL that you specified when creating the collection. <h2>​Solana Runtime</h2>​This request gets processed by a node running the Solana Runtime. The runtime interprets the request and calls a <a href="https://github.com/solana-labs/solana/blob/807263596748508056ccfef6be31527661387f03/rpc/src/rpc.rs#L1685" target="_blank" rel="nofollow noopener">Rust function</a> <code>get_token_accounts_by_owner</code>. This in turn calls several functions: <ol><li>​<code>get_token_accounts_by_owner</code></li><li>​<code>get_filtered_spl_token_accounts_by_owner</code></li><li>​<code>get_filtered_indexed_accounts</code></li><li>​<code>accounts.load_by_index_key_with_filter</code></li><li>​<code>accounts_db.index_scan_accounts</code></li><li>​<code>accounts_index.index_scan_accounts</code></li></ol>​That last step is interesting! That&#x27;s the Accounts DB that we mentioned above. Each node running Solana keeps the full Account DB in memory which makes it easy to query and find data. ​​OK, so I&#x27;m sure that a lot of that went over your head. A lot of it is still pretty confusing to me and I&#x27;m sure that I&#x27;m getting some of the details wrong. So if you have questions, <a href="https://twitter.com/VictorPontis" target="_blank" rel="nofollow noopener">ping me on Twitter</a>!​And if you want to build dope, meaningful stuff on top of Solana, join us!​​<img alt="Image" class="image" src="https://cdn.lu.ma/cdn-cgi/image/format=auto,dpr=2,quality=85,width=800/editor-images/km/c1f088f8-fb45-4ed7-8963-5d110b2a10e1" style="display:block;max-width:100%;max-height:400px;margin:24px auto"/></div>

On Ethereum, it's incredibly difficult to figure out what NFTs someone owns.

 the NFT. But since every NFT collection deploys their own smart contract, there are millions (?) of smart contracts that you need to scan over and check. 

 to query for the NFTs that an address owns. Opensea has already done the hard work for us by scanning over all of Ethereum's contracts and blocks. 

But this kinda sucks, doesn't it? The blockchain is supposed to be a decentralized database and we just ended up querying a centralized provider...

On Solana, we store data across the blockchain in key / value pairs. The terminology is kind of confusing, but each key / value pair is called an account. And everything is an account... But let's not get too sidetracked. 

When you mint a Solana NFT, you have a few different accounts involved in the transaction:

The last account is the most interesting. That's where we will store that you own the NFT. 

 with a special function, let's say that outputs 

Now we are at parity with Ethereum. Given an NFT and a wallet, we can see who owns it. But we can do so much more...

On Solana, each validator node stores the full state of the system. This state is stored in what Solana calls the Accounts DB. The Accounts DB lets us do queries that would be impossible on Ethereum. 

In this case, we can easily go from a Wallet address to a list of all of the Associated Token Programs associated with that Wallet. 

Tada! On Solana, we can quickly find all the NFTs (and other tokens) that someone owns. And we don't have to rely on a centralized service like Opensea. 

Appendix: Diving into the Technical Details