GrinCode is a decentralized service for generating, exchanging, and trading unique codes that are backed by balances of the Grin cryptocurrency.
Analogy: similar to WEX or BTC-E codes, but designed with real decentralization and privacy in mind, staying true to Grin’s philosophy.
How GrinCode works
Code Generation
A user sends Grin to a special self-hosted wallet/contract or handles it locally through their own wallet.
A unique GrinCode is generated — a string containing the balance information and a validity signature.
The code can be used once to claim the funds.
Code Verification
Using a local wallet or a lightweight client, a user can verify the code’s validity (whether it exists, whether it’s already redeemed, and the amount attached).
Code Redemption
You input the code into a GrinCode wallet — it instantly transfers the funds to your Grin address via an atomic transaction.
Code Trading
Peer-to-peer marketplace: users can list codes for sale for other cryptocurrencies or fiat.
The marketplace operates with an escrow system, without a single point of failure.
Features
Decentralization: no central server — only a peer-to-peer network sharing codes and metadata.
Anonymity: no registration needed; codes can be transferred through messengers, forums, etc.
Security: each code is signed with a private key, allowing easy authenticity verification.
Easy Integration: API available for integration into exchanges, online stores, and other services.
Use Cases
Forum-based trading — a safe alternative to direct transfers.
Gift Codes — for promotions or bonuses.
Anonymous Transfers — no direct blockchain link between sender and receiver.
Technical Details
Code generation: the code contains a hash identifier, amount, timestamp, and signature.
Code storage: either on IPFS or locally by the code owners.
Code verification and redemption: via a lightweight client directly checking against the Grin blockchain (or through trusted nodes).
good idea.
Just selling for other cryptocurrencies or fiat,exchange? it is a shopping platform?
I have always wanted to sell products made in China,then get Grin as Medium of Exchange
But there are issues with third-party payment and after-sales guarantee
It would be great if we could also sell physical object products.
it rather meant that the coins would flow directly to the platform. if there are any quick transfers, they could be implemented. The entire text that is written above is a concept that is not yet related to the actual capabilities of grin.
no,I think it is more like crypto exchange like uniswap,gate.io etc.not like trading/shopping platform,which is like amazon,TEMU,Ali express,Ulbricht`s Silk Road~~
I think nothing should happen to them while the platform is functioning.
naturally, there are risks, and they will increase if grin becomes popular and the turnover is significant. We need to think carefully about the decentralization mechanism before starting development and staying in the shadows.
hmm, yes but what if the service goes down - would there be a failsafe so the voucher sender (creator) could perhaps get their coins back? perhaps a TIMELOCK function (but I’m not sure if Grin supports, or can support these, although I think it could, right?) @tromp
The only implementation of grincodes that I can think of is equivalent to the blinding factor of an unspent output. That only has value to the extent that you trust others with knowledge of the blinding factor (such as the party that gave/sold you the grincode) not to spend the output. I.e. it amounts to a 1-of-n output.
@Alice What you describe the idea of Grin vouchers, which indeed in its essence is sharing the private key(s) to a wallet or output.
I though quite a bit about implementing this and worked on implementing a play solution in Python. There are two options on how implement vouchers but they all involve sharing private-key(s):
Implement a sweep function and make grin vouchers that are the seed to a wallet. This could even support SeedQR which is already implemented in Grim wallet and corrects for small damage and mistakes in QR codes. The advantage would be that you can swipe any existing wallet, including a voucher wallets and import the funds. The downside is that perhaps sharing a seed and a HD wallet is overkill and could create confusion. For example, when you would scan a seed QR the user needs to know that when scanning a voucher SeedQR, he should select swipe and not import|restore. So having vouchers that are complete wallets could be used as an attack vector to scam users, by tricking them to import or restore instead of swiping. Also SeedQR does not support adding any metadata.
Make a voucher contain a single private-key/blinding factor plus all relevant metadata.
This key should be distinguished and have a separate derivation path from your regular wallet account for safety and bookkeeping when you restore your wallet.
This limits the voucher to a single output, which avoids potential attacks such as sharing a voucher with dust outputs, and is more unambiguous, there is no confusion between vouchers and wallets.
I think the second option is the cleanest solution. It should not be just a private-key IMO, but a JSON that contains some metadata stating it is a voucher, optional message, and importantly it could reference which output the key is associated with and its value. The whole think can be represented as a simple QR code. So basically you give the receiver all information in needs to quickly build and broadcast a transaction to send the funds to its own wallet without the need to scan or even know the chain state . By including a wrapper of (meta-)data that included all information needed to spend the funds, the users can go from reading the QR code to broadcasting a transaction in milliseconds
It is important to always mention that voucher do not have any transaction proofs, so trading them would rely on a secure Escrow service, and would involve some risk.
the second method seems more convenient. it remains to be seen who has the desire to start development. to form a survey with the community about the need to create such a service. there is no point in creating if people have no interest. Unfortunately, I’m not a programmer.
I think it should start with a (Request for Comments) RFC. Using a wrapper is fine, but it requires good discussion to prepare for all potential use cases.
Perhaps I will start such a RFC, the idea of wrappers, also for transactions, has been floating around for years.
. By including a wrapper of (meta-)data that included all information needed to spend the funds, the users can go from reading the QR code to broadcasting a transaction in milliseconds 