Skip to content

Commit 154f453

Browse files
committed
docs: strengthen public README
1 parent 9097a8d commit 154f453

1 file changed

Lines changed: 204 additions & 69 deletions

File tree

README.md

Lines changed: 204 additions & 69 deletions
Original file line numberDiff line numberDiff line change
@@ -4,48 +4,140 @@
44

55
# Sub Rosa
66

7-
**Embeddable sealed-auction infrastructure for Stellar.** Bidders lock Stellar
8-
assets and submit bids that remain unreadable until a public Drand round. The
9-
Soroban contract then verifies the reveal and atomically exchanges the winning
10-
payment for the auction lot while refunding losing escrow.
7+
**Embeddable sealed-market infrastructure for Stellar.** Sub Rosa lets an
8+
application collect private bids or proposals, reveal them at a publicly
9+
verifiable time, and either settle assets atomically or produce a canonical
10+
receipt for an off-chain decision.
11+
12+
<p align="center">
13+
<a href="https://sub-rosa-web.vercel.app/">Live app</a> |
14+
<a href="https://sub-rosa-web.vercel.app/#/pilot/the-signal">Testnet pilot / deal flow</a> |
15+
<a href="https://sub-rosa-web.vercel.app/#/docs">Hosted docs</a> |
16+
<a href="./packages/sdk/README.md">SDK docs</a> |
17+
<a href="https://stellar.expert/explorer/testnet/contract/CCOVGOQQZJKZ2R55GRWBLTJTGBAMSHXZVN3ICPG3WRVMLMM6RHISC5OV">Testnet contract</a> |
18+
<a href="https://stellar.expert/explorer/public/contract/CDQOFNCJE5Z4ZZL76DU5652FOUKJVEIZWHFGCZVWH63UYBGPSZIPC325">Mainnet contract</a>
19+
</p>
1120

1221
Sub Rosa is a protocol and integration stack, not only a hosted application:
1322

14-
- a Soroban round contract with on-chain Drand BLS12-381 verification;
23+
- a Soroban sealed-round contract with on-chain Drand BLS12-381 verification;
1524
- a public TypeScript SDK with high-level partner templates;
16-
- a tlock package for deterministic sealed payloads;
25+
- a tlock package for deterministic time-locked payloads;
1726
- a permissionless keeper for reveal and settlement;
18-
- a hosted pilot UI and public receipts.
27+
- a hosted pilot UI with public lifecycle receipts.
1928

20-
The primary economic use case is an **asset-backed sealed auction**. A second
21-
`ReceiptOnly` template supports partners that need confidential proposals and a
22-
verifiable simultaneous reveal without putting funds in escrow.
29+
The project is licensed under [MIT](./LICENSE).
2330

24-
Licensed under [MIT](./LICENSE).
31+
## Status at a glance
32+
33+
| Surface | Current status |
34+
| --- | --- |
35+
| Core v2 testnet | Active, with settled `ReceiptOnly` and atomic auction proofs |
36+
| Core v2 mainnet | Official deployment active at the contract linked above |
37+
| Public SDK | `@sub-rosa/sdk`, named `testnet` and `mainnet` presets |
38+
| Hosted pilot | Standalone The Signal-style OTC and loan deal flow |
39+
| Production boundary | Independent funds-handling review still required before uncapped value |
40+
41+
Core v2 uses the same versioned payload envelope, Drand reveal gate,
42+
permissionless lifecycle, public read surface, and deterministic receipt model
43+
on both Stellar networks. An integrator chooses the network and signs for the
44+
matching contract; a testnet deployment is never silently used for mainnet.
45+
The hosted demo may be configured to testnet for safe pilots; its active network
46+
is shown in the UI. Mainnet support is available through the explicit SDK and
47+
deployment configuration documented below.
48+
49+
## Why Sub Rosa
50+
51+
Many applications need a fair private decision before they can safely execute
52+
an on-chain action. A public mempool exposes quotes too early; a trusted
53+
operator can change the outcome; a normal database cannot prove that every
54+
participant saw the same reveal boundary.
55+
56+
Sub Rosa provides the confidential competition primitive while leaving the rest
57+
of the workflow with the integrating application. It is designed to sit inside
58+
existing Stellar products rather than replace their discovery, identity,
59+
selection, payment, or escrow systems.
2560

2661
## Core v2 modes
2762

28-
| Mode | Intended use | Settlement |
63+
| Mode | Use it for | What the contract does |
2964
| --- | --- | --- |
30-
| `Auction` | High-value assets, collectibles, access rights, or other Stellar-native lots | Winner payment to seller and lot to winner in one settlement |
31-
| `ReceiptOnly` | Confidential proposal collection and design-partner pilots | No asset movement; canonical reveal receipt only |
65+
| `Auction` | Asset sales, grants, bounties, RFPs, access rights, and other lots that must settle on-chain | Holds the lot, enforces identical bidder escrow, verifies reveals, refunds losers, and atomically transfers the winning payment and lot |
66+
| `ReceiptOnly` | Confidential provider proposals, design-partner pilots, OTC quotes, and loan terms | Seals and reveals the proposal set, records a verifiable receipt, and moves no assets |
67+
68+
Both modes support open rounds or contract-enforced participant allowlists.
69+
`Auction` rounds require one identical public escrow amount for every bidder so
70+
the escrow cannot reveal relative bid sizes before the reveal gate. New partner
71+
workflows should be typed templates over these reviewed modes instead of custom
72+
settlement callbacks.
73+
74+
## How it fits into an application
75+
76+
```text
77+
Partner application
78+
|
79+
v
80+
Create a sealed round (Auction or ReceiptOnly)
81+
|
82+
v
83+
Participants submit encrypted payloads
84+
|
85+
v
86+
Drand round reaches the reveal boundary
87+
|
88+
v
89+
Permissionless open -> reveal -> clear
90+
|
91+
+--> Auction: contract settles the winning exchange
92+
|
93+
+--> ReceiptOnly: application compares the verified receipt and selects
94+
```
95+
96+
The operator cannot decrypt a payload before the configured Drand round. After
97+
the boundary, any account can advance the lifecycle. If reveal cannot complete,
98+
the contract exposes a grace-period void path that returns held assets.
3299

33-
Both modes use the same versioned payload envelope, Drand reveal gate,
34-
permissionless lifecycle, public read surface, and deterministic receipt model.
35-
Partner rounds can be open or contract-enforced allowlist rounds. Auctions also
36-
enforce one identical escrow amount for every bidder, so differing public
37-
escrow values do not leak relative bid sizes before reveal.
38-
New partner workflows should be expressed as typed templates over these reviewed
39-
modes rather than custom settlement callbacks.
100+
## Hosted deal-flow pilot
101+
102+
[Open the standalone pilot](https://sub-rosa-web.vercel.app/#/pilot/the-signal)
103+
104+
The hosted pilot is a The Signal-style validation surface built entirely on the
105+
Sub Rosa side. It demonstrates the deal flow without requiring a The Signal
106+
database, production-code change, or escrow integration:
107+
108+
1. An organizer creates an OTC or loan deal room.
109+
2. Providers submit private `ReceiptOnly` offers.
110+
3. The organizer chooses a deadline of `2 min`, `5 min`, `1 day`, or `15 days`.
111+
4. Offers remain sealed until the shared reveal boundary.
112+
5. The revealed receipt lets the organizer compare terms and choose a winner
113+
manually.
114+
115+
This is a named early-pilot and validation workflow, not a claim of production
116+
integration with The Signal. It is intentionally useful as a linkable demo
117+
while leaving settlement and business selection to the partner application.
118+
119+
## Ecosystem validation
120+
121+
- **Build on Stellar Istanbul 2026:** first place in the Hack Privacy track.
122+
- **Stellar ecosystem programs:** SCF and Instawards materials are backed by
123+
public Core v2 contracts, SDK integration, receipts, and a runnable pilot.
124+
- **The Signal:** early pilot and validation partner for the standalone
125+
confidential OTC and loan deal-flow pilot above.
126+
- **Open x402 / Ithaca Labs:** integration work is being explored around sealed
127+
provider bidding between MCP discovery and x402 payment.
128+
129+
These statements describe the current validation scope. They do not imply that
130+
partner production codebases, private databases, or payment rails have been
131+
modified by this repository.
40132

41133
## Public SDK
42134

43135
```bash
44136
npm install @sub-rosa/sdk
45137
```
46138

47-
The SDK includes the tlock and generated contract packages as versioned runtime
48-
dependencies. Integrators normally need only the SDK:
139+
The SDK includes the tlock and generated contract packages as version-matched
140+
runtime dependencies. Integrators normally need only the SDK:
49141

50142
```ts
51143
import {
@@ -79,20 +171,50 @@ const sealed = await sealAssetBid({
79171
amount: 700n,
80172
});
81173

82-
await client.submitV2({ roundId, sealed, escrow: 1_000n }); // must equal fixedEscrow
174+
await client.submitV2({ roundId, sealed, escrow: 1_000n });
83175
```
84176

85-
Switch to `network: "mainnet"` to use the canonical Core v2 deployment on the
86-
Stellar public network. An explicit reviewed `contractId` remains supported
87-
for caller-owned deployments. The signer supplied by the integrator pays each
88-
submitted transaction's network fee; Sub Rosa does not subsidize SDK calls by
89-
default.
177+
Use `network: "mainnet"` for the canonical Core v2 public-network deployment.
178+
Browser integrations pass a wallet public key and signing callbacks instead of
179+
placing a secret key in the frontend:
90180

91-
See [packages/sdk/README.md](./packages/sdk/README.md) for both integration
92-
templates and [docs/INTEGRATION.md](./docs/INTEGRATION.md) for lifecycle,
93-
preflight, keeper, and deployment guidance.
181+
```ts
182+
const client = new SubRosaClient({
183+
network: "mainnet",
184+
publicKey: walletAddress,
185+
signTransaction: wallet.signTransaction,
186+
signAuthEntry: wallet.signAuthEntry,
187+
});
188+
```
94189

95-
## Lifecycle
190+
An explicit reviewed `contractId` remains supported for caller-owned
191+
deployments. The SDK checks the RPC passphrase and contract existence before
192+
simulation, signing, or submission, and exposes successful hashes through
193+
`client.submittedTransactionHashes`.
194+
195+
See [packages/sdk/README.md](./packages/sdk/README.md) for proposal templates,
196+
preflight helpers, browser signing, and custom network configuration. See
197+
[docs/INTEGRATION.md](./docs/INTEGRATION.md) for the full lifecycle and keeper
198+
flow.
199+
200+
## Networks, signing, and fees
201+
202+
| Network | SDK setting | Who pays the Stellar fee? |
203+
| --- | --- | --- |
204+
| Stellar Testnet | `network: "testnet"` | The source account that signs the transaction |
205+
| Stellar Mainnet | `network: "mainnet"` | The source account that signs the transaction |
206+
207+
The application must use the contract, RPC, and network passphrase for the
208+
same network. Contract escrow and lot custody are separate from network fees.
209+
Sub Rosa does not subsidize SDK calls by default; an application can add a
210+
relayer if it explicitly wants sponsored fees, in which case that relayer pays.
211+
212+
Repository deployment and capped smoke scripts require an explicit
213+
`MAINNET_CONFIRM=SUB_ROSA_MAINNET` confirmation and funded operator/bidder
214+
accounts. That safety gate applies to those scripts, not as a hidden cap on
215+
wallet-signed SDK integrations.
216+
217+
## Lifecycle and receipts
96218

97219
```text
98220
Create round
@@ -104,12 +226,11 @@ Create round
104226
-> public receipt
105227
```
106228

107-
If reveal cannot complete, the contract exposes a grace-period void path that
108-
returns held assets. The operator cannot decrypt submissions before `R` and
109-
does not control who is allowed to advance the lifecycle after `R`.
110-
111-
See [ARCHITECTURE.md](./ARCHITECTURE.md) for system boundaries and
112-
[docs/THREAT_MODEL.md](./docs/THREAT_MODEL.md) for residual risks.
229+
`Auction` settlement transfers the winning payment to the seller, returns the
230+
winner's unused escrow, refunds losing escrow, and transfers the lot to the
231+
winner. `ReceiptOnly` produces a canonical reveal receipt but makes no business
232+
decision and moves no assets. Applications that need ledger provenance should
233+
verify the receipt and query the configured Stellar contract directly.
113234

114235
## Verified artifacts
115236

@@ -119,30 +240,51 @@ See [ARCHITECTURE.md](./ARCHITECTURE.md) for system boundaries and
119240
| --- | --- |
120241
| Contract | [`CCOVGOQQZJKZ2R55GRWBLTJTGBAMSHXZVN3ICPG3WRVMLMM6RHISC5OV`](https://stellar.expert/explorer/testnet/contract/CCOVGOQQZJKZ2R55GRWBLTJTGBAMSHXZVN3ICPG3WRVMLMM6RHISC5OV) |
121242
| WASM hash | `2c7bc6b4c91940ac185df38a3d0a8532b555140d818df94f03f894e5952ebf42` |
122-
| Proposal proof | Round `2` - allowlisted `ReceiptOnly` - settled and receipt verified |
123-
| Atomic auction proof | Round `3` - fixed escrow - `20 SRUSD` to seller and `1 SRLOT` to winner |
243+
| Proposal proof | Round `2` - allowlisted `ReceiptOnly`, settled and receipt verified |
244+
| Atomic auction proof | Round `3` - fixed escrow, `20 SRUSD` to seller and `1 SRLOT` to winner |
124245

125-
### Mainnet protocol proof
246+
### Core v2 mainnet
126247

127248
| Field | Value |
128249
| --- | --- |
129-
| Contract | [`CA7KSDEYJEPGZEB2ZROTLUWKQQ6GIRIQNGG6Z745MZ34QHP4UJPWODEX`](https://stellar.expert/explorer/public/contract/CA7KSDEYJEPGZEB2ZROTLUWKQQ6GIRIQNGG6Z745MZ34QHP4UJPWODEX) |
130-
| Round | `1` - settled |
131-
| Asset | Native XLM SAC |
132-
| Scope | Legacy v1 settlement smoke, not a Core v2 production deployment |
250+
| Contract | [`CDQOFNCJE5Z4ZZL76DU5652FOUKJVEIZWHFGCZVWH63UYBGPSZIPC325`](https://stellar.expert/explorer/public/contract/CDQOFNCJE5Z4ZZL76DU5652FOUKJVEIZWHFGCZVWH63UYBGPSZIPC325) |
251+
| Deployment transaction | [`349fe1094c544a88a8ad862a26047f4acd537d77a1aef4d14805ad6827768094`](https://stellar.expert/explorer/public/tx/349fe1094c544a88a8ad862a26047f4acd537d77a1aef4d14805ad6827768094) |
252+
| Network | Stellar public network (Mainnet) |
253+
| WASM hash | `2c7bc6b4c91940ac185df38a3d0a8532b555140d818df94f03f894e5952ebf42` |
254+
| SDK | `network: "mainnet"` selects this Core v2 deployment |
133255

134-
### Core v2 mainnet
256+
The mainnet deployment is public and capped in the repository's deployment
257+
workflow. It has not received an independent funds-handling audit. Use explicit
258+
value and participant limits, monitored keepers, and a reviewed contract/hash
259+
before any production or uncapped integration.
260+
261+
### Historical mainnet proof
135262

136263
| Field | Value |
137264
| --- | --- |
138-
| WASM hash | `2c7bc6b4c91940ac185df38a3d0a8532b555140d818df94f03f894e5952ebf42` |
139-
| SDK support | `network: "mainnet"` with an explicit reviewed Core v2 contract ID |
140-
| Official deployment | `CDQOFNCJE5Z4ZZL76DU5652FOUKJVEIZWHFGCZVWH63UYBGPSZIPC325` |
141-
| Safety | Mainnet writes require an explicit confirmation phrase and micro-value caps |
265+
| Contract | [`CA7KSDEYJEPGZEB2ZROTLUWKQQ6GIRIQNGG6Z745MZ34QHP4UJPWODEX`](https://stellar.expert/explorer/public/contract/CA7KSDEYJEPGZEB2ZROTLUWKQQ6GIRIQNGG6Z745MZ34QHP4UJPWODEX) |
266+
| Round | `1` - settled native XLM smoke |
267+
| Scope | Legacy v1 evidence only; never use it as the Core v2 contract |
268+
269+
## Security boundary and current limits
142270

143-
Core v2 has verified testnet proofs and a capped Core v2 mainnet deployment.
144-
Funds-handling contracts require independent review before a production or
145-
uncapped mainnet integration.
271+
Sub Rosa reduces early information leakage and makes the reveal boundary
272+
verifiable. It does not provide identity, KYC, legal enforceability, business
273+
underwriting, or a guaranteed keeper service.
274+
275+
- `ReceiptOnly` does not escrow, transfer, or select assets.
276+
- Provider selection in the hosted The Signal pilot remains an organizer
277+
decision outside the contract.
278+
- A missed reveal window follows the contract's grace-period void path; pilots
279+
should monitor liveness and define incident ownership.
280+
- The SDK cannot make an unknown deployment trustworthy. Pin the network,
281+
contract ID, and expected WASM hash.
282+
- Independent Soroban funds-handling review is required before uncapped
283+
mainnet value.
284+
285+
See [ARCHITECTURE.md](./ARCHITECTURE.md),
286+
[docs/THREAT_MODEL.md](./docs/THREAT_MODEL.md), and
287+
[docs/LIMITATIONS.md](./docs/LIMITATIONS.md).
146288

147289
## Monorepo
148290

@@ -153,8 +295,8 @@ packages/tlock/ Drand tlock and auditor encryption
153295
packages/sdk/ Public integration SDK and templates
154296
services/keeper/ Permissionless lifecycle automation
155297
services/auction-template/ Reference auction integration
156-
apps/web/ Hosted pilot and receipt UI
157-
docs/ Current technical and partner documentation
298+
apps/web/ Hosted pilot, docs, and receipt UI
299+
docs/ Technical, security, and partner documentation
158300
```
159301

160302
## Development
@@ -171,23 +313,16 @@ pnpm sdk:test
171313
pnpm sdk:typecheck
172314
pnpm packages:build
173315
pnpm packages:pack
316+
pnpm web:test
317+
pnpm web:typecheck
174318
pnpm web:build
319+
pnpm docs:check
320+
pnpm docs:check-links
175321
```
176322

177323
Live network scripts require explicit Stellar keys and configuration. Read
178-
[docs/DEPLOY.md](./docs/DEPLOY.md) before running a value-moving command.
179-
180-
## Partner readiness
181-
182-
The software is ready for repeatable testnet pilots when a partner can use a
183-
hosted link or the SDK without a protocol rewrite. Product evidence is a
184-
separate milestone and must include external participants, public round IDs,
185-
partner feedback, and a written next-step decision.
186-
187-
The project does not describe an interested team as a completed pilot and does
188-
not describe testnet settlement as audited production usage. See
189-
[docs/PLATFORM_PLAN.md](./docs/PLATFORM_PLAN.md) and
190-
[docs/PILOT_PLAYBOOK.md](./docs/PILOT_PLAYBOOK.md).
324+
[docs/DEPLOY.md](./docs/DEPLOY.md) before running a value-moving command. Never
325+
commit secret keys, recovery phrases, or local deployment artifacts.
191326

192327
## Documentation
193328

0 commit comments

Comments
 (0)