UTXO-based type model — no scripting engine
Single-key ECDSA secp256k1 with compressed pubkeys and mandatory LOW-S enforcement. BIP143-simplified sighash with genesis hash for replay protection.
Rational fee-rate ordering (fee/size as integer ratio, no floating point). MIN_RELAY_FEE: 1 stock/byte. Mempool prioritizes by fee-rate.
Full UTXO tracking with ConnectBlock/DisconnectBlock for reorg support. BlockUndo preserves spent outputs for chain reorganization.
Up to 256 inputs and 256 outputs per transaction (consensus). Policy limits: 128 inputs, 32 outputs.
1000-block maturity (~7 days). Constitutional 50/25/25 split: miner, Gold Vault, PoPC Pool. Immutable at genesis.
| MAX_BLOCK_BYTES | 1,000,000 |
| MAX_TX_BYTES | 100,000 consensus / 16,000 policy |
| COINBASE_MATURITY | 1000 blocks |
| MIN_RELAY_FEE | 1 stock/byte |
| DUST_THRESHOLD | 10,000 stocks |
| MAX_INPUTS | 256 consensus / 128 policy |
| MAX_OUTPUTS | 256 consensus / 32 policy |
Time-locked output. Funds locked until specified block height. 8-byte payload: lock_until as uint64_t LE. Used by PoPC Model B for custody bonds.
Escrow with designated beneficiary. 28-byte payload: lock_until[8] + beneficiary_pkh[20]. Used by Materials Discovery Engine for access deposits.
Structured metadata in OUT_TRANSFER outputs. 12-byte header + up to 243-byte body. Types: open notes, sealed notes, document references, certificate instructions. Encryption: ECIES-secp256k1-AES256-GCM or X25519-AES256-GCM.
These features represent potential future upgrades to the SOST transaction architecture. Implementation will follow the type-based activation pattern established by BOND_LOCK and ESCROW_LOCK. No timeline commitments are made. Each upgrade requires a consensus change and will only be deployed after thorough testing, formal verification where applicable, and community review. SOST prioritizes correctness and security over feature velocity.
| Aspect | Bitcoin (Script) | SOST (Types) |
|---|---|---|
| Model | Stack-based scripting | Fixed output types |
| Flexibility | Arbitrary programs | One type per capability |
| Attack surface | Large (script injection, witness malleability) | Minimal (no interpreter) |
| Validation speed | Variable (script execution) | Fast (type switch) |
| New features | Soft fork (new opcodes) | Hard fork (new output type) |
| Smart contracts | Limited (Bitcoin Script Turing-incomplete) | None (not a goal) |
SOST chose a type-based model to minimize attack surface and maximize validation speed. Each transaction capability is a distinct output type with consensus-defined semantics. New capabilities activate at predetermined block heights, following the pattern established by BOND_LOCK at height 5000. This design trades flexibility for safety — SOST is a payment chain with constitutional reserves, not a smart contract platform.