RFC - Sentinel (Security)

RFC - Sentinel


This document tries to explain basic principles behind security on the SAFE network.


Big part of algorihms behind the SAFE network rely on so called local group consensus. What it basically means is that for a node to act in some way, it needs to be instructed to do so by a quorum of other nodes. The set of these nodes is determined by the network, but in general they are expected to be as close as possible to a certain HASH address within the XOR network.

We generally call such a set a Group(H) where H is the HASH address or simply a Group when H is known from the context.

The key idea is the assumption that it is cryptographically hard for an adversary to enter an arbitrary group of close nodes. The purpose of the Sentinel is then to ensure that the set of these instructing nodes really lives in a Group surrounding the given HASH.


So pure and key sentinels may become part of the routing library and confirm nodes in both directions but by cross referencing other nodes, where node a is confirmed by node b, and node b is confirmed by node c so node b is also confirmed by a (by way of node c). This is what I’m getting is this correct?

1 Like

Yes this is it. The distance of the group will also be confirmed to be a real group in the real network.


Right confirmed through XOR space, sorry I left that out. Neato :smile:

1 Like

Since this is a group message we expect to receive many copies of it. And since we want
a quorum of such messages, sentinel must start storing them while identifying
which nodes sent it.

Question: when an app does a PUT request, the request isn’t sent only from my node but also from all other nodes in my group, is that correct? If so, what’s responsible for telling the other nodes in my group to replicate my PUT request?

Put == Make something appear for first time on network.

In our case a client cannot do that. So it has to coerce a group to do this one it’s behalf. To do this it goes to a group that knowns it (ClientManager that holds the nodes account). If the group agrees (in our case the client has paid) then they all forward the request as a group.

So to recap

Get == Retrieve (always free no authentication
Put == Create (only possible by a group)
Post == Mutate (can be client direct to a group holding data as StructuredData cryptographically secured)
Delete == Remove (can be client direct to a group holding data as StructuredData cryptographically secured)

ImmutableData is network owned. StructuredData is owned by people (or more accurately owned by a cryptographically secured identity)


Cool so the ClientManager is the one calling the shot. I understand this is a pretty trivial question for many people but I don’t have a lot of time to dive into the white paper, sorry if my question is being redundant.

Is the ClientManager always part of my closed group? Is there always one ClientManager in each closed group?

Some more questions:

  • Just to be sure, there’s always one sentinel of each type in every group, correct?
  • Could a node have more than one sentinel role? For example, can a node be an account sentinel and a pure sentinel at the same time?
  • What is responsible for promoting a normal node into a sentinel?
1 Like

The group is the clientManager, so the closest nodes to your ID are your clientManagers. They will constantly change as nodes go up/down connect/disconnect join/leave etc.


Per node for all persona’s (sentinel is in routing).

I get that a lot :frowning: it’s an Internet thing, we can have books, videos, papers, web sites, wiki’s but still people like to ask and get one-to-one info. It’s something that I am toying with these days how to help more. There must be a way :wink:

1 Like

I get what you are saying. Things is, when you try to picture in your head how something works and you feel like you are missing a very specific parts, it’s indeed more efficient to just ask for it instead of trying to dig it up. To be fair, I didn’t expect you to answer these directly and maybe wrongly assumed the knowledge was already well spread out among the community.

Either way, thanks for the answers and keep up the good work!


I’ve read the white papers but there is so much there it’s hard to retain. I was going to answer but I wasn’t certain and didn’t want to disseminate incorrect info. So I got something from David’s reply too. my favorite fallbacks are the github readme files and the system docs


The videos from Montreal Safe pod were pretty good at explaining high level concept like the XOR space. I wish there were more like it. But I understand these takes a lot of time to put together and there’s so many subject to address it’s quite a daunting task.

I guess as the network gains in popularity so will the amount of information that is available in a more digestible format. I can’t wait for the first Safe for dummies book :smile:


Will the dashboard become available for local test networks…that was pretty cool

are you referring to the visualiser?

Yes thats the one…