- Create a postgres database
- Copy the
server
,ctl
binaries and the.env.example
file to a directory - Change the
POSTGRES_URI
variable in your.env
to point to the database - Change the
PORT
as needed - Change the
ADMIN_*
credentials to be used. Ideally, you should generate random ones - Change the
DEPTH
as needed. The maximum number of items can be calculated as2^DEPTH
. SoDEPTH
= 20 will allow you to have at most 1048576 items in your collection. This API will require changes to its code if you want to haveDEPTH
> 30 - Change the
DATA_DIR
as needed. A small number of.json
files will be stored there (1 constantly and 1 per each update) - Change
TONCENTER_URI
as needed. That means removingtestnet.
if you want to deploy your collection to mainnet cd
to the directory wherectl
and.env
are located- Create a file containing the addresses of owners of your items, one address per line. Empty lines will be ignored. The first one will get item index 0, and so on. We will assume that this file is named
owners.txt
and is located in the same directory - Run
./ctl migrate
. This will create the necessary tables in the database - Run
./ctl add owners.txt
. This will add the addresses to the database - Host your collection metadata and items' metadata with formats as outlined in Token Data Standard. The items' metadata files must all have a pattern of
some-common-uri-part + '/' + item-index + '.json'
. Other patterns are possible but will require changes to the API's code - Run
./server
in a way that prevents it from closing when your SSH (or any other kind of session) closes. You can do that using the screen utility for example. Make sure that the assignedPORT
is visible to the public Internet on some endpoint - Navigate to
api-uri + '/admin/rediscover'
. Use yourADMIN_*
credentials. If all went well, you should see the stringok
and a file should appear underDATA_DIR + '/upd/1.json'
(perhaps after some time if the number of items is large) - Run
./ctl genupd path-to-update-file collection-owner collection-meta item-meta-prefix royalty-base royalty-factor royalty-recipient api-uri-including-v1
wherepath-to-update-file
is the path to the file mentioned in step 15,collection-owner
is the intended collection owner,collection-meta
is the full URI to collection metadata file,item-meta-prefix
is the common item metadata file prefix (for example, if your item 0 has its metadata hosted athttps://example.com/0.json
, then you should usehttps://example.com/
here),royalty-base
is the royalty numerator,royalty-factor
is the royalty denominator (base = 1 and factor = 100 give 1% royalty),royalty-recipient
is the address which will get royalties (you can just use thecollection-owner
here), andapi-uri-including-v1
is the publicly visible API URI with the/v1
postfix (so if you usedhttps://example.com/admin/rediscover
to create the update file, you should puthttps://example.com/v1
here. Usinglocalhost
or similar here will not allow users to claim your items, but for testing purposes that's fine) - Invoke the
ton://
deeplink that appears - Navigate to
api-uri + '/admin/setaddr/' + collection-address
using the address that you saw after step 16 - Wait for a
commited state
message inserver
logs - Done
- Prepare a list of owners to be newly added as described in step 11 of the Setup section. If you previously added 100 owners, then these new owners will have items starting with index 100 and so on. We will assume that this file is named
new-owners.txt
and is located in the same directory as thectl
binary - Run
./ctl add new-owners.txt
- Navigate to
api-uri + '/admin/rediscover'
- Locate the newly created update file under
DATA_DIR + '/upd'
. If your latest applied update was update 1 (as after setup), then the newly created one will have the name2.json
- Run
./ctl genupd path-to-update-file collection-address
wherepath-to-update-file
is the path to the file mentioned in step 4, andcollection-address
is the address of the deployed collection - Invoke the
ton://
deeplink that appears - Wait for a
commited state
message inserver
logs - Done
NOTE: During the brief period when the onchain transaction to update the collection has happened, but the API has not detected it yet, all generated proofs will be invalid and therefore claim requests generated during this period will fail. Therefore, we do not recommend updating your collection under large traffic (or often). Instead, try updating your collection with large batches and when under little traffic.