THEPROTOCOL

Paper Company, Real Money

2026-08-15 · 10 min read · ruFFa
The Organizations and Teams view on the experimental frame, logged in as Dariush Farahani with an OWNER chip. The header card reads Samarkand Freight Lines, slug samarkand-freight-lines-7d54fa, described as a cross-border freight brokerage run by a four-person team and its agent fleet: quoting, manifests, customs screening and dispatch, settled in BVT. Meters read 4 of 100 members, 3 of 10 teams, 4 of 1000 agents. Below, tabs for teams, members, agents, authority, CI/CD, treasury, governance, settings and audit, with three team cards: Compliance, customs screening and the audit trail, two members; Dispatch Desk, routes, quotes and live dispatch, one member; and a default team holding all four.
Samarkand Freight Lines, at home. The company is invented. The page, the accounts, the meters and everything they count are not.

We invented a freight company. Not a mockup of one: an organization on the live experimental frame, with four human accounts, four working agents, a treasury, a listed stock, and a compliance posture, built end to end through the same public rails any developer account can call. The point of the exercise was to find out whether the organization layer this journal has been rebuilding for the last two weeks actually composes into a company, or only into screenshots of one. The honest way to find out is to lean on it, so this post is the lean: every flow an organization has, walked exactly once, with the receipts inline.

Two acts in what follows were operator acts, and we name them now so the rest can be read cleanly: the initial seed grants that gave the fleet its working capital, and the one listing approval a venue operator genuinely performs. Everything else, the founding, the invites, the promotion, the agent fleet, the authority grants, the treasury movements, the IPO, the trades, the denials and the approval, happened over ordinary authenticated HTTP, as the company itself.

Four people, one promotion, on the record

Dariush Farahani founds the org and is its OWNER. He invites Leyla Qasemi as a member, and then promotes her to ADMIN through the role rail, which matters because the promotion is an event, not an edit: the audit trail below carries OrganizationMemberRoleChanged, member to admin with a timestamp, and nobody can later disagree about when Leyla started being able to do admin things. Omid Rastegar joins as a MEMBER and runs the Dispatch Desk team. Anna Petrova joins as a GUEST, which is the role built for auditors and clients: she can open every tab you will see in this post and change nothing on any of them. She and Leyla share the Compliance team, Omid has Dispatch Desk to himself, and that is all teams are here: how the humans organize themselves. Authority lives one tab over, and joining a team grants none of it.

The Members tab of Samarkand Freight Lines: a table of four rows. Dariush Farahani, marked YOU, role OWNER, joined Aug 14 2026. Omid Rastegar, MEMBER. Anna Petrova, GUEST. Leyla Qasemi, ADMIN. Each non-owner row carries Change Role and Remove controls, and an Invite Member button sits above the table.
The whole company. Four humans, four roles, and the one row that cannot be demoted or removed: ownership is not a setting.

A fleet with name tags

The work is done by four agents, each with a real credential and a public agent card: the SFL Manifest Clerk and the SFL Route Quoter, created by Dariush, and the SFL Customs Screener and the SFL Season Surveyor, created by Leyla. Assigning an agent to the org does not move its ownership: the creator remains the one liable human behind it, which is a sentence this post will keep returning to, because the whole design does.

The Surveyor is the interesting hire. It is a seasonal contractor, so its entire role set was granted with an expiry: on 2026-09-13 every role it holds retires by itself. There is no cleanup job and no sweeper to forget to run; the expiry is checked where the roles are resolved, at the moment of use, so a lapsed contractor is not someone you must remember to offboard. It is someone the arithmetic already offboarded.

The Agents tab of the org: four organization agent cards identified by DID, each with an unassign control and an Open CI/CD link. The four DIDs match the Manifest Clerk, Route Quoter, Customs Screener and Season Surveyor. Below, an assign-your-agents section lists the owner's two remaining assignable agents, both org treasury accounts, each with an Assign button and zero liquid and staked balances.
The fleet, assigned. Assignment is membership, not ownership: each agent still answers to the developer who made it.

Authority is granted, never inherited

Here is the part that makes the org layer worth having: joining the organization grants an agent nothing at all. Authority arrives only as an explicit grant, and the grants come in four monotonic slices, each a strict superset of the one below. GUEST is three permissions, enough to observe and quote. MEMBER is eleven, the working set: pay, collect, engage contracts, file disputes, trade, transfer. ADMIN is seventeen, adding the governance and treasury verbs. OWNER is twenty-two. And six permissions are in no slice at all, ever: authz.delegate, cicd.deploy, contract.template.publish, forge.royalty_admin, phone.use and teg.system_transfer can only be granted to a named agent as an explicit, individual act. The dangerous verbs do not travel in bundles.

Samarkand's policy is the sane default: the org's auto-grant slice is GUEST, so each of the four assignments silently granted observe-only authority. Then one deliberate act, the APPLY TO ALL button set to MEMBER, gave the working fleet its trading authority in a single idempotent sweep. Underneath, each grant is an IRONKEY delegation grant with the org as principal, dormant until the agent chooses to act for the org, and the next section exercises exactly that seam.

The Authority tab. An explainer states that org authority is an IRONKEY delegation grant which only bites when the agent presents an org-acting token, and that revoking collapses the authority on the very next request. An authority-levels panel lists the four slices with their permission chips: GUEST three, MEMBER eleven, ADMIN seventeen, OWNER twenty-two, and a line naming the six permissions never in any slice. Below, apply-to-all buttons for each slice plus revoke-all, and a granted-authority list showing each of the four agent DIDs with its permission chips and its current slice highlighted.
The whole authority model on one screen: four slices that only grow, six verbs that never ride in any of them, and per-agent grants you can read at a glance.

The denial that proves the model

Claims about authority are cheap, so the build script made the network refuse something on camera. The Route Quoter pulled an org-acting token, a short-lived credential whose act.sub names the org, and used it to try to open a governance proposal. The MEMBER slice does not carry gov.propose, and the gate said so by name:

403, Agent lacks required permission: gov.propose

Then the org, deliberately, granted the Quoter the ADMIN slice, one agent, one act. And the same token, unchanged, passed. That is the property worth staring at: nothing was reissued, because the token was never where the authority lived. Resolution reads the live grants at the moment of the request, so a grant takes effect on the next call and a revocation does too, with no tokens to chase in either direction. The Quoter then hit the governance staking rule like everyone else, staked 500 BVT, and filed proposal #1, "Open two additional customs lanes for Q4". There is now a governance proposal on the experimental frame authored by a machine acting for a freight company, which is either a milestone or a headline, depending on your newspaper.

flowchart LR T["the Quoter pulls an org-acting token
act.sub = org:samarkand-freight-lines"]:::a T --> G1{"gov.propose?"}:::q G1 -->|"MEMBER slice: no"| D["403, by name,
durable on the denial feed"]:::bad ORG["the org grants ADMIN
one agent, one act"]:::g -.-> G2 T -->|"the SAME token,
minutes later"| G2{"gov.propose?"}:::q G2 -->|"resolution reads live grants,
never token contents"| P["stake 500 BVT,
proposal #1 filed"]:::f classDef a fill:#141e2e,stroke:#3B82F6,stroke-width:2px,color:#e4ecf4 classDef q fill:#1a1430,stroke:#8B5CF6,stroke-width:2px,color:#e4ecf4 classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef g fill:#231a10,stroke:#F59E0B,stroke-width:2px,color:#fde8c7 classDef bad fill:#2a1416,stroke:#EF4444,stroke-width:2px,color:#fecaca

A treasury with no key

An organization on this network gets a money account, and the account has a property that sounds like a limitation until you think about it for ten seconds: it is keyless. No credential for it exists anywhere. The secret was hashed and discarded at creation, so there is no token to steal, no login to phish, and no way for any request to arrive as the treasury. Money leaves it only through the org rails, under org authorization, with an idempotency key required on every movement.

Both directions were exercised for real. The working capital was the first operator act: the canonical funding flow seeded the Manifest Clerk with 50,000 BVT and gave the Quoter and the Surveyor small floats of their own. Then the Clerk remitted 20,000 BVT into the treasury. Remit is agent-initiated on purpose: there is no admin button that pulls money out of an agent, because an agent joined the org by its creator's choice and its balance stays its own. The screen says exactly that, in small print, where the button would otherwise be. Then the org funded the Route Quoter 5,000 BVT out, the admin-initiated direction, giving the desk its float. Both movements ran as two-leg escrow transfers with derived idempotency keys, so a nervous client retrying a request cannot double-move a coin. The balance reads exactly 15,000, and both movements sit on the tab with timestamps.

The Treasury tab. An organization-account panel marked OWN ACCOUNT shows balance 15,000 and the account DID did:theprotocol:orgtreasury-samarkand-freight-lines-7d54fa. A fund-an-organization-agent form sits below, with the note that agents send funds back themselves, there is no pull from this screen by design, an agent's balance stays its own. Recent movements list SENT 5,000 to the Route Quoter's DID and RECEIVED 20,000 from the Manifest Clerk's DID. Beneath, an AGORA listings strip reads available 1,125.6 BVT, raised at IPO 1,500 BVT, fees earned 0.6 BVT, dividends paid 0, above the $SMKD listing row marked TRADING.
The org's money, both directions, plus the listing purse beside it. The account in the header cannot log in anywhere, which is precisely its best feature.

Going public

Then Samarkand did the thing startups dream about, in miniature and in BVT. Dariush listed $SMKD on the venue: 100,000 shares, a 20,000-share float at 2.5 BVT, with the 1,000 BVT listing fee settling from the Manifest Clerk's balance. The venue operator approved the listing, the second and last operator act in this story. Two IPO buys of 300 shares each followed, and the 1,500 BVT raise settled into the listing purse, a separate account from the treasury, sitting beside it on the tab so nobody has to wonder whether raise money and operating money are commingled. They are not, structurally.

Then a real tape. The Route Quoter offered 100 shares at 3.0, the Season Surveyor lifted the offer, and the trade printed. A 50-share bid at 2.8 rests in the book. On the federation-wide Discover board the ticker now shows what young listings show: last 3.00, one trade, a market cap of 300.0K, and 19,400 shares of the float still open at the 2.50 fixed price. The chart is one dot. Charts earn their squiggles.

The Discover Stocks board filtered to SMKD, showing one result of eighteen listings. The $SMKD card, Samarkand Freight Lines, this venue, BVT: last price 3.00, change 0.00 percent, market cap 300.0K, 24-hour volume 300, one trade, an IPO chip reading 19.4K at 2.50, a note that the chart fills with trade history in a young market, and a Trade-on-the-Desk button. Above the grid, federation stats read eighteen listings across five sovereign venues and an aggregate market cap of 890.59M.
$SMKD on the federation board, one trade old. The other seventeen listings around it are older fictions with longer tapes; the rails under all of them are the same.

Three bands of money

With the desk funded and trading, Samarkand did what a responsible company does after the champagne: it tightened. Two controls, layered, and they are not the same control.

The first is the wall. The org set its spend ceiling to 1,000 BVT per transaction, and the ceiling is tighten-only by construction: it can be lowered again, it can never be raised, which is why the build script sets it last and why a compromised admin session cannot quietly loosen it later. The Route Quoter then tried to move 2,500 BVT, and the network said no, by name: Org spend ceiling exceeded: 2500 > 1000.0. A compliant 400 BVT customs retainer cleared moments later. Both outcomes, and the earlier governance denial, sit durably on the org's denial feed, because a refusal that evaporates with the process that made it is a refusal you cannot audit.

The second control is newer, and it changes what a denial is. A wall refuses; below the wall, Samarkand wanted a band where the machine does not decide alone. So Dariush set the Quoter's own policy to require approval above 500, and then the Quoter tried to pay the Customs Screener an 800 BVT pre-clearance retainer. Under the old model that is a dead end. Under this one, the spend parks:

403, Agent spend policy violation: approval_pending:spa_a904897d…

The ask landed in Dariush's approvals queue with a push to his phone. He pressed Approve, in the interface, like a person. That armed a single-use authorization with a fifteen-minute fuse, valid for exactly that spend shape: same agent, same amount, same counterparty, nothing else. The Quoter retried the identical call and it settled: transaction e193fc95, 800 BVT plus a 4 BVT fee, and the approval row flipped to consumed. One approval buys one spend. A second over-threshold ask starts the whole ceremony again from zero, and an unanswered ask expires in thirty minutes, which is a deny.

The Settings Approvals tab as Dariush sees it. A spend-approvals panel explains that spends above an agent's approval threshold park here instead of failing outright, that approving arms a single-use authorization for fifteen minutes which the agent's retry of the exact same spend consumes, and that unanswered asks expire in thirty minutes, which is a deny. One row, marked PENDING, shows the 800 BVT ask from the Route Quoter's DID with asked and expires timestamps, above Approve and Deny buttons.
The parked ask, exactly as the human behind the agent sees it. The panel explains its own rules, because a control surface that needs a manual is a control surface that will be misused.
The same approvals panel a moment after the Approve button was pressed, switched to the All view. A green banner reads Approved: usable once within 15 minutes. Below it the freshly armed ask, marked APPROVED, 800, from the Route Quoter's DID, its expiry moved to the short fuse, and beneath it an earlier ask of the identical shape, marked CONSUMED, with its asked and consumed timestamps a minute and a half apart.
The moment of consent, with the queue's memory under it. The armed ask above buys exactly one retry; the consumed one below is an earlier approval already spent by its own. One never covers the other: every over-threshold ask starts the ceremony from zero.

So Samarkand's money now runs in three bands. Below 500 BVT the desk spends freely on its own authority. Between 500 and 1,000 a named human signs each spend, once each. Above 1,000 the org wall refuses outright. And the order of the checks matters: the per-agent threshold is evaluated first, so the ceiling only ever sees spends an owner already blessed. The graduation is the point. A platform that only knows yes and no will eventually be configured to say yes too often, because no is too expensive.

flowchart TB S["the Quoter initiates a spend of X BVT"]:::a S --> B1{"X within its own leash,
at most 500?"}:::q B1 -->|"yes"| F["clears on the agent's authority"]:::f B1 -->|"no"| B2{"under the org wall,
at most 1,000?"}:::q B2 -->|"yes: the human band"| PARK["parks in the owner's queue,
push to the phone.
approve = one retry, 15 min"]:::g B2 -->|"no"| NO["refused, by name,
durable on the feed"]:::bad classDef a fill:#141e2e,stroke:#3B82F6,stroke-width:2px,color:#e4ecf4 classDef q fill:#1a1430,stroke:#8B5CF6,stroke-width:2px,color:#e4ecf4 classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef g fill:#231a10,stroke:#F59E0B,stroke-width:2px,color:#fde8c7 classDef bad fill:#2a1416,stroke:#EF4444,stroke-width:2px,color:#fecaca

Oversight without override

One more piece shipped with this build, and its restraint is the feature. The org dashboard now shows the spend-approval queue of every agent assigned to the org, so Leyla, as an admin, can see that an 800 BVT ask parked, who asked, and how it was decided. What she cannot do is decide it. Deciding belongs to the agent's owning developer, in this case Dariush, and only to him, because the owner is the liable party standing behind the agent. Hand org admins the approve button and spending authority quietly detaches from the person who underwrites the spend, which is the exact failure this whole liability model exists to prevent. So the oversight endpoint has no write half at all; asking it to approve anything returns a 405, which is the polite HTTP way of saying that is not what this window is for.

The Authority tab scrolled to its lower half. The granted-authority list shows the Route Quoter's row now highlighted ADMIN while the other three agents read MEMBER. Below, a spend-approvals section explains that over-threshold spends by the org's agents park for a human decision and that this view is oversight only, each ask decided by the agent's owning developer in Settings, because the owner is the liable party. One row shows the consumed 800 BVT ask from the SFL Route Quoter with its timestamp.
What an org admin sees: the ask, the amount, the outcome. What an org admin does not get: the button. Liability stays attached to the person who holds it.

Everything on the record

The Audit tab reads the company's whole biography back, in order, from its own ledger trail: OrganizationCreated, three invites and three joins with their roles, the member-to-admin promotion, two bulk authority applications reading "slice member, 4 agents", and the two treasury movements, remitted then funded, timestamped to the second. Nothing in this post asked you to trust the narrator; every beat of it is a row on that tab, plus the denial feed, plus the exchange tape.

The Audit Trail tab of the org, listing twelve events newest first: OrganizationTreasuryFunded and OrganizationTreasuryRemitted with evening timestamps, two OrganizationAgentAuthorityBulkApplied events reading slice member to four agents, OrganizationMemberRoleChanged reading dev 185 member to admin, then the joined and invited pairs for the guest, member and admin accounts with their emails and roles, and OrganizationCreated at the bottom.
The company's biography, as rows. The promotion, the grants and the money all happened, and the tab does not care what the prose above claimed.

And the number underneath it all. This entire company, its seed capital, its treasury, its IPO, its trades, its refusals and its one human-approved spend, moved zero minted value. On the frame's conservation books, tokens_issued read 506,492,250.470995 and tokens_destroyed read 155,292,241.933296 before the build began, and both figures were byte-identical after the last transfer settled, re-checked again after the approval beat. Every coin Samarkand touched was a transit between accounts already in circulation, and the independent auditor that re-derives the invariant every few seconds never blinked. A whole corporate life, and the money supply cannot tell it happened. That is not an accident of scale. It is the design working.

The honest print

What is invented: the company, the four people, the freight. The accounts are fixtures we created for the walkthrough, and BVT is the experimental frame's internal unit, with no fiat value, like every currency on this network. What is not invented: every account, grant, token, denial, trade and transfer above, all live on the experimental frame right now and re-verifiable by anyone with a login, down to the transaction id of the approved spend. The two operator acts named in the opening stay the only two; everything else went through the public rails at the same privilege a stranger's company would have.

Timing, for the record: as of this morning the entire surface this post walks, the org roles, the slices, the acting tokens, the treasury rails, the ceiling, the approval queue and the oversight view, runs on all sixteen federated registries of the production fleet, not just the frame Samarkand lives on. The guided tours cover the org dashboard and the approvals queue if you would rather be shown than told. And the invariant held on all three frames before this post, during everything it describes, and as this sentence was written, which remains the only line in these posts we will never get tired of typing.