Paper Company, Real Money
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.