Greg Brockman

Page 2

Setting up federated addresses with Stellar

Fun fact: the username you sign up with on Stellar’s hosted web client is actually a federated address rather than a username. That is, the username gdb is actually short for If you control a domain, you can set up federated addresses for your domain.

We’ve now set up federated addresses on You can now use your client to make a payment to

 Setting up federation

You can set up federation for your domain too — it’s pretty easy (though per the below, the protocol may end up being changed). I’ll walk you through how a client or browser resolves


First, the client finds Stripe’s stellar.txt file by requesting the following URLs until one works:


We’ve set up our stellar.txt on, which is served as...

Continue reading →

The Stellar object model

Stellar attempts to encode a relatively direct model of real-world
finance. Here’s an overview of the main concepts you need to know to
start building using Stellar’s API.


Think of the credit system as a graph. Each account is represented as
a node, and the credits are represented as per-currency weights
on the edges. For example, if Joyce owes me 10 GBP, then from my
perspective the balance between us is set to +10 GBP. If she later
gives me 15 GBP in person, then our balance should adjust down to -5

From her perspective, everything is the same except the signs are

Note that it’s possible to issue credits in arbitrary (even user-defined) currencies. The implications here are pretty interesting, and I’ll likely address them in a subsequent post.


Trust lines are effectively permission for an edge’s nodes to move the balance in one direction. By default...

Continue reading →

System Design: Stripe Capture the Flag

We launched Stripe CTF 2.0 on Wednesday. Thus far we’ve had 14,000 signups, and over 500 people have captured the flag. Designing an architecture to handle this many users, all running their potentially malicious code on the level servers, was definitely a challenge, but it was also a ton of fun.

Our first and foremost design goal was pretty simple: don’t let people root the machines. It’s horrendously difficult to keep a shared Linux login machine secure, so the best you can do is apply all of the security countermeasures you can think of. Each level server is configured in the same way (maintaining multiple configurations is a great way to end up with an oversight due to increased complexity). All user-facing services run in a chroot with only /home, /tmp, /var/tmp, and /var/log writeable. This is implemented by mounting a filesystem (created using debootstrap) at /var/chroot and...

Continue reading →