Web3devs participated in PayID Hackathon: Make money move like email hosted by Devpost.
Unisend – Send money internationally for free
Inspiration
It’s quite hard, expensive, and slow to pay overseas developers.
What it does
Unisend allows you to send money to anywhere in the world for basically free via an XRP payment rails and PayId. This is done by using Dwolla and Plaid to withdraw money from the sender’s bank via ACH. Those funds are deposited into an exchange. The USD is immediately exchanged for XRP. The XRP tokens to the recipient’s exchange address which is on their PayId. The tokens are immediately sold once the webhook is triggered. From there, the funds are send to the recipients bank account.
How we built it
We used React for the frontend and Express NodeJS for the backend. We utilized numerous APIs including Plaid and Dwolla. These two APIs allow us to withdraw funds from a user’s US bank account via ACH. We also used the Indian banking API to handle their ACH equivalent.
Challenges we ran into
Setting up Dwolla and making it function with Plaid.
Love it or hate it, everyone was waiting to see what Facebook’s new Libra platform would look like when it was revealed today. I spent some time this morning going over their docs and examples and I found some things to be expected and some things that were a bit surprising.
Getting Started
It looks like for now, Facebook has a testnet up and running. The mainnet will be up sometime in 2020, so that gives developers plenty of time to learn the system and create apps on top of it. As expected, there is no way to run a real “node” in the classic sense of the term, where you can contribute directly to the network. You must currently connect to validator nodes. I couldn’t quickly determine what their process is for becoming a validator node, but I have a strong suspicion it consists of being a giant corporation and paying a small fortune. You can run your own validator network locally, but that is just your own network for development purposes and does not connect to the testnet or future mainnet.
Getting started was pretty quick and painless if you’re not afraid of the command line. I was connected to the test network and making transactions between Alice and Bob in less than 5 minutes. A lot of the tools and commands were very familiar and it does seem that Facebook is putting effort into giving developers what they’re used to in the blockchain world and not trying to reinvent the wheel. One really nice feature was that there is a testnet Faucet built right into the CLI. This helps us devs get up and running even faster.
Pseudonymity
One of the big questions looming about Libra was how anonymous was it going to be? Blockchain people love anonymity/pseudonymity, it’s one of the core belief pillars for a lot of people in the industry. And Facebook doesn’t exactly have a strong reputation in the privacy department.
I was happy to see that nowhere in the process of getting set up and making transactions was I prompted with a Facebook login. It seems Facebook so far is taking pseudonymity pretty seriously. So far. Keep in mind this is all currently on testnet. Things could be different when the mainnet launches.
Smart Contracts
As a dyed-in-the-wool Ethereum enthusiast, I was a bit disappointed in Libra’s smart contract capabilities. Ethereum’s smart contracts are the thing that made everything click for me about the potential future of blockchain technology, and it seems Libra’s “smart contracts” are a bit more akin to Stellar Smart Contracts, which are really more like multisig wallets than flexible smart contracts. There’s still a lot you can do with them, though. Everything from custom tokens to full auction websites can be built using this type of contract, but good luck going as far as projects like MakerDAO or Aragon on a limited system like this.
Open Source
Facebook seems to actually be making the effort to build a development community around Libra. Everything is open source, the documentation is excellent, and the developer tools are familiar. Once again, we’ll see if this holds up when they make the transition to mainnet, but I’m hopeful after today.
Conclusion
I’m remaining hopefully optimistic about Facebook’s new Libra platform. It seems like they’re headed in the right direction. And while I would never suggest Libra will overtake a fully open network like Ethereum, I’m sure it will have valid use cases that help move the needle with blockchain technology in general. I think the really exciting use cases of this technology will come from the WhatsApp world. Large sections of the world use WhatsApp to pay for quite literally everything they buy. Adding the possibility for conditional payments on top of that could open up billions of people to the benefits of blockchain technology. I’ll definitely be watching this project closely and learning more and more on the dev side. Let us know if you have the next great idea to be built on this platform and need some devs to put it together.
The Status hackathon in Prague last week was one of the most anticipated events in the blockchain world this fall. Hundreds of coders from all over the world formed 32 teams and worked all weekend to build blockchain tools in the Status ecosystem.
Aaron Anderson’s team created DaiPOS, a point of sale solution using the DAI stablecoin. It has an interface similar to SnapChat, creates QR codes that hold the transaction data for purchases, and keeps track of sales and inventory. Purchasers do not need to have the app, any Ether wallet that can scan QR codes can complete the transaction.
The judges awarded them 2nd place in the Marketplaces Track and received the bounty from the DAI prize.
Since we’ve been cleaning up at these hackathons, we’ve decided to go all in and head out as a team to San Francisco next week to compete in the EOS Global Hackathon. Let us know if you’ll be there!
The WyoHackathon was a highly anticipated hackathon where participants were tasked with building a fully functional blockchain-related product in one weekend. More than 300 software developers from all over the world formed 30 teams to compete for a number of prizes. Wyoming has been incredibly innovative in the past year regarding blockchaintechnology, and their state government has led the way in proactive forward-thinking blockchain and cryptocurrency regulation, hence the anticipation from blockchain enthusiasts for this hackathon.
A team of developers from web3devs made the trek to the Cowboy State to participate. Aaron Anderson, David Bruno, Scott Finney, and Sam Steele created the Electronic Corporate Formation Portal to help blockchain businesses legally incorporate in the state of Wyoming and to help those companies comply with the new regulations Wyoming has enacted — and they did it in less than 48 hours.
The Electronic Corporate Formation Portal takes advantage of new Wyoming services that allow companies to incorporate an LLC with the state electronically instead of filling out paperwork manually. The web3devs team’s ECFP integrates with Wyoming’s new system and also allows companies to then create and associate cryptocurrency wallet addresses with the new LLCs, thereby complying with the state’s new financial regulations regarding blockchain LLCs.
The product they created was a hit, winning four awards including the final “Best for Wyoming” award. The judges included all 3 gubernatorial candidates in Wyoming as well as tech leaders in the Wyoming community and blockchain experts from around the country including Joseph Lubin, the co-founder of Ethereum and founder of ConsenSys.
The WyoHackathon was lots of fun and we had the opportunity to meet a lot of great people. Next stop is Atlanta! Check us out at EthAtlanta September 21-23 and check out what we’re going to build next.
What to Expect when your Smart Contract is Audited: The Auditor’s Story
Considering a Smart Contract Audit?As a smart contract auditor, I’m trying to make sure your contract is secure against Ethereum Virtual Machine (EVM) level attacks. Those are the kinds of attacks that leverage the nuances of the EVM’s logic in order to hack your smart contract. What I am not looking at is your business logic. That job falls to your test writers. I can do that, DApp developers are polymaths by definition, but that requires a lot more hours and should be scoped out separately.
Specifically, I’m targeting the list of known attacks published by Consensys and the Ethereum Foundation.
Race Conditions (Reentrancy and Cross-function Race Conditions)
Transaction-Ordering Dependence (TOD) / Front Running
Timestamp Dependence
Integer Overflow and Underflow (including Storage Manipulation)
Now the first thing I am going to do is test your smart contract, ideally, with the test scripts you have already written. If I don’t have access to those I’ll compile your contracts in either Truffle or Remix in order to make sure the contract compiles and exposes the functions that have been detailed in the contract specification.
Ensure dependencies are accessible
Once I know I’m working with a functioning smart contract, there are a few steps I need to take in order to make sure my auditing application will recognize every dependency that your contract imports. I need to go grab the code of any dependency that is already deployed and then link it locally. If the framework your code is working in has any issues with pathing, I’ll copy your dependencies into the same folder as your contract and redirect the import statements to this copy. And then I’ll need to do the same for every dependency that I copied, because they will often times also have dependencies that I need to expose locally.
Explore every possible interaction
At this time in the smart contract audit, I’ll spin up Docker and run a local instance of my auditing application and give it the command to run a whole bunch of simulated interactions with your contract using symbolic execution. What this does is explore every possible interaction an actor can perform with your contract using an abstraction of any given input. So instead of testing every possible value that can be passed to every function, which would take longer than the heat death of the universe, it passes a symbol that stands for every possible input. This frees up time for the software to test all possible recursion in your contract’s flow control. The standard depth of recursion that I test for is 8 levels of recursion, but if we will be conducting a formal audit, I’ll run much deeper in an attempt to falsify any mathematical proofs required by a formal audit.
Trivial and non-trivial vulnerabilities
Once the smart contract audit application has finished exploring all the possibilities it will return a report that I will then convert to an appropriate file format; usually markdown, but some projects require JSON reports in order to be parsed by 3rd party applications. This report will contain both trivial and non-trivial vulnerabilities. The trivial ones are technically vulnerabilities, but are generally not exploitable. For example, if your contract is built atop OpenZeppelin smart contracts they could theoretically have malicious business logic, but if we check and see that OpenZeppelin is an accepted standard and does not have any delegate calls that will alter the behavior of the source contracts, we know that we are safe.
Non-trivial vulnerabilities are usually exposed by your business logic. A common one I see is Integer Overflow arising from a for loop that works with arrays. In this case, the business logic may be sound in that controls are in place that no combinations of array lengths or iterations through the for loop will result in an array length exceeding 2**256. But I would advise the client to request or perform a formal audit on that particular function in order to mathematically prove that there is no intersection between control logic boundaries and statistical vulnerability frontiers… or at least that the probability of their intersecting within a given timeframe is within the client’s risk tolerance.
Formal Auditing Recommendation
Finally, I’ll write up my “Formal Auditing Recommendation” in which I identify those functions that expose non-trivial vulnerabilities and suggest that they either be formally audited or rewritten in order to preclude those vulnerabilities. Only the client and their development team can determine which option is most appropriate. As a general rule, though, you want your smart contract to require as few proofs as possible so it’s usually wise to go for the rewrite first and follow that with a second smart contract audit.
Auditing and testing are the pillars of good contract security. If you are handling money in your contracts you should definitely seek out those services from experts. And, if you are looking for some experts in blockchain solutions, you’re always welcome to reach out to my team at web3devs!
