RainCheck unites online shoppers with offline purchases, generating an on-demand shopping experience.
RainCheck aims to deliver solutions on the online shopping problem; majority of people are now browsing products online, but only few close the purchase.
Co-Founder and CEO Cameron Wall says, ‘We found that there was a lot of people obviously saving items into their list. I think the average basket size from online was about just over a hundred dollars but the average basket size in store was probably 2.5 times the size of that.’
With 90 percent of people researching new products online, 90 percent of purchases continue to take place in offline in-store.
The company has built, designed and launched its RainCheck app which facilitates people to use their mobile device to choose a brand, save preferred items in a shopping cart to a ‘wishlist’, where users then receive notifications when a product is available in nearby stores.
Cameron Wall states, ‘Raincheck is transcending online to offline so it’s a layer that plays that whole ecosystem.’
As we are living in an online world, people are taking on a multichannel approach when shopping, hence much more focus should be pointed to transforming the online shopping to in-store purchasing.
‘I think there’s a big opportunity for everyone’s discovering things online. But let’s try and work out what store they went into when they went there whether we converted them and if they actually bought the item. I think that’s more important for brands to understand that’, says Cameron Wall.
Digital devices have a significant influence on in-store sales according to GeoMarketing, Mobile phones will influence $1.4 trillion in offline sales within the next 5 years.
The sales that Mobile influenced in 2016 account for over one-third of total retail in online and offline sales. (GeoMarketing)
Retail has shifted to using technology to close the sales to an extent that it is both contextual and consistent. RainCheck creates relationships with consumers and assists in determining the sale and retail journey, making it personal.
RainCheck transcends the future for retailers to establish balance of power, measure the online to offline conversion of sales and target online users that ensue in-store activity and purchases.
‘Our original mission is transcending the online and offline worlds and that’s what we’re focused on and everything that happens around that’, says Cameron Wall.
RainCheck is a digital channel that transforms the digital and physical systems of retail shopping. For the consumers, there is the opportunity to obtain both an online shopping request and an in-store experience.
As the data shows, about 85% of people prefer browsing online, but make a purchase in-store. People are afraid of bad material quality or that the thing may not fit. While just viewing goods, users are not particularly eager to click on “Buy” and purchase them online. Thus appeared a gap which the whole eCommerce is stuck in. It is RainCheck that can fulfill this loophole. So, let’s look deeper what RainCheck is and what use it can bring for customers and sellers.
What is RainCheck?
RainCheck is an O2O Commerce Platform aiming at transcending the online and offline worlds. This platform is based on DLT, or in other words, blockchain, while the other instances run on the AWS Cloud Environment. The RainCheck platform allows sellers to track online product discovery to in-store sale. This platform doesn’t use Ethereum network, like many other do, it will be built using Stellar Network that works for non-complex applications through simple smart contracts. It means that all the transactions will be recorded forever in the Stellar Consensus Protocol. SCP has some safety properties that optimize for safety over liveness, it pauses the progress of the network until consensus can be reached. SCP simultaneously enjoys four key properties: asymptotic security, decentralized control, flexible trust, and low latency. This makes the RainCheck platform unique. Furthermore, the platform has already won several awards, including the Visa Everywhere Initiative and the Accenture Consumer Tech Award in Singapore.
What are the main advantages of RainCheck?
By using this platform, users obtain the most updated information about the product presented at the right time and place, so that it will narrow the gap between online and offline shopping. All the products discovered online can be saved, moreover, the user will get notified information about the time when the product is available in nearby stores.
The platform also includes such positive aspects as:
gulping the product information data including stock levels from different eCommerce platforms such as Neto, Magento, Demandware, Shopify;
accumulating the data of the product for the customer;
allowing users to save a product item into the Cloud;
involving backend integration to payment scheme API’s, PSP’s and banks;
using Geo-fencing technology;
analyzing hundreds of data points;
offering a card-linking capability to users of debit and credit cards. The platform works closely with payment card schemes such as Visa, MasterCard, American Express, along with Payment service Providers (PSP).
Every party will benefit from this platform. For example,
Shoppers – The user will be rewarded with reward points or even cash-back if the purchase is performed either online or offline.
Retail brands – The data analysis function can measure digital marketing attribution to a landing page or website so that the sellers can find out all the information. The platform can track that sale all the way from the digital marketing call-to-action (CTA).
Payment Service Providers (PSP) – They can set fees and/or make a commision from successful online payments, they are also in a good position to capture offline transactions.
The ICO starts on November 5 and will last for 1 month till December 5. The RAIN Token is based on Stellar and costs $0.04. The soft cap is marked at 6,000,000 USD, while the hard cap is 28,000,000 USD. The total supply of RAIN Tokens is 2,000,000,000. The distribution pool accounts for 35% of tokens. The RAIN Token sale will be conducted through OST KYC.
The Coin Shark does not endorse and is not responsible for or liable for any content, accuracy, quality, advertising, products or other materials on this page. Readers should do their own research before taking any actions. The Coin Shark is not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any content, goods or services mentioned in the article.
Article by Coin Shark – https://thecoinshark.net/raincheck-o2o-platform-aims-to-change-ecommerce-world/
Many people have asked me why we chose to build our Token project on the Stellar protocol, and my answer is quite simple. If we had built our project on the ERC-20 standard (Ethereum), it would have failed. In fact, I believe that almost all projects backed onto the Ethereum chain will fail, here is why.
It was June of 2017 and I was discussing using the Blockchain or DLT (Distributed Ledger Technology), with my cofounder Will, to solve a massive problem that loyalty had in the retail brand space. It was a no-brainer really as we could extend our existing online-to-offline (O2O) platform to capture loyalty as well and using the distributed ledger ticked a lot of boxes.
The next task was for us to evaluate what chains existed that we could leverage to build out or solution on. The obvious choice was Ethereum as it was widely being used by many projects and there was a lot of hype around it at the time as they had an ERC-20 standard that supported smart contracts. We ended up deciding on the Stellar protocol and we are so happy we did, below is a summary of that journey and how we got to where we are today.
At the time Ethereum was relatively new to the Blockchain world still, and was, basically a distributed programming platform — scripting software for autonomous organizations and ownerless apps. Described by Vitalik Buterin (co-founder of Ethereum), himself as
“Ethereum is a modular, stateful, Turing-complete contract scripting system…our goal is to provide a platform for decentralized applications.”
Now if you are going to build a project that is truly decentralized with no central decision making, Ethereum is a great choice. But most blockchain companies don’t need smart contracts to execute their core business logic or want to circumvent the legal or jurisdictional problem. They just want to issue digital assets and process transactions. That’s exactly where Ethereum will let you down.
If you are building a project where tokens will be issued where they need to be traded quickly and at low cost then Ethereum will fail every time. Our project involved issuing tokens that needed to be used in a retail environment while transactions were happening in near real-time, this was a concern.
With all tech projects you start from the user experience and work back from there, and using the Ethereum chain we would have been in big trouble from day one. To confirm this we observed tests that were carried out between April and May this year 2018. The results and methodology can be found here on GitHub.
Problem 1: Your most enthusiastic users will have the worst experience.
Ethereum queues transactions on a per-account basis, and yet miners don’t prioritize transactions by wait time. In fact, given transactions with equal gas prices, miners are assigned them at random. So an active account builds up a transaction queue, and the network has no mechanism to clear it. The result, for high-volume accounts, is an ever-increasing transaction lag.
Ethereum processes transactions using two numbers, a transaction nonce (what we’ll call the “nonce”) and an account nonce that, for clarity, we’ll sometimes call the “count”. The transaction nonce puts an account’s transactions in order; the account nonce counts whenever one of them is mined. When a new transaction, with its nonce, is submitted, Ethereum compares that nonce to the current count to decide what to do. If the transaction’s nonce is lower than the count, the transaction is ignored. If it’s higher, the transaction is delayed. Only if/when the nonce matches the count can the transaction move into a block. Here’s a simplified diagram of how it works:
This is actually very similar to the “please take a number” systems you see at a deli or at a government office like the DMV, and it’s a fairly common way to prevent replay attacks. Lots of other chains do something similar. However, Ethereum’s transaction-to-block algorithm (or, really, lack thereof) adds the wrinkle that the people working your DMV window here — the miners — aren’t necessarily accountable to the next number in line.
As you can see in the graph below, Ethereum mining is dominated by a few select mining pools — the four largest miners account for a whopping 70% of the Ethereum hash rate.
Miners often have their own criteria for the transactions they’ll accept. Many only accept high-gas-price transactions. Some only accept their own transactions. Miners like these will let block space go unused before filling it with something from your queue. So now imagine a DMV where certain windows are telling people “sorry can’t help you,” while more people file into the waiting room every second and you have all these jokers in front of you who have to get helped before you can even talk to someone — and, voila, you have some idea of how Ethereum handles transactions.
We weren’t aware it worked like this until after we tried to implement Kik’s load spec: 480 accounts each submitting 1 txn/minute on average for 3 hours. That’s 86,400 total transactions, an average of 8 per second.
We spun up the test, using ETH Gas Station’s “standard” estimates for gas, expecting a median confirmation time of about 30 seconds, and, lo and behold, 13 hours later, more than half of our transactions still hadn’t made it into a block. We stopped the test at 13h and 50m, and 50.1% of our transactions were missing. (Reminder: the raw data is in our GitHub, if you want to check our work.) We thought we’d messed up somehow, but, no. We had just created a bunch of long lines, and some jabroni transactions had stood there all day doing nothing.
When you read elsewhere about “Ethereum transaction times”, the posted numbers almost always suppose a single, one-off event. They do not pertain in an application-level environment. We ran the Kik test again just to really make sure we were doing everything right, spending another 6.9 ETH, and we got essentially the same result.
Here’s a typical experience from that run — this is just the account that happened to be first alpha-numerically. You can see the wait times grow as transactions pile up.
It’s one thing to talk about “settlement time” in the abstract. But think about the above data in terms of actual user experience. The more someone uses your Ethereum app, the slower it goes. After just three hours, their transactions are taking 8 hours to confirm.
Of course Kik’s test spec said we should submit transactions for three hours and then stop, so that’s what we did. In the real world, you can’t build in downtime to allow the count to catch up — so in theory transaction queues just get worse and worse. In practice, of course, as your Ethereum app becomes unresponsive, users will help it catch up, by leaving.
Here’s the performance distribution from that second test. I trimmed the slowest 5% so the long-tail doesn’t skew the overall picture.
For comparison, this is what Kik measured running the same spec (on Stellar.)
I just grabbed this plot from their post, and I don’t have the original data, so I can’t show my results on the same chart. But using the magic of computers, I can at least overlay the curves:
Everything looks comparable until you notice the x-axes. The waits we measured on Ethereum are 3,000 times longer. That’s the queuing problem in a nutshell.
This performance issue is currently a fundamental part of Ethereum. Improvements like sharding or Casper are promising in theory, but those will be complex fixes layered over Ethereum’s almost maximal complexity. Something like lightning can rely on Bitcoin’s inherent simplicity; whereas there’s nothing basic to fall back on here. A skyscraper is usually built on bedrock, not on top of another skyscraper, yet that is what a lot of Ethereum scaling solutions propose to do.
The only certain performance improvement is to spend more on gas and hope to plow through each account queue faster. We in fact did that in a third three-hour trial — which we ran because of our “we should do what we can to make this work” commitment.
The previous two tests had used the “standard” ETH Gas Station recommendation. We used the “fast” tier (≈4 Gwei at the time) for the third and spent 11.8 ETH on our 480 accounts.
Performance improves — to only 500 times slower than Kik’s results on Stellar — but it’s still not fast enough. The backlog builds and payments hang around with nothing to do.
Problem 2: Very High Cost of Wide Adoption
Ever thus to power users. But Ethereum is also unsuitable for the other kind of adoption, what you might see with an app like, I dunno, Etsy, where instead of a few people going deep, you have lots of people checking in every once in a while. That’s because an Ethereum app’s per-user costs go up quickly as it adds users, and that’s why you see stuff like 70x price spikes whenever anyone tries using the network across many accounts.
We captured this data incidentally, looking for a workaround to the queueing problem. To keep transactions from piling up, we refactored the Kik spec as follows: instead of a few accounts submitting a bunch of transactions, we spun up a bunch of accounts (28,800) and had each of them just do a single transaction. To stick to the original test’s guideline of 8 total txn/s we submitted the transactions over the course of an hour.
Curiously, this didn’t actually help performance very much. The median confirmation time was 23 minutes — actually slower than the “fast” test above. Even weirder, some of the first transactions we submitted were the last to confirm:
We knew account queues couldn’t be the issue. It turned out that as soon as our transactions started hitting the network, miners’ fees soared. So our earliest transactions, submitted with pre-test “standard” pricing, were quickly priced-out. They lingered in low priority for hours.
We had discovered another of Ethereum’s negative reinforcement loops. Adding users immediately scales cost. In the real world, increasing the number of units implies lower per-unit costs. Basically the whole private sector is built on this idea — “economy of scale”. But here: each incremental user immediately increases the per-user cost. It’s like bizarro economics.
You can see prices climbing ≈6x over the short 1-hour run of our test.
Again, the built-in time limit of the test makes everything look more sustainable than it actually is. Extrapolate this chart out and drop the needle somewhere in the middle. What do your per-user costs look like after two weeks of steady usage? Two years?
The above test cost us $1,445 for a single hour. It ran when gas prices were low, just ≈1 Gwei for standard speed, and it puttered along at just 8 transactions a second. To run a basic test, that’s $12.6m a year.
If you apply that cost structure to a real business, you see that Ethereum’s fees are already unsustainably high. For example, PayPal does about 240transactions a second. Put aside the performance fixes it would take to make that happen and put aside the rising-price dynamic I just documented. If PayPal had been built on Ethereum and paid our observed rate, they would’ve laid out $380m in network fees last year. That would’ve been 21% of their net income, and, again, that’s pretending that you could somehow freeze prices.
An idealized version of Ethereum won’t work for one of the most profitable transactional businesses in the world. How is the real version going to work for the rest of us?
“If you want to build a decentralized Uber and Lyft on top of an unscalable Ethereum, you are screwed. Full stop.” — Vitalik Buterin
I encourage you to watch the full panel this quote came from — it shows four of the most important members of the Ethereum team saying a lot of what I’ve been saying here. When today’s high-profile ICO becomes tomorrow’s cautionary tale, it will only be bad for everyone in the ecosystem, and they know it.
There’s no doubt that the Ethereum community is the strongest in blockchain, and there very likely wouldn’t be token economies at all without Vitalik’s vision. It’s not Ethereum’s fault that developers are asking from the tech what it was never meant to deliver. It’s the people chasing last year’s ICO dollars, regardless of what’s actually the right tool. Ethereum’s problems all start with misguided entrepreneurs. Don’t become another one of them.
If you’re building a transactional app, the protocol will not support the behavior your users will expect. I have immense respect for the ambition and the complexity of Ethereum, but I’ve come to see it as blockchain haute couture. Beautiful, intricate, high-concept, high-minded. And not what you wanna wear to work.
If you want trustless, distributed computation — if that’s really what you’re building — definitely use it. If you never plan to actually launch anything, Ethereum’s great for that, too — just ask the over 50% of ICO projects who disappear after their token sales, if you can find them. They’ve already hit the Great Filter. And likely some beach in Puerto Rico.
But if you want to build a business that sticks around like we are — if you plan a typical user-to-user service and don’t need to tie up your business logic in a smart contract — if you plan to issue a digital asset and you plan to transact at high volumes as a core part of your strategy, pick a platform that is optimized for that. Do what we did, and build on Stellar.
Cameron Wall CEO & Co-Founder, RainCheck
Credits: Contribution by Christian at StellarX and Tomer Weller designed and ran the load tests and provided technical guidance for this post.
Providing consumers with a loyalty program in the digital age is simple and fast. But, there is regularly a substantial divide between the numbers of programs in which consumers join and the number in which they actively engage.
Co-Founder and CEO of RainCheck, a Decentralized Loyalty and Rewards Platform, Cameron Wall states,
‘Obviously people who shop online and offline are much more valuable than people that just shop online.’
Loyalty should be like other new technologies, simple, logical, clear and valuable. Rewards should be acquired, exchanged and used at any loyalty program, and accessible everywhere.
During a short period of the pilot it was measured ‘1.8 million dollars in merchandise that was RainChecked, and that basically led us to the point of understanding, did the transaction occur’. ‘And that’s that’s when we went into the phase of tackling that problem and integrating the payments side of it so that we could close the whole loop’, says Wall.
The RainCheck Platform based on Stellar will establish RAIN Tokens. In applying the distributed ledger technology, people will be able to acquire loyalty and reward points in a smooth way from any retail brand and use it to share or convert them into a service unit that can be used at other retail brands.
Having multiple brands accessible to consumers, via online channels, indicates that there are a great number of reward programs that are driven by various loyalty programs.
The arrival and access of online channels sets loyalty programs to be tailored to the consumer and pertinent through the use of mobile apps and in-store engagement. RainCheck delivers instant content that enables the shoppers loyalty program to be more personalized and consistent across frequent purchases.
‘We basically make money from the platform play. So we license the platform out to the brands if they want to use all the different modules for their own app or we actually can click the ticket on loyalty on the payment side’, says Wall.
‘Loyalty is a big one on card linking so linking offers and loyalty points to everything on payment cards’ says Wall.
RainCheck adopt and focus more on a SKU level of the card-linking approach in order for shoppers to save money on purchases by linking their payment cards to a merchant, cash-back or loyalty program.
Wall continues, ‘So it’s sort of a cloud platform it’s quite flexible depending on what the retail brand wants to do because they all want to do different things.’
RainCheck establishes a decentralized loyalty and rewards platform that can combine reward points across a number of loyalty programs. It aims to allow the consumer to pass reward points for one program to another. Shoppers will now have the opportunity to collect their points into one unit and use at that one loyalty program, or even share points to a third party.
Establishing a simple, logical, clear and valuable loyalty program will lower the increasing debt that is owed, as well as managing the level of loyalty contentment of it’s program shoppers.