Currently we are using Rinkeby tesnet, besides solving issue like synchronization, we need to interact with a mainnet blockchain.
Preferably, we remove completely the internal asset database, so that the platfrom get always the balances from blockchain.
In the mean time, we might migrate first the current solution, to reduce complexity, we should maybe not create for the moment a DAO for the space. A space which has a specific wallet shall just be able to create a specific Algorand Stanard Asset. Principal calls made through this module :
Following function have probably to be adapted:
POST /coin/mint when issuing new coins
POST /coin/transfer when transferring coins
GET /coin/balance to get a wallet balance
POST /wallet to create wallet(s)
GET /wallet to get a specific wallet details
Folliwing function might be skipped:
POST /coin/setTransferEventListener to set a listener for a specific coin
POST /dao to create a new dao
GET /dao to get a specific dao details
POST /space/addMembers to add member(s) to a specific space
POST /space/removeMember to remove a member from a specific space
POST /space/leave to leave space
POST /migrate/space to migrate an existing space before enabling ethereum
To avoid migration complexity, we should restart with a platform without any balances. We operate the old database version under an other subdomain, to ensure beeing able to manually adapt balances when needed.
Currently we are using Rinkeby tesnet, besides solving issue like synchronization, we need to interact with a mainnet blockchain.
Preferably, we remove completely the internal asset database, so that the platfrom get always the balances from blockchain.
In the mean time, we might migrate first the current solution, to reduce complexity, we should maybe not create for the moment a DAO for the space. A space which has a specific wallet shall just be able to create a specific Algorand Stanard Asset. Principal calls made through this module :
Following function have probably to be adapted:
Folliwing function might be skipped:
To avoid migration complexity, we should restart with a platform without any balances. We operate the old database version under an other subdomain, to ensure beeing able to manually adapt balances when needed.