Stellar Dev Digest: Issue #31
SDF joins the Blockchain Association, Bankhaus von der Heydt building on Stellar, new Kelp release and more.
Hey everyone! Welcome to another issue of the Stellar Dev Digest, a weekly recap of all things related to the development of the Stellar Network.
What is Stellar? Stellar is a platform that connects banks, payment systems, and people. Integrate to move money quickly, reliably, and at almost no cost.
News & Posts of the Week
- SDF joins the Blockchain Association, an organization that works with policymakers to educate them on the benefits of distributed ledger technology. “Together with like-minded organizations,” writes SDF General Counsel Candace Kelly, “we’ll use our collective voice to advocate for smart, effective policy that allows blockchain to thrive in the United States.” — Read the announcement here.
- 🔥 One of the oldest banks in Europe is developing a special-purpose euro stablecoin that can facilitate private placements in tokenized securities — and they’re using Stellar to do it! Munich-based Bankhaus von der Heydt, established in 1754, announced that it has partnered with Bitbond to help integrate tokenization into its established securitization platform. — Read more here.
- Stellar Community Podcast Ep. 5 is out! This week Tyler and I cover all the big Stellar news from the Stellar Dev Digest Issues #29 and #30 (Jan 24th — Feb 7th). — Listen here.
- Nitin Gaur, Director of IBM WW Digital Asset Labs, joined the Inside Stellar podcast to discuss remittances, banking, and what it’s going to take for the financial world to adopt Stellar. — Listen here.
- SDF is hosting a “Build Your Own Stellar Wallet” workshop this week in San Francisco on Wednesday, February 19. It’ll cover everything you need to know to build a fully functional Stellar wallet. — RSVP here.
Application of the Week
This week I’m featuring SatoshiPay! — Global, fast, and easy micropayment solutions.
SatoshiPay has a suite of products that includes a micropayment platform, the Solar wallet, and a recently announced business-to-business payment solution. I’ll probably cover all of them at some point, but in this issue I’ll focus on the micropayment platform.
Micropayments, by which I mean sub-$1 transfers, are hard to execute using traditional methods because fees are too high. When you pay $.10 to process a $.05 payment, you know something’s not right. That’s where SatoshiPay comes in.
SatoshiPay allows publishers to integrate a Stellar wallet widget into their websites, which makes it easy for consumers to pay tiny amounts for online content. You don’t have to log in to use it, there’s no waiting, and because Stellar fees are so low, it’s pretty dang close to free. As a result, publishers can dispense with ads and paywalls, and instead charge, say, $.20 for a premium article. Don’t believe me? You can test it yourself on this German publication!
You can find more about SatoshiPay by checking out their website, or by reading the SatoshiPay case study page on Stellar.org.
Releases and Updates
v1.8.1 of Kelp came out last week. If you use Kelp, make sure to upgrade by February 29th. Prior versions aren’t compatible with Horizon v1.0.0, so when the public network switches over, they’ll stop working.
👉 Not familiar with Kelp Bot? You can learn more about it here.
Speaking of Horizon v1.0.0, we are getting closer and closer to releasing it on the public network. The plan is to release the production version 2/24/20 then deploy it to the public network 3/02/20.
Most of the SDKs have added support for Horizon v1.0.0, so we suggest upgrading your SDK of choice as soon as possible to avoid problems.
Here’s a full list of the SDKs that are ready to go:
Active Discussions
💬 The conversation on the dev mailing list this week circled back to the topic of CAP-0027 (multiplexed accounts), and David Mazières posted a last call for objections.
Reminder: this proposal attempts to solve two problems:
- Users forget memo IDs, leading to increased support costs and
lost customer funds for custodial services. - Memos are per transaction, not per operation or source, making it
impossible do to things like have one transaction with payments to
two different multiplexed accounts, or include a multiplexing
identifier in a source account so that funds can be
returned.
The idea is to solve these issues by replacing all sources and destinations of payments with a new MuxedAccount type. The MuxedAccount type can either be an Ed25519 key or a pair of an Ed25519 and an unsigned 64-bit integer id. The id is ignored by stellar-core, kind of like a per-AccountID memo ID.
The road map for implementing CAP-27 is a long one because it requires a change to Stellar-core. In the mean time, there is an ongoing conversation about how to temporarily solve this problem with a SEP, which I’ve been covering over the past few weeks. You can follow that conversation here.
👉 If you have an objections, questions, or concerns regarding Multiplexed Accounts speak now or forever hold your peace! Join in on the conversation here.
Not Yet Signed Up?
Want to get the Stellar Dev Digest and other developer updates directly to your inbox? Sign up for the developer newsletter today!
Did I Miss Something?
If you found that something from this issue is missing or inaccurate reach out to me (kolten) on Keybase and I’ll make sure to fix it 👍
