Stellar Dev Digest: Issue #21

Meridian Recap, SDF’s Next Steps, and Protocol 13 sneak peak.

Kolten
Stellar Community
7 min readNov 11, 2019

--

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.

Meridian keynote — Carlos Hernandez

This was a huge week for Stellar-related news. In case you missed it, Meridian took place November 4–5, and it was amazing. Developers, businesses, students, and everyone in-between met up in a beautifully worn-in, plant-filled casa in Mexico City to discuss all things Stellar. There’s no way to cover everything that happened—take a look the Meridian hashtag to understand why—but I’ll do my best to hit the highlights.

Featured Developer Posts and News from the Week

🔥 The hardest hitting news from Meridian: the announcement of SDF’s Next Steps. The takeaway: SDF can be leaner, more focused, and more efficient with smaller lumen allocations, so we burned 55 billion lumens and set up some new strategic objectives including ecosystem support, use-case investment, and user acquisition.

Some other interesting tidbits from this week:

This week’s application is Illmatic! I was unaware of this project before Meridian, where they were part of the Stellar Spotlights panel hosted by SDF’s own Jed McCaleb. You can watch a short video of their pitch and demo here.

Our mission is to empower individuals, society, and culture through the freedom of programmable money.

Illmatic is a wallet and point-of-sale app that enables users to make p2p cash-like payments. As creator Danny Tamez said in his pitch, it’s like “apple pay for crypto.” It abstracts wallets into cards, which is a clever design decision that keeps things simple. Payments are done through NFC, where things like transaction amounts and public keys are shared, and are settled on the Stellar network.

Updates to Stellar Protocol (CAPs) and Ecosystem (SEPs)

Core Advancement Proposals (CAP) and Stellar Ecosystem Proposals (SEP) are a formal way of documenting proposed standards to improve various aspects of the Stellar Network. These function similar to EIPs and BIPs from the Ethereum and Bitcoin communities respectively. CAPs and SEPs represent the culmination of many discussions that often take place on the Stellar Developer Google Group.

It was an interesting week on the CAP front. Tomer Weller from SDF and OrbitLens from StellarExpert gave a talk at Meridian that covered the CAPs being considered for inclusion in Protocol 13. There were a total of four:

  • CAP-0015 introduces fee-bump transactions, which enable any account to pay the fee for an existing transaction without the need to re-sign or manage sequence numbers. Say validators decide they need to increase minimum the transaction fee: there’s a way to “bump” a pre-signed (or pre-authorized) transaction’s fee so you can still get it on the ledger.
  • CAP-0023 introduces a claimable balance entry, which helps anchors get around the chicken/egg trustline conundrum. It’s a protocol-level solution to the problem SEP-0025 tries to address, and essentially makes it so that an anchor can give a user access to a token even if the user doesn’t have an account or a trustline.
  • CAP-0018 makes it easier to issue regulated assets on Stellar by introducing fine-grained asset authorization. Once implemented, it will allow an issuer to de-authorize trust for an auth_required token without canceling open orders, which means they can approve trades on a case-by-case basis.
  • CAP-00XX, which isn’t numbered because it has yet to be drafted, will be a protocol solution to multiplexed accounts. It will allow exchanges and other companies that map a single Stellar account to internal customer databases to send and receive payments that include info currently relegated to the memo line. That thing where humans forget to add a required memo? This CAP will stop that from happening.
Stellar Protocol: Design Consideration and What’s Next

One cool thing: during the presentation, Anthony Barker from TEMPO actually submitted a potential CAP of his very own. It’s in the early stages, but it proposes the idea of implementing a “cross order type,” which is an over-the-counter trade an exchange executes and announces to the market. The basic idea: two anchors can trade directly with each other on the SDEX, which means they can build a payment corridor that improves market volumes and has good auditability.

Calls for Participation

Want to contribute to Stellar but don’t know where to start? The repositories below have a handful of beginner friendly PRs for you to take on!

  • Kelp (Go: 9 Open Issues): a free and open-source trading bot for the Stellar universal marketplace.
  • Account Viewer (JavaScript: 5 Open Issues): a simple tool to view an account on the Stellar network and make transactions from it.
  • JavaScript SDK (JavaScript: 8 Open Issues): a Javascript library for communicating with a Stellar Horizon server. It is used for building Stellar apps either on Node.js or in the browser.
  • Js-Stellar-Base (JavaScript: 2 Open Issues): the lowest-level stellar helper library. It consists of classes to read, write, hash, and sign the xdr structures that are used in stellar-core. This is an implementation in JavaScript that can be used on either Node.js or web browsers.
  • Go MonoRepo (Go: 13 Open Issues): the home for all of the public go code produced by SDF. In addition to various tools and services, this repository is the SDK from which you may develop your own applications that integrate with the stellar network.
  • Laboratory (JavaScript: 2 Open Issues): a suite of tools to help you learn about exploring the Stellar network.
  • Vanity Address Generator (Rust: 3 Open Issues): a simple CLI tool to generate Stellar vanity addresses.

At Meridian, I heard a lot of compliments about the dev community, documentation, SDKs, and more. So kudos to everyone who has chosen to be a part of the Stellar ecosystem and has worked hard to get us to where we are today —your contributions do not go unnoticed!

Hot tip for Python SDK users: Overcat, the maintainer of the Python SDK, will be releasing the stable version of v2 at the end of the month. For now, when users install stellar-sdk from pip, it installs 1.4.0 by default, but after the release it will be 2.0.0 by default. Anyone using the Python SDK should configure requirements.txt to ensure that dependencies aren’t broken.

Looking to work on Stellar full-time? Check out the list of job openings below:

  • SDF Frontend Engineer (New York) Apply
  • SDF Senior Platform Engineer (San Francisco) Apply
  • SDF Senior Core Engineer (San Francisco) Apply
  • SDF Senior Platform Engineer (New York) Apply
  • SDF Software Integration Engineer (San Francisco) Apply
  • SDF Spanish Language Content Writer & Translator (New York) Apply

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 👍

--

--