100-shares.rst (20153B)
1 DD 100: Share Tokenization 2 ########################## 3 4 :Design status: Draft 5 :Implementation status: Not started 6 :DD shepherd: TBD 7 :Historical contributors: Christian Grothoff 8 :First published: 2026-08-09 9 :Last substantive change: 2026-10-24 10 11 Summary 12 ======= 13 14 This document specifies how GNU Taler can tokenize shares in companies, how 15 such shares can be traded and how dividends are paid out. Share positions are 16 represented by share tokens held in the users' wallets, the merchant backend 17 provides the cryptographic machinery for the issuance, transfer and renewal of 18 those tokens, and the Taler exchange continues to process the 19 electronic-money payments used to buy shares and to receive dividends. 20 21 For *registered* shares (*Namensaktien*) the design adds a share register that 22 keeps the authoritative record of the registered shareholders and of the number 23 of shares attributed to each of them. The register is maintained by the issuer 24 or by an operator designated by the issuer. Here the central principle is that 25 share tokens only represent share positions *technically*: a change of the 26 registered ownership of a share is processed by the share register. A transfer 27 request starts the registration process, and only a successful registration 28 triggers the issuance of share tokens to the buyer. 29 30 Motivation 31 ========== 32 33 Taler can tokenize assets other than fiat-money or crypto-currencies. 34 One asset class that could be particularly promising are shares in 35 companies. This design document specifies how Taler could be used to 36 tokenize shares and pay out dividends. 37 38 For registered shares, the system must additionally associate every share 39 position with an identified shareholder and keep a reliable record of the 40 changes of ownership. Simply moving bearer-style tokens from one wallet to 41 another would not by itself keep the wallet balances and the shareholder 42 register synchronized. The design therefore introduces an explicit 43 registration step into the share transfer protocol: this retains the 44 cryptographic and payment-processing mechanisms of GNU Taler while maintaining 45 a separate, auditable shareholder register. 46 47 Requirements 48 ============ 49 50 - emit shares for fiat money (raising capital), showing investor brief / shareholder agreement before purchase 51 - sell shares for fiat money to new shareholders 52 - buy shares for fiat money from existing shareholders 53 - issue dividends from the business to shareholders 54 - notify shareholders about business developments, such as shareholder meetings 55 56 Enabling shareholders to vote (e-voiting) on business decisions is out of 57 scope for this initial design and left for a future design document. 58 59 For registered shares, the system must additionally be able to: 60 61 - register shareholders following a successful identity verification 62 - record the allocation of newly issued shares to identified shareholders 63 - represent the registered share positions using share tokens 64 - initiate a transfer by presenting or transferring share tokens through the 65 share-transfer protocol 66 - verify the identity and the eligibility of the recipient before a transfer is 67 completed 68 - update the shareholder register before replacement share tokens are issued to 69 the recipient 70 - prevent the same share tokens from being used in multiple concurrent 71 transfers 72 - exchange share tokens of one generation for tokens of the next generation 73 while paying the corresponding dividend 74 - maintain an auditable history of share issuances, transfers, redemptions and 75 dividend distributions 76 - reconcile the shareholder register, the issued share tokens and the completed 77 transactions 78 79 Electronic-money payments continue to use the existing Taler exchange: 80 share-specific functionality must not be implemented as a new asset class 81 inside the exchange itself (see `Alternatives`_). 82 83 Proposed Solution 84 ================= 85 86 Share Tokens, Frontend and Order Book 87 ------------------------------------- 88 89 Shares are something a new frontend allows users to buy and sell 90 (or the company to emit) using a traditional merchant backend for 91 the cryptographic part: 92 93 - add new token family "shares" in the merchant backend; it includes 94 new meta-data for wallets to learn about notifications and dividends 95 from the (new) frontend 96 - share token families have a generation, like 2024 and 2025, where 97 the contract for selling 2024 tokens for 2025 tokens yields 98 the dividend (see below) 99 - merchant backend tracks number of shares issued and bought back, 100 thus knows number of shares outstanding 101 - buying shares is a regular v1 contract with share tokens as outputs 102 and Taler payments in digital cash are inputs; the token family 103 references the shareholder agreement (must not be forgotten with the 104 purchase details) 105 - new frontend includes endpoints to send notifications to wallets 106 for issued shares, such as dividend notifications or shareholder 107 meeting announcements; wallets should request updates at a 108 frequency specified with the token family; all notifications are 109 ordered (numerically), with an endpoint to list all notifications 110 past a given serial ID, and another to download each of the 111 (historic) notifications; once issued, notifications never change; 112 notifications are signed by a long-term frontend key; note that 113 we probably want these announcements to be managed by the merchant 114 backend as a new feature: this way, all of the auditing can focus 115 just on the merchant backend 116 117 Notification endpoint ownership is therefore an open design decision: the 118 initial frontend-owned proposal and the merchant-backend alternative above 119 must be resolved before the API is specified. 120 121 - new frontend includes its own wallet; it is used to pay dividends; 122 wallets can request a contract to sell generation X shares for 123 generation X+1 shares (once a notification has been posted that 124 dividends for generation X shares are available). In that contract, 125 the wallet_data includes either a p2p-pull request that tells the 126 frontend where to pay the dividend (from its local wallet); 127 note that the frontend probably should handle the case where the 128 local wallet does not have the required balance and merely exports 129 the list of p2p-pull requests instead of executing them immediately 130 - new frontend tracks order-book with buy and sell orders, allowing 131 share owners to indicate the number of shares they want to buy or 132 sell at a certain price; these bids must be *backed* by tokens 133 (money or shares) with signatures to buy or sell the respective 134 amount of stock at the given price; double-spending is NOT yet 135 detected when the order is made, but deferred up to the moment 136 where the order would be executed; here the frontend would use 137 a transient wallet: the buy order would be for an already 138 signed contract to buy shares, the sell order would include a 139 p2p-pull request to be satisfied; by giving the buyer the new 140 shares the frontend would be paid (into its bank account) and 141 could then (possibly delayed) use those funds to satisfy the 142 p2p-pull request from the seller; as above, a frontend-integrated 143 wallet may be able to immediately pay the p2p-pull requests (if 144 its balance is sufficient), or the p2p-pull requests are exported 145 to the administrator to be executed later 146 - new frontend allows admin to emit new shares (picks best bids from 147 order-book at the deadline, possibly conditional upon top N-bids 148 exceeding minimum investment, or top N-bids being above minimum 149 price) 150 - all requests are stored, and there is a new merchant auditor that 151 inspects the share transaction data and checks if all p2p-pull requests 152 have been paid out (the existing merchant backend reconciliation 153 logic should naturally already check the incoming deposits). 154 Note that the order book itself probably does NOT need to be in 155 the merchant backend, but we could keep it there as well (to keep 156 the new frontend "stateless"; in that case, we'd also want to track 157 the p2p-pull requests in the merchant backend) 158 159 Registered Shares 160 ----------------- 161 162 For registered shares, the design separates three functions: 163 164 - the share register maintains the authoritative record of the registered 165 shareholders and of their share positions 166 - the merchant backend and the share-token functionality handle the issuance, 167 the transfer requests and the renewal of share tokens 168 - the Taler exchange processes the electronic-money payments used to purchase 169 shares and to receive dividends 170 171 Shareholder Register 172 -------------------- 173 174 A new share register service maintains the shareholder records and the share 175 positions. Every shareholder has a unique internal identifier that is 176 associated with a verified customer identity. The service stores the 177 information required for the register and keeps a history of all changes. 178 179 The register contains at least: 180 181 - the shareholder identifier and the required shareholder information 182 - the relevant share class 183 - the number of shares attributed to each shareholder 184 - the registration date and the applicable effective date of each change 185 - references to the transactions that caused each change 186 187 The register must support reconstructing the shareholder positions at an 188 earlier point in time. The current position may be stored as a materialized 189 balance, but every change must be traceable to a recorded register event. 190 191 The register is authoritative for determining which shareholder is recorded as 192 holding a given number of shares. Wallet balances must not be used as a 193 substitute for the register. 194 195 Share Issuance 196 -------------- 197 198 Shares are purchased through the new web frontend, which uses the merchant 199 backend for the purchase order and for the payment. The buyer must have a 200 verified customer identity before a purchase can be completed. 201 202 For example, a customer purchases ten shares at EUR 100 each: 203 204 1. the frontend creates a purchase order for ten shares 205 2. the customer pays EUR 1000 using their Taler wallet 206 3. the merchant backend confirms the successful payment 207 4. the share register service verifies the purchase order, the customer 208 identity, the payment reference and the availability of shares 209 5. the service records the allocation of ten shares to the shareholder 210 6. only following the successful registration does the share-token 211 functionality issue ten share tokens into the buyer's wallet 212 213 Share Transfer 214 -------------- 215 216 A transfer begins when a shareholder initiates a transfer of share tokens to 217 another party. Such a transfer is treated as a *request* to sell or transfer 218 the corresponding share position, and not as an unconditional transfer of the 219 registered shares. 220 221 The transfer protocol proceeds as follows: 222 223 1. the seller initiates a transfer of a given number of share tokens (sending 224 share tokens to another wallet, possibly as a share/money swap) 225 2. the share backend creates a unique transfer request and reserves the 226 corresponding tokens, or otherwise prevents their concurrent use 227 3. the recipient is identified and verified against the applicable eligibility 228 requirements; the recipient's wallet must be bound to a verified customer 229 identity (see `Identity and Privacy`_) 230 4. the share register service checks the seller's registered position, the 231 requested quantity and any applicable transfer restrictions 232 5. if all required conditions are satisfied, the register records the change of 233 the shareholder attribution 234 6. the successful register event triggers the issuance of the corresponding 235 share tokens to the buyer 236 7. the transfer is marked as completed once the token issuance has been 237 confirmed 238 239 For example, a shareholder holding ten shares transfers five shares to another 240 registered shareholder. Before the transfer, the register records ten shares 241 for the seller and none for the buyer; after the successful registration, it 242 records five shares for each of them. The seller retains five share tokens and 243 the buyer receives five newly issued share tokens. 244 245 The buyer's tokens must not be issued before the register change has succeeded. 246 If the registration fails, the system must not issue tokens to the buyer; the 247 transfer request must then either be safely retried or cancelled, with any 248 reservation released according to the transfer protocol. The transfer process 249 must prevent double-spending and must ensure that two concurrent requests 250 cannot transfer the same registered share position twice. 251 252 Share Register Events 253 --------------------- 254 255 Every register change is recorded as an immutable event. Events include: 256 257 - the initial share issuance 258 - the allocation of newly issued shares 259 - a transfer between shareholders 260 - a share buyback or cancellation 261 - a correction of a previously recorded event 262 - any other change affecting a shareholder's position 263 264 An event records the affected shareholders, the share class, the quantity, the 265 effective time, the recording time and the corresponding transaction 266 identifier. Corrections are represented by additional events rather than by 267 silently overwriting historical records. The service maintains the current 268 share positions derived from these events and provides the audit trail used for 269 reconciliation. 270 271 Dividends and Share Token Generations 272 ------------------------------------- 273 274 As described above, share tokens have a generation, such as 2026 or 2027, which 275 identifies the token series used for a particular dividend distribution period. 276 When a dividend becomes available, a notification identifying the relevant 277 generation and distribution is published, and a wallet holding tokens of 278 generation X may then request a contract to exchange those tokens for 279 generation X+1 tokens. 280 281 For registered shares, the share backend determines the number of shares 282 eligible for the distribution and the corresponding dividend amount from the 283 shareholder register and the applicable entitlement rules, and not merely from 284 the number of tokens presented by the wallet. 285 286 For example, a shareholder holds ten shares and is entitled to a dividend of 287 EUR 1 per share. The refresh then results in: 288 289 - ten tokens of generation X being redeemed 290 - ten tokens of generation X+1 being issued 291 - EUR 10 being paid into the shareholder's wallet as ordinary Taler digital 292 cash 293 294 The share position itself remains unchanged: only the token generation changes, 295 and the dividend is paid separately. The backend must ensure that each 296 dividend entitlement can be claimed only once. It must also handle transfers 297 and refresh requests consistently around the applicable dividend entitlement 298 date. 299 300 Separation of Components 301 ------------------------ 302 303 The share register service is introduced precisely so that the exchange is not 304 overloaded with share-specific responsibilities. The components have the 305 following responsibilities: 306 307 - **web frontend**: the user interface for share purchases, transfers and 308 shareholder information, including the relevant legal documents 309 - **merchant backend**: purchase orders, payment references and the integration 310 with Taler's contract and token mechanisms 311 - **share register service**: the shareholder records, the validation of 312 register changes, and the decision when a token issuance may proceed 313 - **share-token functionality**: issuance, redemption and refresh of share 314 tokens, and the coordination of the associated transfer and dividend 315 operations 316 - **exchange**: the electronic-money operations, that is the purchase payments 317 and the dividend payouts 318 319 The share register service and the share-token functionality may initially be 320 implemented as components of the same application, provided that their 321 responsibilities and their data integrity requirements remain clearly 322 separated. 323 324 Data Model 325 ---------- 326 327 The implementation requires persistent records for: 328 329 - shareholders and their verified customer identities 330 - share classes and issued shares 331 - the current shareholder positions 332 - purchase orders and the associated payments 333 - share transfer requests and their states 334 - share register events 335 - share token generations and issuance records 336 - dividend distributions and individual entitlement claims 337 - token refresh operations and electronic-money payouts 338 339 Every operation must have a unique identifier that connects the relevant 340 payment, register event and token operation. 341 342 Identity and Privacy 343 -------------------- 344 345 The share register uses the customer identity established through the 346 applicable verification process. Wallet identifiers are associated with 347 customer identities through explicit backend records; a wallet identifier alone 348 must not be treated as proof of a shareholder's identity. 349 350 Identity information should only be exposed to the components that require it. 351 The token protocols should use transaction references and other strictly 352 necessary technical identifiers instead of unnecessarily distributing personal 353 information. 354 355 Audit and Reconciliation 356 ------------------------ 357 358 In addition to the merchant auditor described above, the system must support 359 reconciliation between: 360 361 - the shareholder register 362 - the issued and redeemed share tokens 363 - the pending and completed transfer requests 364 - the purchase payments 365 - the dividend entitlements and payouts 366 367 The reconciliation process must identify discrepancies such as missing token 368 issuances, incomplete transfers, duplicate processing attempts and unpaid 369 dividend obligations. 370 371 A transfer or dividend operation must not be considered complete merely because 372 a request was submitted: completion requires the relevant register and token 373 operations to have reached their defined successful states. 374 375 Test Plan 376 ========= 377 378 - backend logic to issue, sell, buy shares 379 - pay out dividends 380 - wallet-core and wallet-UI tests 381 - initial issuance of shares following a successful payment and registration 382 - rejection of purchases by customers that do not satisfy the eligibility 383 requirements 384 - transfers between registered shareholders 385 - rejection of transfers to ineligible recipients 386 - concurrent transfer requests involving the same tokens 387 - failed registration with safe cancellation or retry 388 - repeated processing of the same registration event without duplicate issuance 389 - refresh from one share-token generation to the next 390 - correct dividend calculation and payout 391 - reconciliation between register positions and token issuance records 392 - recovery following a service interruption between registration and token 393 issuance 394 395 Definition of Done 396 ================== 397 398 - shares can be purchased using ordinary Taler digital cash 399 - a successful purchase results in a registered shareholder position and in the 400 corresponding share tokens 401 - transfers initiate a registration process and do not issue tokens to the 402 recipient before the registration succeeded 403 - failed transfers do not create additional share tokens 404 - a refresh replaces the previous token generation and pays the corresponding 405 dividend without changing the underlying share position 406 - all operations can be audited and reconciled 407 - the wallet and the merchant backend can recover safely from retries and 408 interruptions 409 410 Alternatives 411 ============ 412 413 - Using the exchange as the emitter of shares; not so good as it is 414 single-currency by design and not setup for dealing with purchases; 415 it might make p2p transfers easier, but regulation on trading is 416 different for shares and the mismatch is likely big enough that 417 not overloading the exchange code with is it is a good idea. 418 - Transferring bearer-style share tokens between wallets without a 419 registration step; this does not provide the synchronization between wallet 420 balances and the shareholder register that registered shares require. 421 422 Drawbacks 423 ========= 424 425 426 427 Open Questions 428 ============== 429 430 The implementation must be reviewed against the applicable corporate-law and 431 securities-law requirements before deployment. The design separates the 432 technical representation of the shares from the shareholder register, but that 433 separation alone does not establish the legal classification of the tokens or 434 the regulatory status of the resulting system. 435 436 Discussion / Q&A 437 ================ 438 439 (This should be filled in with results from discussions on mailing lists / personal communication.)