Chapter 05 · the templates
The Primus browser extension is open source. Sixteen data sources ship in it, and the configuration says, for each one, how the flow gets in: through a session you already have, through a key you mint, or through a grant you approve. Four of them go further and write out the exact request chain. None of this is in an announcement. All of it is in files you can read.
Every source declares a connection type, and the three are not equivalent. An API key is a credential you create and can scope down to read only. An OAuth grant is a permission you can withdraw at the provider. A browser session is neither: it already exists, it was not made for this, and it carries whatever it carries. 9 of 16 entries use the third one.
There is a second axis, and it is the one worth noticing. Of the sixteen entries, only
7 are offered in the picker.
carry a hidden: true flag, and one, Bitget, is commented out of both source files
while its template and its constants stay behind. Shipped is not the same as shown.
Method, path, and the named cookies or headers each call must carry. Open one and read it downward: this is the order the flow visits your account in. Note which four these are. Every template written out in full belongs to a source that is hidden or commented out, which makes this section less a map of what runs today than a record of what was built and then set aside.
The other half of the configuration is the vocabulary. There is no free text anywhere in it. You prove that a number clears a bracket, never what the number is, which is the same selective disclosure chapter 04 took apart from the other end.
Coinbase is an API key source. Its entry carries a baseName of
api.coinbase.com, which is right, and an accountBalanceUrl of
https://api.binance.com/api/v3/account, which is Binance.
It appears three times: in constants.ts, in dataSource.ts and again
in dataSource2.ts, which is a near duplicate of the first. I could not find a
consumer for the field outside those config files and the type declaration, so the likely
answer is that it is inert, a copy-paste that outlived its line. Worth knowing anyway: the
config is the thing everyone reads to understand what a flow touches, and one line of it
points at the wrong exchange.
This is not a claim that your cookie is taken. The design of zkTLS is that the credential is used inside the TLS session and is not handed to the attestor: in MPC mode the key material is split, in proxy mode the proxy sees ciphertext. Nothing in these files contradicts that, and nothing here is an exploit.
What the files settle is reach. A template declares which endpoints the flow is configured to visit on your behalf and which named credentials each call carries. That is a product decision rather than a cryptographic one, and it is the kind of decision that normally lives in a slide instead of a file you can open.
The Bitget entry deserves the most precision, because it is the easiest thing on this page to
misread. Its template lists three requests and the middle one is a KYC real-name status
endpoint. The product does offer a KYC Status claim under Humanity Verification, with Basic
and Advanced levels, so the endpoint has a purpose. But the Bitget source itself is commented
out in both dataSource.ts and dataSource2.ts. You cannot pick it,
and this is not a description of something running today. It is a template that outlived the
source it belonged to, still carrying the shape of what that flow was meant to visit.
If you are integrating, the habit is the one from chapter 01. Do not reason about what a proof means from its name. Read what produced it: which door it came through, which endpoints it visited, and which bracket the claim was made against.
Quoted under LGPL-3.0. Endpoints, credential names and connection types are reproduced as the files declare them, read on the first of October 2026.