text:
**WARNING:** This is a draft document dated 28 February 2016. It is under review and is definitely **not finalized!** If you'd like to stay updated, consider joining the Hypergolix [mailing list](https://www.hypergolix.com/#page-top).

**SPECIAL WARNING:** This protocol should not be used for private data in a production environment until subjected to a third-party audit. Until that time, consider all Golix information to be fully public.

**NOTE:** This is a purely implementation document. For design discussion, see our [design document](/design_philosophy.md). For technical discussion, see our [whitepaper](/whitepaper.md). For security discussion, see [here](security-whitepaper.md).

# Cipher suites and address algorithms

**Note that this is not a substitute for a proper threat model or security analysis.** Those documents have been separated from the protocol specification for readability and digestibility purposes.

## Cipher suites

By Golix integer representation:

+ **0x0:** None. Reserved for testing and development purposes.
+ **0x1:** SHA512/AES256/RSA4096.
  **Signature:** RSASSA-PSS, MGF1+SHA512, public exponent 65537. Salt length 64 bytes.
  **Asymmetric encryption:** RSAES-OAEP, MGF1+SHA512, public exponent 65537.
  **Symmetric encryption:** AES-256 in **CTR mode with nonce distributed privately with the key**
  **Symmetric shared secrets:** Elliptic curve Diffie-Hellman using Curve25519.
  **Key agreement from shared secret:** HKDF+SHA512. Salt with bitwise XOR of the the address components of the two parties' GHIDs.
  **Symmetric signatures / MAC:** HMAC+SHA512
+ **0x2:** SHA512/AES256/RSA4096.
  **Signature:** RSASSA-PSS, MGF1+SHA512, public exponent 65537. Salt length 64 bytes.
  **Asymmetric encryption:** RSAES-OAEP, MGF1+SHA512, public exponent 65537.
  **Symmetric encryption:** AES-256 in **SIV mode (formally AEAD_AES_SIV_CMAC_512)**
  **Symmetric shared secrets:** Elliptic curve Diffie-Hellman using Curve25519.
  **Key agreement from shared secret:** HKDF+SHA512. Salt with bitwise XOR of the the address components of the two parties' GHIDs.
  **Symmetric signatures / MAC:** HMAC+SHA512

**WARNING:** Ciphersuite **0x2** is likely to be removed and replaced in the near future. Implementations should not expect its definition to stay stable, and should instead rely upon **0x1** until future notice.

**Quick note:** Why not elliptic curves first? Basically, development resource allocation. There was a reasonably large amount of thought put into this decision, and I stand by it. We need a prototype that works and is suitably secure for alpha testing. ECC is a very high priority for the production standard. If you want to discuss this further, please [get in contact directly](mailto:badg@muterra.io). We'd like to experiment some with the **0x1** ciphersuite, and make sure integrated packaging of nonce+key works how we'd like it to, and from there we will likely replace **0x2** with curve25519/ed25519/ecies.

**Quick note 2:** Why not an AE/AEAD block mode? The added complexity doesn't make sense in this application. Dynamic bindings don't use symmetric encryption, and everything else is non-malleable. There's already a hash, and a signature, on top of the existing non-malleability, for GEOC records. CTR is very simple, which makes it much harder to screw up.

**Quick note 3:** Investigating alternative stream ciphers is on our long-term horizon, as are highly-performant (symmetric only) one-to-one pipes. For now, the best route for performant streams is to use Golix to negotiate secret keys for lower-level transport sockets (etc) directly between hardware.

### CTR vs SIV

Relevant details:

1. key/access control is separate from content containers
2. all resources are content-addressed by their hash digests
3. the protocol is transport agnostic, so traffic analysis, etc are deliberately out-of-scope

Because everything is hash addressed, and content is retained asynchronously (potentially indefinitely; note that key persistence is handled separately), we're very concerned about data deduplication. "Ideally" (ie, ignoring security, which we're obviously not doing), to minimize network clutter, every (plaintext + key) combination would result in identical ciphertext.

Of course, in practice, we need to be extremely concerned about reusing a (key + nonce) combination. Replay attacks are meaningless to this specific protocol[1] -- so the thought is, we can generate the nonce from a manipulation of the hash of the plaintext. This way an identical (key + nonce) combination will by definition result in an identical file.

[1] Without going into a ton of detail, replays for the symmetric containers (GEOCs) are indistinguishable to re-uploading the file. Because retention is handled by the bindings, which have replay protection, a replay of the container without the binding would be automatically garbage-collected by the persistence provider. If the persistence provider already has the GEOC, a second upload is meaningless. This ignores traffic analysis and the like, which again, is out-of-scope for the protocol.

**SIV mode**:

Note: in SIV mode, the MAC tag must be prepended to the ciphertext in the GEOC payload.

Advantages:

+ Network simplicity and deduplication
+ Does not rely upon strength of random number generation
+ [Well-documented](http://web.cs.ucdavis.edu/~rogaway/papers/siv.pdf); also, [good security properties](https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf)
+ Places no restrictions on keys (ie, compatible with reuse, ratcheting, new keys, etc)

Disadvantages:

+ Slow, and requires 2 passes
+ Relatively new, bringing the potential for buggy implementation code
+ Less availability in off-the-shelf crypto libraries
+ Doubles key size, unless using a secondary KDF

**CTR mode**:

Note: in SIV mode, the nonce should not be prepended to the ciphertext in the GEOC payload. It should be considered a functional component of the key, and must be distributed therewith. It may be random, but must never be reused for the same key. New key generation should be accompanied by new nonce generation to emphasize their equivalence and discourage accidental content duplication. Note that the nonce size must match the block size for the underlying symmetric cipher.

Advantages:

+ Fast, and may be totally precomputed
+ Compromise between deduplication and performance
+ Cryptographic simplicity
+ Library availability

Disadvantages:

+ Relies on the strength of the random number generator for birthday resistance
+ **Note that this places restrictions on keys, as the new nonce must be distributed in a new key exchange for new content.** This makes it unsuitable for API pipes.

## Address algorithms

By Golix integer representation:

+ **0x0:** None. Reserved for testing and development purposes., and bootstrapping identity containers.
+ **0x1:** SHA-512.

**Not-so-quick note:** Why not SHA-256? Two primary reasons. The first is to reduce the possibility of an accidental (or malicious) birthday attack against the hash itself. That does sound a little ridiculous, to be fair, given the sense of scale:

+ In 2013 the internet [reached approximately 4E21 bytes](https://en.wikipedia.org/wiki/Zettabyte)
+ Golix headers consume ~1kB per file. Taking this as a minimum filesize yields 4e18 possible files in 2013
+ The internet is expanding rapidly, and will [probably double in size within the next 5 years](http://www.forbes.com/sites/gilpress/2014/08/22/internet-of-things-by-the-numbers-market-estimates-and-forecasts/).
+ Taking 2020 with 1E19 bytes as a baseline, and a 5-year doubling period (approximately 13.9% yearly growth), and extrapolating to a 2040 design life (making Golix approximately as old as the internet is today), yields 1.6E20 files
+ Combine all of that and the formula for [birthday attack probability](https://en.wikipedia.org/wiki/Birthday_attack), and you get p≈1-10^-10^-38 for 256 bits, which is just vanishingly small.

However, this kind of analysis is grossly misleading. It is wholly predicated on the strength of the hash function, and by this kind of analysis, MD5 still looks acceptable (please do *not* mistake that as an argument for MD5). Point is: giving ourselves some headroom for such a potentially large application seems prudent.

Secondly, and much less importantly, we are considering defining 0x2 as a concatenation of SHA256 and SHA3-256 (operating independently over the same input bytes; this is a whole separate discussion). This allows us some version-independent wiggle room, though we could also just reserve an extra 256 bits in the standard to accomplish the same end result.

# Identity containers (GIDC)

+ Preferred stored file extension: no extension
+ Secondary stored file extension: .ghid
+ Tertiary stored file extension: .gidc

Identities are contained within specially-formatted container objects. Unlike other Golix objects, identity containers do not require a binding to persist. A persistence provider should only remove an identity container under extreme circumstances; they should be considered, generally speaking, to be indefinitely persistent. However, they may be bound by dynamic bindings, and that dynamic address may be used as a proxy for the author's GHID.

Because they may have different versions, identity containers are not necessarily deterministically reproducible; rebuilding them from the base public keys without knowing what identity container version was originally used will generally result in a different author GHID. Furthermore, each individual identity container can only support a single ciphersuite.

An author using multiple author GHIDs for the same public keys may have catastrophic consequences for that author, but will leave the network unaffected. Given the difficulty of identity recreation, Golix best practices are to **always** wrap identity containers within a dynamic binding as a proxy, *even if there is only a single GIDC associated with that entity.*

The file hash of the GIDC container (or, again, its dynamic binding proxy) is the Author/Recipient GHID for all other objects.

## Format

| Decimal Offset | Decimal Length | Name                    | Format              |
| ------         | ---------      | -------------------     | -----------         |
| 0              | 4B             | Magic number            | 0x 47 49 44 43      |
| 4              | 4B             | Version number          | Unsigned 32-bit int |
| 8              | 1B             | Cipher suite            | Unsigned 8-bit int  |
| 9              | ...            | Signature key material  | (See below)         |
| ...            | ...            | Encryption key material | (See below)         |
| ...            | ...            | Exchange key material   | (See below)         |
| ...            | 1B             | Address algorithm       | Unsigned 8-bit int  |
| ...            | 64B            | File hash               | Bytes               |

**Why not ASN.1 / DER / PEM encoding?** In a nutshell, this decision is made out of a strong aversion to upstream dependencies. To elaborate: typical DER encodings for ASN.1 key material don't support multiple key serializations. Because identity files are a collection of three public keys, this means they cannot be immediately used as-is without additional code. That leaves three options:

1. using DER for the entire identity container, introducing an upstream dependency or downstream adaptation
2. using DER for the key material, and embedding those three blobs within another encoding
3. avoiding DER / ASN.1 entirely.

Given the very rigid Golix requirements for identity files, and the inherent simplicity of the encoding (public keys are simply large integers), it makes sense for us to define a basic, explicit, versioned container for the public keys. Furthermore, until the Golix protocol reaches maturity, we would like to strongly disincentivize reuse of Golix private keys with other cryptographic systems. In other words, explicitly breaking compatibility with existing key storage standards helps insulate Golix users from protocol and implementation vulnerabilities.

### 1. Magic number

ASCII "```GIDC```" (0x 47 49 44 43)

### 2. Version number

The version number is an incrementing unsigned integer. It is not intended for human use; particular version numbers will be tagged with semantic version numbers.

**The current GIDC version is 2.**

### 3. Cipher suite

Golix supports multiple cipher suites. They are represented as an 8-bit integer. See "Cipher suites and address algorithms" above for details. For GIDC objects, this represents the ciphersuite supported by the identity. This determines the lengths of the key material fields. Currently, identities can only support a single ciphersuite, even if those ciphersuites use the same public keys. This may change in the future.

### 4-6. Key material

Key material formatting, including length, is determined by the declared ciphersuite. Each key is used as follows:

+ **Signature key material:** the key material for object signature verification.
+ **Encryption key material:** the key material for asymmetric encryption, as used in the GARQ object.
+ **Exchange key material:** the key material for symmetric identity exchange, as used for GARQ "signatures" (key agreement for HMAC) and deniable identity aliasing.

#### Ciphersuite 1

| Offset | Length    | Name                               | Format      |
| ------ | --------- | -------------------                | ----------- |
| 9      | 512       | Signature key material (RSA-4096)  | Bytes       |
| 521    | 512       | Encryption key material (RSA-4096) | Bytes       |
| 1033   | 32        | Exchange key material (Curve25519) | Bytes       |

**Notes:**

1. RSA key material (the signature and encryption key) consists only of the RSA public modulus. The public exponent is defined within the ciphersuite, and excluded from the identity file. It must be encoded as a big-endian 4096-bit integer.
2. Curve25519 key material (the exchange key) consists of the uncompressed, unpadded concatenation of the public elliptic curve point *Q* = (*x*, *y*). Both *x* and *y* must be encoded as big-endian 128-bit integers.

#### Ciphersuite 2

**Note:** ciphersuite 2 (differs from CS1 only by using SIV mode on AES) may soon be removed from the Golix standard.

| Offset | Length    | Name                               | Format      |
| ------ | --------- | -------------------                | ----------- |
| 9      | 512       | Signature key material (RSA-4096)  | Bytes       |
| 521    | 512       | Encryption key material (RSA-4096) | Bytes       |
| 1033   | 32        | Exchange key material (Curve25519) | Bytes       |

**Notes:**

1. RSA key material (the signature and encryption key) consists only of the RSA public modulus. The public exponent is defined within the ciphersuite, and excluded from the identity file. It must be encoded as a big-endian 4096-bit integer.
2. Curve25519 key material (the exchange key) consists of the uncompressed, unpadded concatenation of the public elliptic curve point *Q* = (*x*, *y*). Both *x* and *y* must be encoded as big-endian 128-bit integers.

### 7. Address algorithm

Golix may eventually need multiple hash algorithms. They are represented as an 8-bit integer immediately following the magic number. The protocol specification defines which algorithm corresponds to which integer. The 1-byte address algorithm field is prepended to the file hash to form the GHID.

See "Cipher suites and address algorithms" above for details.

### 8. File hash

The hash digest of the file, using the algorithm described by the Address Algorithm field. For **all** Golix objects, input to the hash function is the concatenation of all previous fields. For example, in the case of a GIDC, the file hash is the concatenation of:

1. Magic number
2. Version
3. Cipher suite
4. Signature key material
5. Encryption key material
6. Exchange key material
7. Address algorithm

The file hash is appended to the 1-byte address algorithm field to construct a static GHID.

# Object container (GEOC)

+ Preferred stored file extension: no extension
+ Secondary stored file extension: .ghid
+ Tertiary stored file extension: .geoc

GEOCs must be stored by a persistence provider if, and only if, they are referenced in a GOBS or GOBD stored at the same persistence provider.

**Terminology:**

+ Author: the entity-agent creating the GEOC
+ Payload: all information to be protected by the container
+ Static GHID: the immutable, unique identifier for this particular object. It is always the (address algorithm + file hash) combination for that object.

## Format

| Decimal Offset | Decimal Length | Name                | Format              |
| ------         | ---------      | ------------------- | -----------         |
| 0              | 4B             | Magic number        | 0x 47 45 4F 43      |
| 4              | 4B             | Version number      | Unsigned 32-bit int |
| 8              | 1B             | Cipher suite        | Unsigned 8-bit int  |
| 9              | 65B            | Author GHID         | Bytes               |
| 74             | 8B             | Payload length, *N* | Unsigned 64-bit int |
| 82             | *N*            | Private payload     | Encrypted blob      |
| 82 + *N*       | 1B             | Address algorithm   | Unsigned 8-bit int  |
| 83 + *N*       | 64B            | File hash           | Bytes               |
| 147 + *N*      | 512B           | Author signature    | Bytes               |

### 1. Magic number

ASCII "GEOC" (47 45 4F 43)

### 2. Version number

The version number is an incrementing unsigned integer. It is not intended for human use; particular version numbers will be tagged with semantic version numbers.

**The current GEOC version is 14.**

### 3. Cipher suite

Golix supports multiple cipher suites. They are represented as an 8-bit integer.

See "Cipher suites and address algorithms" above for details.

### 4. Author GHID

The full GHID of the GEOC object containing the author's identity (her public keys).

### 5. Payload length

A 64-bit unsigned integer representation *N* of the length (in bytes) of the binary blob associated with the payload. If the cipher suite prepends a nonce to the ciphertext, this length will include the nonce.

### 6. Private payload

The payload follows the public header immediately, with no padding. It is encrypted according to the cipher suite definition, as described in the public header. The file terminates immediately at the end of the payload.

### 7. Address algorithm

See above for description.

### 8. File hash

See above for description.

### 9. Author signature

This field is always an asymmetric cryptographic signature of the file hash field. The signature algorithm is defined by the cipher suite field.

# Static binding (GOBS)

+ Preferred stored file extension: no extension
+ Secondary stored file extension: .ghid
+ Tertiary stored file extension: .gobs

GOBS must be stored by a persistence provider until, and only until, they are cleared by a debinding.

**Terminology:**

+ Binder: the entity-agent creating the binding (not necessarily the same as the bound GEOC's author)
+ Target GHID: the static GHID for the bound GEOC

Note that the static GHID applies to this particular binding, not to the target.

## Format

| Decimal Offset | Decimal Length | Name                | Format              |
| ------         | ---------      | ------------------- | -----------         |
| 0              | 4B             | Magic number        | 0x 47 4F 42 53      |
| 4              | 4B             | Version number      | Unsigned 32-bit int |
| 8              | 1B             | Cipher suite        | Unsigned 8-bit int  |
| 9              | 65B            | Binder GHID         | Bytes               |
| 74             | 65B            | Target GHID         | Bytes               |
| 139            | 1B             | Address algorithm   | Unsigned 8-bit int  |
| 140            | 64B            | File hash           | Bytes               |
| 204            | 512B           | Binder signature    | Bytes               |

### 1. Magic number

ASCII "GOBS" (47 4F 42 53)

### 2. Version

See above for description. **Currently 6.**

### 3. Cipher suite

See above for description.

### 4. Binder GHID

The full GHID (hash algorithm byte + file hash) of the GEOC object containing the identity (the public keys) of the agent placing the binding.

### 5. Target GHID

The GHID of the resource to bind to. Valid choices are:

1. Static GEOC address
2. Dynamic GOBD address

Binding to the address prevents its removal by the persistence provider.

### 6. Address algorithm

See above for description.

### 7. File hash

The file hash is used only for the signature. See above for further description.

### 8. Binder signature

See Author Signature above.

# Dynamic binding (GOBD)

+ Preferred stored file extension: no extension
+ Secondary stored file extension: .ghid
+ Tertiary stored file extension: .gobd

GOBDs must be stored until, and only until, they are cleared by a debinding, or successfully updated by their binder. Like GEOC objects, external bindings may prevent debinding. In this case, the persistence provider must retain the author's debind object as it otherwise would, even if the GOBD object persists.

**Terminology:**

+ Dynamic GHID, dynamic address: The secondary address for this binding. Static for the lifetime of the binding.
+ Frame: Any particular version of the binding with this dynamic GHID.

Note that the static GHID applies to *this particular frame*.

## Format

| Decimal Offset | Decimal Length | Name                      | Format              |
| ------         | ---------      | -------------------       | -----------         |
| 0              | 4B             | Magic number              | 0x 47 4F 42 44      |
| 4              | 4B             | Version number            | Unsigned 32-bit int |
| 8              | 1B             | Cipher suite              | Unsigned 8-bit int  |
| 9              | 65B            | Binder GHID               | Bytes               |
| 74             | 8B             | Monotonic frame counter   | Unsigned 64-bit int |
| 82             | 2B             | Target vector length *LR* | Unsigned 16-bit int |
| 84             | *LR*           | Target vector             | Bytes               |
| 84 + *LR*      | 1B             | Dynamic address algorithm | Unsigned 8-bit int  |
| 85 + *LR*      | 64B            | Dynamic hash              | Bytes               |
| 149 + *LR*     | 1B             | File address algorithm    | Unsigned 8-bit int  |
| 150 + *LR*     | 64B            | File hash                 | Bytes               |
| 214 + *LR*     | 512B           | Binder signature          | Bytes               |

### 1. Magic number

ASCII "GOBD" (47 4F 42 44)

### 2. Version

See above for description. **Currently 16.**

### 3. Cipher suite

See above for description.

### 4. Binder GHID

See above for description.

### 5. Monotonic frame counter

A monotonically increasing counter indicating frame ordering. The counter prevents replay attacks and state synchronization discrepancies. Persistence providers must reject any attempted frame with a counter lower than the existing frame at the persister. The counter is zero-indexed, *ie* the first frame uploaded has a counter of zero.

### 6. Target vector length

The length, in bytes, of the GHID target vector included in the binding.

### 7. Target vector

A record of the recent history of the dynamic binding's target GHIDs, sorted from most recent to oldest. The first GHID in the target vector is the current target of the binding.

The GHID of the object representing the current state of the binding. The only valid targets are:

+ The static GHID of a GEOC object
+ The dynamic GHID of a GOBD object
+ The static GHID of a GIDC object

Circular references between dynamic bindings are not allowed. Persistence providers must detect any attempts to create these references, and must always reject the latest of the dynamic bindings (the one that "closes" the circular reference). If multiple closing bindings are submitted within the same individual transport request, the persistence provider should reject all of them. Persistence providers may enforce a maximum depth for chained dynamic bindings.

Note that it is impossible to have two *different* dynamic bindings with identical initial target lists. It is therefore also impossible to directly preallocate multiple dynamic "branches". Applications seeking such functionality have at least two options:

1. Create a new dynamic binding at the branch point, updating downstream references to point to the new binding where appropriate.
2. Immediately create two dynamic bindings, with one targeting the other.
3. Create a disposable zeroth (initial) frame, constructing a target vector of a single random GHID, effectively using that GHID as a nonce. Then, update the binding with the desired (duplicate) target.

### 8. Dynamic address algorithm

See above for description. Applies to the dynamic hash.

### 9. Dynamic hash

The GHID hash for the secondary address for the dynamic object. Remains static for the life of the binding. Is used to address the binding.

Like a file hash, generated from the concatenation of the entire preceding file of the original frame in the binding using the hash algorithm described in the Address Algorithm field.

### 10. File address algorithm

See above for description. Applies to the file hash.

### 11. File hash

See above for description.

### 12. Binder signature

See above for description.

# Debind record (GDXX)

+ Preferred stored file extension: no extension
+ Secondary stored file extension: .ghid
+ Tertiary stored file extension: .gdxx

Note that, without chaining, binding and debinding are subject to replay attacks. Therefore, GDXXs must be stored until, and only until, they are cleared by subsequent debinding. For example (ignoring garbage collection):

1. Create object #Obj1
   Bind #BBB1, references (and holds) #Obj1
2. Debind #XXX1, references (and clears) #BBB1
3. Debind #XXX2, references (and clears) #XXX1
   Bind #BBB1, references (and holds) #Obj1
4. Debind #XXX3, references (and clears) #XXX2
   Debind #XXX1, references (and clears) #BBB1
5. Debind #XXX4, references (and clears) #XXX3
   Debind #XXX2, references (and clears) #XXX1
   Bind #BBB1, references (and holds) #Obj1

In each case, the *most recent* set of bindings and debindings must be retained in full by the persistence provider. In other words, ignoring the initial object, the persistence provider state at the end of each exchange above would be:

1. Binding #BBB1
   **Result: hold #Obj1**
2. Debinding #XXX1 (prevents replay of #BBB1)
   **Result: release #Obj1**
3. Debinding #XXX2 (prevents replay of #XXX1)
   Binding #BBB1
   **Result: hold #Obj1**
4. Debinding #XXX3 (prevents replay of #XXX2)
   Debinding #XXX1 (prevents replay of #BBB1)
   **Result: release #Obj1**
5. Debinding #XXX4 (prevents replay of #XXX3)
   Debinding #XXX2  (prevents replay of #XXX1)
   Binding #BBB1
   **Result: hold #Obj1**

**Terminology:**

+ Debinder: The entity-agent removing a binding.

Note that the static GHID applies to *this particular debinding*.

## Format

| Decimal Offset | Decimal Length | Name                | Format              |
| ------         | ---------      | ------------------- | -----------         |
| 0              | 4B             | Magic number        | 0x 47 44 58 58      |
| 4              | 4B             | Version number      | Unsigned 32-bit int |
| 8              | 1B             | Cipher suite        | Unsigned 8-bit int  |
| 9              | 65B            | Debinder GHID       | Bytes               |
| 74             | 65B            | Target GHID         | Bytes               |
| 139            | 1B             | Address algorithm   | Unsigned 8-bit int  |
| 140            | 64B            | File hash           | Bytes               |
| 204            | 512B           | Debinder signature  | Bytes               |

### 1. Magic number

ASCII "GDXX" (47 44 58 58)

### 2. Version

See above for description. **Currently 9.**

### 3. Cipher suite

See above for description.

### 4. Debinder GHID

The full GHID (hash algorithm byte + file hash) of the GEOC object containing the identity (the public keys) of the debinding agent.

### 7. Target GHID

Only one object can be debound per debinding. The target GHID is the address algorithm + file hash of the particular binding or debinding to remove. The **only** valid debind targets are:

1. Static bindings (reference the static binding's GHID, not the object's GHID)
2. Dynamic binding frames (reference the dynamic GHID, not the individual frame's GHID)
3. Debindings (reference the debinding's GHID)
4. Asymmetric requests (reference the GARQ's GHID)

### 8. Address algorithm

See above for description.

### 9. File hash

See above for description.

### 10. Debinder signature

See Binder Signature above.

# Golix encrypted asymmetric request (GARQ)

+ Preferred stored file extension: no extension
+ Secondary stored file extension: .ghid
+ Tertiary stored file extension: .garq

GARQs must be stored until, and only until, they are cleared by a debinding from their recipient.

**Terminology:**

+ Pipe: a bidirectional channel between (usually two) agents
+ Half-pipe: a unidirectional channel, from one agent to another.
+ Recipient: the entity-agent against whose public key the GARQ was encrypted. If Alice is the author and she wants to open a half-pipe to Bob, then Bob is the recipient.
+ Target: the address for the half-pipe (usually dynamic)

Note that the author is the entity-agent requesting the pipe.

## Format

| Decimal Offset | Decimal Length | Name                       | Format              |
| ------         | ---------      | -------------------        | -----------         |
| 0              | 4B             | Magic number               | 0x 47 41 52 51      |
| 4              | 4B             | Version number             | Unsigned 32-bit int |
| 8              | 1B             | Cipher suite               | Unsigned 8-bit int  |
| 9              | 65B            | Recipient GHID             | Bytes               |
| 140            | 512B           | Private inner container    | Bytes               |
| 652            | 1B             | Address algorithm          | Unsigned 8-bit int  |
| 653            | 64B            | File hash                  | Bytes               |
| 717            | 64B            | Author symmetric signature | Bytes               |

**Asymmetrically encrypted inner container format:**

| Offset | Length    | Name                 | Format              |
| ------ | --------- | -------------------  | -----------         |
| 0      | 65B       | Author GHID          | Bytes               |
| 65     | 2B        | Payload identifier   | Bytes               |
| 67     | 2B        | Payload length, *LA* | Unsigned 16-bit int |
| 69     | *LA*      | Payload              | Bytes               |

### 1. Magic number

ASCII "GARQ" (47 41 52 51)

### 2. Version

See above for description. **Currently 12.**

### 3. Cipher suite

See above for description.

### 4. Recipient GHID

The GHID of the recipient.

### 5. Private inner container

Encrypted asymmetrically against the public key for the recipient. Once decrypted, the plaintext contents are defined as:

1. The GHID of the GARQ author.
2. A 2-byte identifier for the payload contents
3. The length, in bytes, of the payload
4. The payload

See "Asymmetric request types" below.

**Note that certain cryptosystems (ex: RSA) may impose limits on the size of the payload.** Asymmetric requests are not intended to be used as communication channels, but rather as handshakes in their establishment.

+ RSA-OAEP [can encrypt](https://www.ietf.org/rfc/rfc2437.txt) at most ``` modulus_size - 2 - 2 * hash_size ``` bytes *total*. With the internal header overhead also accounted for, ciphersuites 1 and 2 can therefore handle a maximum payload of ```512 - 2 - 2 * 64 - 69 == 313``` bytes.

### 6. Address algorithm

See above for description.

### 7. File hash

See above for description.

### 8. Author symmetric signature

The symmetric signature / MAC of the author. The key for the signature is derived by:

1. (EC)DH shared secret between author and recipient
2. Expand shared secret into key material using the file hash as salt. (Ex: cipher suite 0x1 would use HKDF+SHA512)

The material for input into the signature algorithm is the entire preceding file (including the file hash).

## Asymmetric request types

Though the outer container of asymmetric requests is always identical, the internals may differ. The Golix standard currently defines four different objects for use in asymmetric requests:

### Pipe handshake (HS)

Pipe requests are used (primarily) to establish a dynamically-bound GEOC pipe between two Golix identities. They are really only intended to be used once between any particular entity-entity pairing; best practice is to immediately construct a *symmetric* share between the two entities, and use that to bootstrap any additional pipes.

Pipe requests are identified by the ASCII string "HS" ( 0x 48 53 ).

| Offset | Length    | Name                | Format      |
| ------ | --------- | ------------------- | ----------- |
| 69     | 65B       | Target GHID         | Bytes       |
| 134    | 1B        | Secret length, *LK* | Bytes       |
| 135    | *LK*      | Target secret       | Bytes       |

### Pipe acknowledgement (AK)

Pipe ACKs should only be used during pipe negotiation. They most commonly indicate a successful closure or initiation of a half-pipe. They must only be used to indicate problems incurred during pipe management, not, for example, acknowledging messages within the pipe itself.

Pipe acknowledgements are identified by the ASCII string "AK" ( 0x 41 4B ).

**Terminology:**

+ Requested GHID: the GHID used in the original pipe request.

Note that here, the author is the entity-agent acknowledging the pipe, not the entity that made the request. Also note that the requested GHID references the request's GHID, **not** the request's target's GHID.

| Offset | Length    | Name                   | Format      |
| ------ | --------- | -------------------    | ----------- |
| 69     | 65B       | Requested GHID         | Bytes       |
| 134    | 32B       | Status code (optional) | Bytes       |

### Pipe non-acknowledgement (NK)

Pipe non-acknowledgements (NAKs) should only be used during pipe negotiation. They most commonly indicate a rejection of the pipe request, but may also indicate an error in opening the pipe (wrong key, etc). They must only be used to indicate problems incurred during pipe management, not, for example, malformed messages within the pipe itself.

Pipe acknowledgements are identified by the ASCII string "NK" ( 0x 4E 4B ).

Note that here, the author is the entity-agent non-acknowledging the pipe, not the entity that made the request. Also note that the requested GHID references the request's GHID, **not** the request's target's GHID.

| Offset | Length    | Name                   | Format      |
| ------ | --------- | -------------------    | ----------- |
| 69     | 65B       | Requested GHID         | Bytes       |
| 134    | 32B       | Status code (optional) | Bytes       |

### Arbitrary content (0x0000)

Arbitrary asymmetric content is primarily reserved for Golix spec development purposes. It is, once again, explicitly **not** intended for general-purpose use. Application-level communication should **always** be conducted within symmetric pipes.

Pipe acknowledgements are identified by the bytestring ```0x0000```.

| Offset | Length    | Name                   | Format      |
| ------ | --------- | -------------------    | ----------- |
| 69     | *LA*      | Payload                | Bytes       |

# Ancillary binary formats

Two additional binary objects are considered network-critical and included in the Golix standard to facilitate network operations and interoperability. They are:

+ A specific serialization for secret sharing (keys, nonces, etc)
+ A specific serialization for identities (asymmetric signing, asymmetric encryption, and ECDH exchange public keys)

## Secret sharing

Secrets are generally embedded as the target secret in a GARQ pipe request. They are defined in the Golix spec to ensure implementation interoperability.

Format:

| Offset | Length    | Name                | Format              |
| ------ | --------- | ------------------- | -----------         |
| 0      | 2B        | Identifier          | ASCII "```SH```"    |
| 2      | 2B        | Version             | Unsigned 16-bit int |
| 4      | 1B        | Cipher suite        | Unsigned 8-bit int  |
| 5      | ...       | Key                 | Bytes               |
| ...    | ...       | Seed                | Bytes               |

1. **Identifier:** constant to denote a serialized secret. ASCII "```SH```" (0x 53 48)
2. **Version:** the version for the secret serialization. Current is 2.
3. **Cipher suite:** the integer representation of the cipher suite used by the corresponding GEOC object. This determines the key and seed lengths.
4. **Key:** the key material. Length is defined on a per-ciphersuite basis.
5. **Seed:** the nonce or initialization vector, if any is required by the ciphersuite. Length is defined on a per-ciphersuite basis.

### Ciphersuite 1

| Offset | Length    | Name                | Format      |
| ------ | --------- | ------------------- | ----------- |
| 5      | 32        | Key                 | Bytes       |
| 37     | 16        | Seed                | Bytes       |

### Ciphersuite 2

**Note:** ciphersuite 2 (differs from CS1 only by using SIV mode on AES) may soon be removed from the Golix standard.

| Offset | Length    | Name                | Format      |
| ------ | --------- | ------------------- | ----------- |
| 5      | 64        | Key                 | Bytes       |
| XX     | 0         | Seed                | Unused      |

# Persistence provider commands

All of the following commands must be supported by all persistence providers. Additional application-specific commands may be added, though this is not necessarily recommended. Overlay standards define their format for different transport mechanisms. All commands are bidirectional. Nomenclature used here is party ```A``` initiates (in a unidirectional architecture, the client), ```B``` responds (unidirectional server).

## ACK

```A``` acknowledges a transmission from ```B```, indicating successful completion of request. May be accompanied by a status code.

```A``` sends bare statement

```B``` does not respond

## NAK

```A``` acknowledges a transmission from ```B```, indicating unsuccessful completion of request. May be accompanied by a status code.

```A``` sends bare statement

```B``` does not respond

## Ping

```A``` queries ```B``` to determine reachability.

```A``` sends bare request

```B``` responds with:

+ ACK if reachable and ready
+ NAK if reachable and unready

This command can also used by ```A``` to initiate a connection with ```B```.

## Publish

```A``` sends ```B``` a Golix network object.

```A``` sends GIDC, GEOC, GOBS, GOBD, GDXX, GARQ

```B``` responds with:

+ ACK if successful
+ NAK if unsuccessful

## Get

```A``` requests an object from ```B```.

```A``` sends GHID

```B``` responds with:

+ The object if successful
+ NAK if unsuccessful

There is no return response from ```A```. Retries are initiated with a new get command. Persistence providers should always be capable of graceful handling of requests for missing objects.

## Subscribe

```A``` requests to be subscribed to an address at ```B```.

```A``` sends GHID

```B``` responds with:

+ ACK if successful
+ NAK if unsuccessful

If ```B``` receives:

+ An updated copy of a dynamic binding with the indicated dynamic GHID
+ An asymmetric request with the indicated GHID as recipient

then ```B``` will publish only that specific object (GOBD or GARQ) to ```A```. If unsuccessful, ```B``` *may* repeat until successful.

## Unsubscribe

```A``` requests to be unsubscribed from an object at ```B```.

```A``` sends GHID

```B``` responds with:

+ ACK if successful
+ NAK if unsuccessful

## List subscribed addresses

```A``` requests a list of subscribed GHIDs from ```B```.

```A``` sends bare command

```B``` responds with:

+ List of GHIDs if successful
+ NAK if unsuccessful

There is no return response from ```A```. Retries are initiated with a new list command.

## List bindings

```A``` requests a list of bindings targeting a specified GHID ```B```.

```A``` sends GHID

```B``` responds with:

+ List if successful (may be empty)
+ NAK if unsuccessful

There is no return response from ```A```. Retries are initiated with a new list command.

If the specified GHID exists at ```B```, then ```B``` must return successfully, even if there are no bindings for that GHID, or if the target is an invalid target for bindings. The list returned must be ordered as follows:

1. Static bindings must be first (leftmost)
2. Dynamic bindings follow (rightmost)
3. For any of the above two sets, bindings placed by the author must come first (leftmost)
4. No other order is defined.

## Query debinding

```A``` requests to know if a specified binding GHID ```B``` has been targeted for debinding.

```A``` sends GHID

```B``` responds with:

+ GHID of debinding if successful and binding exists
+ Null object if successful and binding does not exist
+ NAK if unsuccessful

There is no return response from ```A```. Retries are initiated with a new list command.

## Disconnect

```A``` disconnects from ```B```, terminating all subscriptions and requests.

```A``` sends bare request

```B``` responds with:

+ ACK if successful
+ NAK if unsuccessful

```B``` should not require this from ```A```; persistence providers should also include a timeout (or other connection termination) method. This command is included to allow ```B``` to log off a particular device securely.

# Object verification

The following section outlines the order of operations while verifying objects, and the conditions under which Golix objects are considered valid. Items with strict execution order are numbered.

Note that in all cases, if a Golix object is successfully received, verified, and stored, a persistence provider **must** issue an ACK, even if the persistence provider already had a copy of the object.

## GIDC order of verification

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + Verify valid signature public key
    + Verify valid encryption public key
    + Verify valid exchange public key
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify EOF reached

## GEOC order of verification

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + Author retrieval
        1. Verify author exists at persistence provider
        2. Retrieve author's identity file
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify signature
6. Verify EOF reached

## GOBS order of verification

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + GOBS status check: verify no debinding exists for the binding's resultant ```GHID```
    + Binder retrieval
        1. Verify binder exists at persistence provider
        2. Retrieve binder's identity file
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify signature
6. Verify EOF reached

## GOBD order of verification

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + GOBD status check: verify no debinding exists for the binding's dynamic ```GHID```
    + GOBD consistency check:
        + if dynamic address **does not exist** at persistence provider...
            1. Verify binding has no history (*ie*, it's new)
            2. Verify dynamic address algorithm
            3. Verify dynamic hash
        + else...
            1. Verify existing binder matches uploaded (new) binder
            2. Verify existing frame ```GHID``` is included in list of historical ```GHID```s for the uploaded (new) binding
    + Binder retrieval
        1. Verify binder exists at persistence provider
        2. Retrieve binder's identity file
    + Digest remaining file
        1. Verify frame address algorithm
        2. Verify frame hash
5. Verify signature
6. Verify EOF reached

## GDXX order of verification

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + GDXX status check: verify no debinding exists for the debinding's resultant ```GHID```
    + GDXX reference check
        1. Verify target GHID exists at persistence provider
        2. Verify debinder GHID matches binder GHID (for GOBS, GOBD, GDXX) or recipient GHID (for GARQ)
    + Binder retrieval
        1. Verify binder exists at persistence provider
        2. Retrieve binder's identity file
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify signature
6. Verify EOF reached

## GARQ order of verification

**Public (server/persister) verification:**

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + Verify recipient exists at persistence provider
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify EOF reached

**Privileged (client/recipient) verification:**

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. Digest remaining file
    1. Verify address algorithm
    2. Verify file hash
5. Verify EOF reached
6. Decrypt payload
7. Author verification
    1. Verify author exists
    2. Retrieve author's identity file
8. Perform symmetric signature key agreement procedure (see "Author symmetric signature" above)
9. Verify author symmetric signature


text:
# WARNING: THIS DOCUMENT IS BOTH DEPRECATED AND UNDER REWRITE

# GOSP 2: Private key storage container

**Problem abstract:** In order to make digital identities (see [GOSP 1](/muse_overlay_standard_proposals/GOSP1.md)) available on multiple devices, and to enable safe Muse storage thereof, a secure private key container file is necessary.

**Goals:**

1. Once the container's GHID is known, the private keys contained within should be accessible through a single password
2. The container file must, on its own, be heavily resistant to brute-force cracking attacks
3. For usability reasons, a single container should enclose all three private keys.

**Solution TL;DR:**

1. First generate public identity container as per MOSP 1 and retain its final byte representation
2. The identity owner chooses a password for the identity.
3. This password (utf-8) is salted with the bytes from 1.
4. A symmetric key is generated using the scrypt.hash function and the salted password from 3.
5. Pack all three private keys together, with no padding, delimiter, etc. Order them as: sign, encrypt, exchange.
6. Create the EICO using the symmetric key from 4 and payload from 5.

repo_name: Muterra/doc-golix

mime_type: text/plain


text:
# WARNING: THIS DOCUMENT IS BOTH DEPRECATED AND UNDER REWRITE

# GOSP 1: Digital identity container

**Problem abstract:** The Muse requires a single object for digital identities, but does not define its structure. This document is a proposed format for the identity file.

**Goals:**

1. As per Muse spec, must include public signature key, public encryption key, and public Diffie-Hellman key.
2. Should be self-describing.
3. Should be self-hosted and should therefore bootstrap itself.

**Solution TL;DR:**

Formatted as a zbg-encoded dictionary with the following structure:

1. ASCII '```__class__```': <API class ghid>
1. ASCII '```version```': <version identifier>
2. <ciphersuite identifier>:
    1. ASCII '```sign```': <signature key>
    2. ASCII '```encrypt```': <encryption key>
    3. ASCII '```exchange```': <Diffie-Hellman key>

and raw binary encoding of the keys themselves:

1. n-bit

The container author ghid should be 66 bytes of ```00```


text:
# Format Notes

Classic vs Standard Text

## Mint

Classic in json  - single-line mint example:

```json
{"p":"orc-721","op":"mint","s":"diypunks","g":[59,0,38]}
```

Classic in json  - multi-line mint example:

```json
{
  "p":"orc-721",
  "op":"mint",
  "s":"diypunks",
  "g":[59,0,38]
}
```

vs

standard text mint example:

```
og mint diypunks 59 0 38
````

note:
- no quotes ("""")
- no keys  (p, op, s, g)
- no objects ({})
- no arrays ([])
- no commas (,,,,,)
- no dots (....)

## Deploy

Classic in json  - multi-line deploy example:

```json
{
    "p": "orc-721",
    "op": "deploy",
    "slug": "diypunks",
    "name": "D.I.Y. Punks",
    "max": 721,
    "dim": "24x24",
    "generative": "cf5df319bbe23fa3d012e5ee0810700c8e82aebff41164246f0d87d7b60a9903i0"
}
```

vs

standard text deploy example:

```
og deploy diypunks
max:  721
dim:  24x24
name:  D.I.Y. Punks
cf5df319bbe23fa3d012e5ee0810700c8e82aebff41164246f0d87d7b60a9903i0
```

- start with required triplet  - protocol / operation / slug
- followed by headers  (using single-line key value pairs)
- list of inscribe ids  (generatives)

## Questions? Comments?

Please post in the #generative-orc-721 channel
in the ordinal punks discord.
For an invite
see <https://twitter.com/OrdinalPunks/status/1620230583711576068>.

repo_language: Ruby


text:
# More ORC-721 Notes (Work-In-Progress)

Q: wen use standard text format or "classic" json format?

about the new text format - the rule is the deploy leads, that is, if the deploy is in json than the mints must be in json too and if the deploy is in text than the mints must be in text too.    json not ded (if anyone wants to deploy using "classic" json).

Q: mix-n-match of "recursion"(s) and "spritesheet"(s) possible?

yes, you can stack spritesheets too ... numbers get added.   yes, you can reference specific tiles from multiple spritesheets.  ORC-721 started with single spritesheet to keep it simple (to get started and not confuse everybody). and yes - you can mix'n'match "recursion"(s) and spritesheet(s). another world's 1st generative? wen deploy?

Q: If there is no way to know the current number
of mints and obtain the initial 721, it will be frustrating

A: sorry - i am working on a more automatic way to collect inscriptions and finalize the validation rules / protocol -   for now the best / fastest is search on https://unisat.io/ or such to get a close figure. the number is excat (but cannot do the validation - because the protocol / validation rules are  getting  finalized right now).

Q: if mints has been 721,then others would be ignored right?

A: the "overflow" mint will not be part of the official 721 collection - but they are still ordinals you can buy / sell individually - the current plan is to call / collect them under the name "cursed" overflow "negatives" and they start counting -1, -2, -3,... to infinitiy (no limit).

## search for orc-721 mints

try:

- <https://unisat.io/>  - Search in Text Inscriptions

## validate your json (orc-721 text inscription)

try:

- <https://jsonlint.com> - JSON Validator

 ## protocol trivia / research / rules  - (work-in-progress)

one deploy rule

IMPORTANT ORC-721 protocol triva -    if you (re)use copy-n-paste a deploy mint it will NOT work - sorry
the slug in the deploy mint is like a domain name and can only used once (first-come, first-serve) .... if you want to deploy v2, v3, etc. ... you MUST use a different slug e.g.  add -v2, -v3, etc.

just to clarify - the one deploy rule - a ORC-721 slug is like a domain-name "first-come / first-serve"  is valid for all ORC-721 collections -
if you do another "diypunks" you CANNOT - you must change to a new unique name (not already taken) e.g "diypunks-v2" or whatever same for "diyordibots" and "diyordibots-v2" and "diyordibots-v3" and so on.

note - duplicate mint deploy (same slug) WILL get rejected by the validation / protocol.

good news - all mints will get added to the first deploy as "cursed" overflow negatives.

Q: but the deployed  diyextraordpunks it is ok we can mint ?

A: is this a new deploy inscription with the slug "diyextraordpunks"  and NOT the first?   Than again sorry it will not work ... you MUST use a new slug  e.g. add change to  "diyextraordpunks-v2" or  "diyextraordpunks-v3" or whatever.

what's a broken mint?

the validation rules will be the same for all ORC-721 collections - it's a step-by-step algorithm  anyone can run

> oh and also one more thing i found a fault in the diyordibots the deploy inscription is before the spritesheet was ever uploaded or confirmed on the mempool so that makes the diyordibots invalid in terms of code as the deploy inscription cannot read the inscription id as it was not confirmed there ye

 o o o

> I think both diyordibots v1&v2 are valid
> Since the spritesheet inscription id is inside the deployment inscription

the ORC-721 protocol rule is a deploy inscribe is valid if the inscription id references a  spritsheet that exists.

edge case - deploy inscribe before spritesheet?  happened in diyordibots?

## pixle art image (resize) tips

btw if you want to test;

https://redketchup.io/image-resizer

- aspect ratio as original
- resampling to nearist neighbour

###  More Design Notes

- Keep all keys unique, that is, MUST start with a different letter,
  thus,
  - d is the same as dim
  - g is the same as generative
  - n is the same as name
  - m is the same as max
  - s is the same as slug
  - etc.


text:
# Ideas

## Register Collections - Inscribes BEFORE Deploy

here's an idea ...
this is a new ordgen / ORC-721 word's 1st generative ....
... BEFORE deploy people inscribe .PNGs for the collection ... you specifiy  e.g.  24x24px canvas or anything if you want ...
... now the ordgen / ORC-721 protocol update and new feature ...
... if you leave out the max key  (and the dim key)  than you can turn any inscribes (BEFORE deploy) into a collection!
example:

```
og deploy canvas
<inscribe id no. 0>
<inscribe id no. 1>
<inscribe id no. 2>
....
```

that's it.  no need for max because the number of inscribe ids listed are the max.

.. let's explore options for a new ordgen / ORC-721 collection syntax where you inscribe the mints (as .PNGs)  BEFORE the deploy inscribe!

... so what?!

... here is the proposal ... yes, a single text deploy can turn ordinalpunks into the world's 1st ORC-721 / ordgen collection using the new formula / update ...

... all ordinal punks already inscribed as .PNGs BEFORE deploy!

... what's missing to wrap-up is the deploy to turn the "free-floating" .PNGs into a collection for indexers. here's the suggested format:

```
og deploy ordinalpunks
<inscribe id - ordinal punk no. 1>
<inscribe id - ordinal punk no. 2>
<inscribe id - ordinal punk no. 3>
...
```

that's it. no need for max because the inscribe id list IS the max ... and the magic switch to turn a deploy to use the "BEFORE" formula is dropping the max / maxblock. that's it.

as a bonus - ordgen / ORC-721 slugs / keys are like sat names  - first-come / first-serve - and, thus, the ordinalpunks name is yours forever with a deploy.

now what for you might be thinking?
what if .... a ordgen / ORC-721 indexer produces a listing something like this ... https://unisat.io/brc20  or this https://www.brc-20.io/   - do you want to ("automagically") get listed or not? being world's first counts ;-).

...let's explore some more...  let's go recursive! ... recursive what!? ...

... let's use the inscribe id for the ordinalpunks meta data / manifest!!
now how does this look:

```
og deploy ordinalpunks
a64027dabba3c5acf83068028edf4e938464ff3c6b279f0415f5c6573cf03207i0
```

yes. that's it.
and the inscribe id is this -> https://ordinals.com/content/a64027dabba3c5acf83068028edf4e938464ff3c6b279f0415f5c6573cf03207i0
(the official meta data manifest inscribe by @FlowStay )

thus - the new proposal - if anyone wants to inscribe this text ( two lines):

```
og deploy ordinalpunks
a64027dabba3c5acf83068028edf4e938464ff3c6b279f0415f5c6573cf03207i0
```

than this is the world's 1st ordgen / ORC-721 collection with meta data manifest using the BEFORE formula for automagic processing by indexers.

.. one more thing ...

... one option  is to turn this into a new "on-chain" protocol kind of sat names for collections   ....   any good names for the new protocol? here's the reworked further simplified version using the new proposed collection protocol:

```
collection ordinalpunks
a64027dabba3c5acf83068028edf4e938464ff3c6b279f0415f5c6573cf03207i0
```

---

Q: `og deploy ordinalpunks` - what is this?

A: this is a suggested ordgen / ORC-721 protocol update to REGISTER  collections with .PNGs inscribed BEFORE deploy  ... that works perfectly for ordinal punks if anyone wants to try -  comments and questions welcome.

## More Dimensions (X and Y)

> your orangenpixel [by ZimmerAllDay] idea was already realized on ETH

1-bit 20x24 canvas example on ethereum -> <https://canvas.papercorp.org>

> turn your imagination into an NFT in a 20x20 canvas

pixel format  is:

```
[
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,1,0,0,0,1,1,1,0,0,0,0,0,0,0]
  [0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0]
]
```

... that is the canvas matrix metadata (copy-n-pasted) from the website ...

... that meta data "matrix" style format looks like hitting the jack pot ... and marked for an upcoming ordgen / ORC-721 protocol update that lets you expand the g(enerative) numbers in two dimensions (x and y).

let's explore some more ...

happy to do a 16 color (or 256 color - 8bit) canvas in ordgen / ORC-721 ... BUT ...

let's introduce a new g(enerative) matrix syntax!

.. here's the idea ... the dim is 1x1px!
the "recursives" can be an all-in-one spritesheet with 16x1px  with 1px per color (0,1,2,3,4)  ... or 16 inscribes 1x1px with one pixel in one color ....
now the new magic matrix generative mint syntax:

```
[ .., ..., ...]
[ .., ..., ...]
```

... for every row ... and you can use 0,1,2,3,4 for colors  ... that is like classic paint by numbers .... e.g.

```
[0 0 0 1 0 ....]
[0 1 2 2 4 5 6 ...]
[4 4 5 ...]
```

... and so on ...  maybe change to commas for starting a new row / line / anywhere e.g.

```
0 0 0 1 0 ...  ,
0 1 2 2 4 5 6 ... ,
4 4 5 ...  ,
```

... or maybe even better only numbers no commas  ... and in deploy a new   dim: 24x24px  AND tile: 1x1px  or dim: 24x24px / 1x1px  and than only series of numbers e.g. colors 0 to 15 (16).

happy to experiment if anyone interested in a 16 color or 256 (8-bit) color canvas in 24x24px or such in ORC-721 / ordgen.

but remember to inscribe a bitmap / pixel canvas the easiest is to inscribe .PNG ... .PNG has all the "metadata" e.g. pixels and colors encoded in binary with compression - can't beat that  - but sure with ordgen / ORC-721 in the deploy you CAN specifiy the color palette and the canvas size and the collection max. and such ... that sure is something extra (beyond plain .PNG inscribe).

## Alternate Spritesheet Formats

Why? Why not?

###  Option 1) - Tabular Text / Dataset (.csv) - Compact (Less Bytes, Saving Sats!)

Using the tabular (text) format in the comma-separated values (.csv) format
lets you add "on-chain" metadata
such as names, categories, and more.

Example - spritesheet.csv:

``` csv
name,   category, base64
Human,  Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAADWdQf3kxr4rUv///+T6IvaAAAABnRSTlMA//////96eeD+AAAAXklEQVR4nGNiQAJM5HIEBQUFYBxGJSUlRRhHiBFIC8CU8SPr+YDTtP8fGN5DOYwK/w0YPsNlmB4wyME4D5D0/AdS95BNU8Ll6n/IyphQlf37AOfcu3cfIfP//QcM0wAaAxSH2HomKQAAAABJRU5ErkJggg==
Vampire, Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAFVBMVEUAAAAAAABbMwOlXQX2AAv3kxr////bh9zEAAAAB3RSTlMA////////pX+m+wAAAG1JREFUeJxjYkACTORyBAUFBWAcRhcXF0cYRwSIWQRINO3fA4Z7UA6jwz8DhsdwGZYPDPYwzgEkPf+B1B5k01xw2bNnzwEEx8TFAMxhFBRkYBBg4PkA4vxnFAQp2w9R9h7kI4EPEM5/EP0erBUAERwWzx5CqboAAAAASUVORK5CYII=
Demon,   Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAD1BMVEUAAAAAAAC4cAv3kxr///+zzqXqAAAABXRSTlMA/////xzQJlIAAABgSURBVHichY3dDYAgDISPTgAuYGX/mdANaByAqonSEhPty+XL/ZTgjj4hRCB1Z0Fgi6VoHcq5w3Rp/J0eQQX1hsDK2G1aMD+wuY6eUvxa9uD/NB+jMdakQymrOVrltXYAZGITh03FFbsAAAAASUVORK5CYII=
Zombie,  Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAADHcwz3kxr/AAD/z5G469XyAAAABnRSTlMA//////96eeD+AAAAYUlEQVR4nJ2O0Q2AMAhEDyZoHUAr+89UjQuUCVr7IZXE9Ec+IC93HDBc8V+IMQYDEpHdYOmNg9lWv3NO05qiPECJFdtQasJlcBJgR1sf2afJ7OvqbeRthKoDcj5epRX9pN0MGRSH7kVdXgAAAABJRU5ErkJggg==
Ape,     Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAAD3kxr3nzL/xHj////N6G+OAAAABnRSTlMA//////96eeD+AAAAb0lEQVR4nJ3PwQ2AMAgAQNq+TcoGJg6gkf1HIDqCcYGyQFs1kdKHL/nQC4WAhy78XyBiVLgbqHgeLn721JSkYSJarSKQXrhYRjhbJQjMCummVThyttElhNLgLd9NzLudQLQ0DABZFI55s2+1W1TjAn1pHXVHt3hFAAAAAElFTkSuQmCC
Alien,   Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAACcXA7QeA33kxr/z5E7kZyXAAAABnRSTlMA//////96eeD+AAAAY0lEQVR4nGNiQAJM5HIEBQUFYBxGY2NjQxhHmJGBgVkApowfWc8HHKYxMvy7wHAXyhFW+K/A8AnKeSsANApu9AWYEUDOf7wOFUDinD17AcExNjZA1vP3A5Ky8wiZ/+8/YBgNAJwZFZmWaFZKAAAAAElFTkSuQmCC
...
```

Note: The name (or names) or the category columns
are optional - only the base64-encoded image is required - and, yes you
can add more columns as you please.

Aside - What's base64?

Images are binary blobs - using the base64 encoding
you can convert (or encode) the binary blob into
an ascii-7bit (& utf-8)-safe text snippet that you can copy-n-paste
into any text file.

**D.I.Y. Punks Sample**

Example - [diypunks/spritesheet.csv](sandbox/diypunks/spritesheet.csv):

``` csv
name,   category, base64
Human,  Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAADWdQf3kxr4rUv///+T6IvaAAAABnRSTlMA//////96eeD+AAAAXklEQVR4nGNiQAJM5HIEBQUFYBxGJSUlRRhHiBFIC8CU8SPr+YDTtP8fGN5DOYwK/w0YPsNlmB4wyME4D5D0/AdS95BNU8Ll6n/IyphQlf37AOfcu3cfIfP//QcM0wAaAxSH2HomKQAAAABJRU5ErkJggg==
Vampire, Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAFVBMVEUAAAAAAABbMwOlXQX2AAv3kxr////bh9zEAAAAB3RSTlMA////////pX+m+wAAAG1JREFUeJxjYkACTORyBAUFBWAcRhcXF0cYRwSIWQRINO3fA4Z7UA6jwz8DhsdwGZYPDPYwzgEkPf+B1B5k01xw2bNnzwEEx8TFAMxhFBRkYBBg4PkA4vxnFAQp2w9R9h7kI4EPEM5/EP0erBUAERwWzx5CqboAAAAASUVORK5CYII=
Demon,   Base,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAD1BMVEUAAAAAAAC4cAv3kxr///+zzqXqAAAABXRSTlMA/////xzQJlIAAABgSURBVHichY3dDYAgDISPTgAuYGX/mdANaByAqonSEhPty+XL/ZTgjj4hRCB1Z0Fgi6VoHcq5w3Rp/J0eQQX1hsDK2G1aMD+wuY6eUvxa9uD/NB+jMdakQymrOVrltXYAZGITh03FFbsAAAAASUVORK5CYII=
...
```

**D.I.Y. Wiener**

Example - no2/spritesheet.csv:

``` csv
name, category, base64

...
```

**D.I.Y. Ordibots**

**Format Option 2) Tabular Text (.csv) - Compact**

Example - [diyordibots/spritesheet.csv](sandbox/diyordibots/spritesheet.csv):

``` csv
name, category, base64
blue, background, iVBORw0KGgoAAAANSUhEUgAAACAAAAAgAQMAAABJtOi3AAAAA1BMVEVkhZa3PARZAAAAC0lEQVR4AWMY5AAAAKAAAVQqnscAAAAASUVORK5CYII=
bitcoin-orange, background, iVBORw0KGgoAAAANSUhEUgAAACAAAAAgAQMAAABJtOi3AAAAA1BMVEX3kh03gNzOAAAAC0lEQVR4AWMY5AAAAKAAAVQqnscAAAAASUVORK5CYII=
brown, background, iVBORw0KGgoAAAANSUhEUgAAACAAAAAgAQMAAABJtOi3AAAAA1BMVEWUVU4LyOhwAAAAC0lEQVR4AWMY5AAAAKAAAVQqnscAAAAASUVORK5CYII=
purple, background, iVBORw0KGgoAAAANSUhEUgAAACAAAAAgAQMAAABJtOi3AAAAA1BMVEWOb7aMtmqBAAAAC0lEQVR4AWMY5AAAAKAAAVQqnscAAAAASUVORK5CYII=
antenna, accessories, iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAKUlEQVRYCe3BsQ0AIADDsOT/o8sJLEgssSHJhTpg4oDxmzKSJEmS5KEDUlIFA6L+DvwAAAAASUVORK5CYII=
none, accessories, iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAGklEQVRYR+3BAQEAAACCIP+vbkhAAQAAAO8GECAAAcFgLJ8AAAAASUVORK5CYII=
rainbow, accessories, iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAu0lEQVRYw+2OsQ5EQBCG12ucjhegpaFdPa/GG3BoeDMamv1vZ5bG1XvJJfMlX2ZGJPspJQiCIAiCIAiWI0tx5imOLMHvH88T4K2sAU8OYROcNojuk/fUTxzGAGYvgb2w02pDzKisLoh2kHb3EmC2EtVUQ88NT3OHbIWLonnpJUBPDcLWsK8O0BRzBem5RkXyXfsJoEeHaMEQr+yrcyFk2IJvF2f8BAzxgufdsytL923/+LeP1q9vgvB3fABOiLQ6WjY8vQAAAABJRU5ErkJggg==
...
```

###  Option 2)  -  Structured Text / Dataset (.json)  - Classic

Using the structured (text) format in the javascript object notation (.json) format
lets you add "on-chain" metadata
such as names, categories, and more.

Example - spritesheet.json:

``` json
[{ "name": "Human",
   "category": "Base",
    "base64": "iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAADWdQf3kxr4rUv///+T6IvaAAAABnRSTlMA//////96eeD+AAAAXklEQVR4nGNiQAJM5HIEBQUFYBxGJSUlRRhHiBFIC8CU8SPr+YDTtP8fGN5DOYwK/w0YPsNlmB4wyME4D5D0/AdS95BNU8Ll6n/IyphQlf37AOfcu3cfIfP//QcM0wAaAxSH2HomKQAAAABJRU5ErkJggg==" },
  { "name": "Vampire",
    "category": "Base",
    "base64": "iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAFVBMVEUAAAAAAABbMwOlXQX2AAv3kxr////bh9zEAAAAB3RSTlMA////////pX+m+wAAAG1JREFUeJxjYkACTORyBAUFBWAcRhcXF0cYRwSIWQRINO3fA4Z7UA6jwz8DhsdwGZYPDPYwzgEkPf+B1B5k01xw2bNnzwEEx8TFAMxhFBRkYBBg4PkA4vxnFAQp2w9R9h7kI4EPEM5/EP0erBUAERwWzx5CqboAAAAASUVORK5CYII=" },
  { "name": "Demon",
    "category": "Base",
    "base64": "iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAD1BMVEUAAAAAAAC4cAv3kxr///+zzqXqAAAABXRSTlMA/////xzQJlIAAABgSURBVHichY3dDYAgDISPTgAuYGX/mdANaByAqonSEhPty+XL/ZTgjj4hRCB1Z0Fgi6VoHcq5w3Rp/J0eQQX1hsDK2G1aMD+wuY6eUvxa9uD/NB+jMdakQymrOVrltXYAZGITh03FFbsAAAAASUVORK5CYII=" },
  { "name": "Zombie",
    "category": "Base",
    "base64": "iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAADHcwz3kxr/AAD/z5G469XyAAAABnRSTlMA//////96eeD+AAAAYUlEQVR4nJ2O0Q2AMAhEDyZoHUAr+89UjQuUCVr7IZXE9Ec+IC93HDBc8V+IMQYDEpHdYOmNg9lWv3NO05qiPECJFdtQasJlcBJgR1sf2afJ7OvqbeRthKoDcj5epRX9pN0MGRSH7kVdXgAAAABJRU5ErkJggg==" },
  { "name": "Ape",
    "category": "Base",
    "base64": "iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAAD3kxr3nzL/xHj////N6G+OAAAABnRSTlMA//////96eeD+AAAAb0lEQVR4nJ3PwQ2AMAgAQNq+TcoGJg6gkf1HIDqCcYGyQFs1kdKHL/nQC4WAhy78XyBiVLgbqHgeLn721JSkYSJarSKQXrhYRjhbJQjMCummVThyttElhNLgLd9NzLudQLQ0DABZFI55s2+1W1TjAn1pHXVHt3hFAAAAAElFTkSuQmCC" },
  { "name": "Alien",
    "category": "Base",
    "base64": "iVBORw0KGgoAAAANSUhEUgAAABgAAAAYBAMAAAASWSDLAAAAElBMVEUAAAAAAACcXA7QeA33kxr/z5E7kZyXAAAABnRSTlMA//////96eeD+AAAAY0lEQVR4nGNiQAJM5HIEBQUFYBxGY2NjQxhHmJGBgVkApowfWc8HHKYxMvy7wHAXyhFW+K/A8AnKeSsANApu9AWYEUDOf7wOFUDinD17AcExNjZA1vP3A5Ky8wiZ/+8/YBgNAJwZFZmWaFZKAAAAAElFTkSuQmCC" },
 ...
]
```

Note: The name (or names) or the category keys
are optional - only the base64-encoded image is required - and, yes you
can add more keys as you please.


text:
Ordgen / ORC-721

#  Frequently Asked Questions  (F.A.Q) and Answers

## Q: Wen image (in wallet) - i see text?

No worries ... all generative metadata is "on-chain" and the spritesheets and recursive building blocks.

tip:  if anyone feels like they don't own the image because only the image DNA or formula (AND yes, all "recursions" or "spritesheets")  to generate is "on-chain" and inscribed forever ... than you can generate the image "off-chain" in any size e.g. 1x, 4x, 8x, 10x, 20x as .PNG
or even as .SVG .... and than inscribe the image.

note: ordgen / ORC-721 are generatives, that is, YOUR NUMBERS - YOUR IMAGE.

... still worried - you are not alone - see this meme:

![](i/sats.png)

fyi -  if your plain image e.g. .SVG or .PNG or .JPEG is "on-chain" than it is ONLY accessible via complex segwit bitcoin decoding / data generation  ... the data is stored in the bitcoin segwit store with OP_IF / OP_ELSE envelopes or such ... that is, more cryptic than the ordgen / ORC-721 text protocol.

## Q:  Does Magic Eden (ME) or Ordinals Wallet.com (OW) support Ordgen / ORC-721? Will the images be on the market?

nobody supports ordgen / ORC-721 image generation (yet)...   Ordinal Wallets.com (OW) supports "off-chain" images - same as Magic Eden (ME) in inscriptions.json with  high_res_img_url key.

Yes, the reference inscriptions.json (for market submit)
includes the `high_res_img_url` key
(with public image hosted @ [ordbase.github.io](https://ordbase.github.io/)
or on your own host).

## Q:  How can i generate the  image "off-chain"?

The ordgen image generation algorithm is "super-simple" ... paste / merge the generative sprites / tiles / "recursions"
in the stacking order (left-to-right) into a new image (using the dim size from deploy text eg. 24x24, 32x32 etc). That's it.

Use any programming or scripting language of your choice. Or use the ready-made ordgen library (or tooling).

For ready-made preview scripts, see [/preview »](preview).

For ready-made generate scripts, see [/generate »](generate).

## Q:  YOUR NUMBERS, YOUR IMAGE - explain?

Your image is a computer-generated image (CGI) or generative.
You  are the creator and you own the computer-generated image,
that is the idea / rule of "YOUR NUMBERS, YOUR IMAGE".

## Q:  Wen "on-chain" image renderer in javascript (.js) inscribed?

The javascript (.js) renderer to generate images with "on-chain" data only
is planned from day one. SOON!

## Q: Is Ordgen / ORC-721 recursive?

Yes, ordgen / ORC-721 is recursive generative. The world
is not recursive vs generative.
Recursive gives generative new super-powers. It's 2+2 is 4.

Before the ord recursive update v0.6 - ordgen was "recursing"
on its own spritesheets only ... now with the ord recursive update
ordgen can "recurse" on its own spritsheets AND on all inscriptions (recursive or not). Mix'n'match ("recurse") building blocks / sprites / tiles  that's the idea from the beginning in ordgen / ORC-721.

Note: Ordgen / ORC-721 is a (text) protocol meaning
the generative metadata is "on-chain" and the spritesheets and recursive building blocks.

The image generation (or viewer / browser) is possible "on-chain"
with javascript (.js) renderers
but "off-chain" is prefered because upgradable day-to-day, month-to-month, year-to-year ... offering ever more functionality (and bug fixes).

## Q:  The ordgen image is a text inscription? Can a text inscription be recursive?

what is recursive? let's have fun with this Magic Eden (ME) statement / reasoning:

> The [100 D.I.Y. Martians] inscriptions do not look recursive (they are text).

Text? Text? Text?!

From the wikipedia article on SVG:

> SVG images are defined in a vector graphics format and stored in ......
>

drum-roll please ....

>  text files.

It's still early. Anyone wants to do HTML ...    web pages defined in a markup format and stored in ....  You tell us.    It's still early.

## Q: Wen (scalable) vector graphics (.SVG) in ordgen?

SOON!
See [Quick Notes & Commentary on (Scalable) Vector Graphics (.SVG) »](SVG.md)

## Collections

## Q: Is the D.I.Y Martians Art itself a copy of an existing collection?

that's a good one.  first these are creator's do-it-yourself (DIY) original inscribes AND  it's recursive!  many originals inscribed first-time e.g. 10 boring backgrounds, 7 martians, martian happy smile, laser eyes, etc.  AND recursive (reuse) inscribes - from recursive punk collection and recursive noun punks.  tell again D.I.Y Martians is not recurisve ;-).

# Questions? Comments?

Post them over at the [Help & Support](https://github.com/geraldb/help) page. Thanks.


text:
# Quick Notes & Commentary on (Scalable) Vector Graphics (.SVG)

> I just created an on chain 3d rendering of my pixel pepe using recursive inscriptions. In the process, I inscribed  tooling that will be critical as we build out the bitcoinverse.  this is how i dit it - source: https://twitter.com/hbeckeri/status/1671917391377317891

here's a first quick answer / commentary:   for now ordgen / ORC-721  is bitmaps / .PNG  2D   ... support for new format - (scalable) vector graphics (.SVG) supporting 3D upcoming   BUT maybe in a week or two.
... another idea is the ordgen "on-chain" render than you can recurse in .SVG  and do the above ...
... if you want to do it NOW ... you CAN ... BUT you have to inscripe the generated image in 1x as .PNG.  it is your image - one more inscription needed to recursve in .SVG.

## (Recursive) SVG Examples

... broken in recursive punk:

 add svg here

... improved formula in recursive noun punks:

 add svg here

...  now with rotation and transalte in recursive doodinals (rcsvio):

> Doodinals is the 1st collection of recursive arts fully created by the community.

> Doodle to your heart's content on http://RCSV.io,
> inscribe the generated SVG files on Ordinals,
> and your inscriptions have the chance to be included in the collection.

 add svg here


text:
# Mint Text Format Commentary & Ideas

short-hand mint text formats - why? why not?

```
og mint punk 58 4 19
=>
og punk 58 4 19
punk 58 4 19
punk #58 4 19
```

or use slash(`/`)

```
punk/58 4 19
```

or allow space - why? why not?

```
punk / 58 4 19
punk/ 58 4 19
```

or lisp? style - why? why not?
```
(punk 58 4 19)
```

keep `#` for (pre-)registered generatives - why? why not?

```
punk #0
punk #1
punk #2
```

or make a collection all d.i.y. or (pre-)registered? - why? why not?

that makes `og` or/and `mint` optional
plus the new `#` is optional too. use `#`only for (pre)registered og/ordgen collections?

## more discussions

instead of:

    og mint diypunks 58 4 19

it is

    58 4 19.diypunk

yeah maybe onto something ...
maybe `og mint diypunks 58 4 19` still too complex ;-).

`58 4 19.diypunk`  or `58 4 19 diypunk` or `58 4 19 diypunks`... why not?

or for diymonke that would be ...

`0.diymonke`   or `0.diymonkeys`   ...  let's think about it.

or let's drop the diy  (the number tells that it's d.i.y.) ...

`0.monke`  or  `54 58.monke`   or `54 58 1 24 28.monke`
... searching for .monke  gets you this results for now =>  <https://unisat.io/search?q=.monke&type=text&p=1>

... lets try .punk that gets you this results for now => <https://unisat.io/search?q=.punk&type=text&p=1>

... lets  try .rock that get you this results for now => <https://unisat.io/search?q=.rock&type=text&p=1>

... too many to ignore ...  lessons learned.

1. drop d.i.y. and
2. use singular in mint  eg.  punk NOT punks  or rock NOT rocks.

how about  turning the syntax around e.g.

     0.monke    =>  monke 0    or
     54 58.monke    => monke 54 58   or
     54 58 1 24 28.monke   => monke   54 58 1 24 28

or to add back the protocol?

     monke og 0     or og monke 0
     monke og 54 58     or og monke 54 58
     monke og 54 58 1 24 28   or  og monke   54 58 1 24 28

f.i.y. genesis punks waiting to happen ;-).   now how about ...

     genesis 1      or 1.genesis

for the mint text inscribe?

or since the dot is really sat names
lets pick a new character for og / ordgen.

     0.monke    =>  0/monke or
     54 58.monke    => 54 58/monke   or
     54 58 1 24 28.monke   => 54 58 1 24 28/monke

or maybe star \*?

     0*monke or
     54 58*monke   or
     54 58 1 24 28*monke

or maybe  hash rocket =>?

     0  => monke or
     54 58 => monke   or
     54 58 1 24 28 => monke

questions? comments? what do you want your ordgen / ORC-721 mint text to look like?
numbers before name? or name before numbers? with or without dot (.) or slash (/) or __?

maybe dollar ($) is the way to go?

     $monke 0 or   0 $monke
     $monke 54 58   or    54 58 $monke
     $monke 54 58 1 24 28  or   54 58 1 24 28 $monke      ... why? why not?

always obvious once you see it .. is the number sign / hashtag (#) the way to go?

     monke #0 or
     monke #54 58   or
     monke #54 58 1 24 28     ... why? why not?

try a search on "punk #" or "monke #"  here -> https://unisat.io/search?q=punk%20%23&type=text&p=1    that gets you zero results - bingo!  it is now a og / ordgen standard.

monke #0  or rock #0 or punk #0  or __    anyone?  let's make it happen. yes, you can.

## pre-registered collections

instead of `max:`` list generative numbers one-by-one
or  better reference via inscriptions  - why? why not?

allow inscriptions in the format text

### attach generative or generative collection to sat names - why? why not?

list of inscribe ids - what format available now or design new one?

simple list format:
- inscibe id, optional name(s), optional category

```
og reg (or deploy?) punk
<inscribe_ids>

0, g(enerative) numbers
1, g(enerative) numbers
hello,   g(enerative) numbers
```

- allow (or use) optional comma (,) - why? why not?

than use for mint - why? why not?

```
0.punk
1.punk
hello.punk

or

punk #0
punk #1
punk hello  ???? - # not working for names really!?
```


text:
**NEW!  [Public Ordgen / ORC-721 Mint Feed (Incl. Reference Images in 1x and 4x) »](https://orc721.github.io)**

**NEW!  [Discussions - Join Us - Welcome to the Ordgen / ORC-721 Community - Wen [next] deploy? »](https://github.com/orc721/market/discussions)**

**Wen Market? Wen Magic Eden (ME)? Wen Ordinals Wallet (OW)?  See [/market @ Bitcoin Ordinal Generative (ORC-721 / OG / Ordgen) Community »](https://github.com/orc721/market)**

## What's News? Updates

We are live!  The world's first ORC-721 collections (on bitcoin) include:

[**721 D.I.Y. Punks**](https://ordinals.com/inscription/753f663770d816f61acd35da8dd04e122eec8582e93ca36b2122f2d4ac206089i0) (24×24px) - sub 10 million club!  - deploy (& spritesheet) inscribes thanks to [@ZimmerAllDay](https://twitter.com/zimmerallday)

Show / Hide

![](diypunks/i/diypunks_max721.png)

[**721 D.I.Y. Punks V2**](https://ordinals.com/inscription/49fc0b24a6d2be8c78b1b468b77729e3516fae223766e64dc3e68d4051c52e89i0) (24×24px)

Show / Hide

![](diypunks-v2/i/diypunks-v2_max721.png)

[**1000 D.I.Y. Ordibots**](https://ordinals.com/inscription/e1be0a2827e42ffaacde0da19006566d9efb5b920e41d29fd59b5d0a3527cfc8i0) (32×32px)

Show / Hide

![](diyordibots/i/diyordibots_max1000.png)

[**999 D.I.Y. Ordibots V2**](https://ordinals.com/inscription/671293d418f7e05a503ffec6703b266ce08eb5522329774f2ac008b883a4e2a0i0) (32×32px)

Show / Hide

![](diyordibots-v2/i/diyordibots-v2_max999.png)

[**721 D.I.Y. Cool Cats**](https://ordinals.com/inscription/02ef2b3c240e56acd9ffad6c17e9758b5c5fd2d957fb80949f22de8c5ec6df83i0) (24×24px)   - deploy (& spritesheet) inscribes thanks to [@TheInscriptor](https://twitter.com/TheInscriptor)

Show / Hide

![](diycoolcats/i/diycoolcats_max721.png)

[**1000 Words on Bitcoin**](https://ordinals.com/inscription/ac685db241919af1e5556bfc5a452e40efc961b074d385de750863256272a8aai0) (102×32px) by  [@ZimmerAllDay](https://twitter.com/zimmerallday) -
see the [Words On Bitcoin Getting Started Guide and Documentation »](https://github.com/ZimmerAllDay/btcwords)

[**721 D.I.Y. Birdies**](https://ordinals.com/inscription/5cf5cb5cf764f6363e6485b85824909533b8d274c4a9988a9c7362e3d4e4409fi0) (24×24px)  -  deploy (& spritesheet) inscribes thanks to [@TheInscriptor](https://twitter.com/TheInscriptor), public domain ("do what you want") pixel art thanks to [@TheSkullCat](https://twitter.com/TheSkullCat)

**ORC-721 Protocol Update - Look Ma! No Spritesheet! It's "Recursive!"**

[**100 D.I.Y. (Recursive) Apes**](https://ordinals.com/inscription/610ad953a48ce514ca71933b40228a366ef5edb8f6581ac20dca3098d618c7b2i0) (24×24px)   - world's 1st recursive generative  (re-using recursive punk .PNG inscribes in 24×24px - thank you!)

Show / Hide

![](diyapes/i/diyapes.png)

[**100 D.I.Y. (Recursive) Aliens**](https://ordinals.com/inscription/3832d5d8dc247cfa3506343acca1f4a9f1a9f914a4e6f16589e0dac4fdb67c1ci0) (24×24px)  - world's 2nd recursive generative  (re-using recursive punk .PNG inscribes in 24×24px - thank you!)

Show / Hide

![](diyaliens/i/diyaliens.png)

[**100 D.I.Y. (Recursive) Martians - Aliens Vol. 2**](https://ordinals.com/inscription/b2426c302ad2807d832b994cb509000a5fa8ac9c08cce273b16400a8409b4c13i0) (24×24px)  - world's 1st recursive generative mix'n'match  (re-using recursive punks, recursive noun punks, 10 boring backgrounds, 7 martians, alien happy smile 1/1, and more .PNG inscribes in 24×24px - thank you!) -  deploy (& 10 boring backgrounds, 7 martians, alien happy smile 1/1, & more) inscribes thanks to [@612crypto_eth](https://twitter.com/612crypto_eth)

Show / Hide

![](diymartians/i/diymartians.png)

... let's remove boring backgrounds ...

![](diymartians/i/diymartians-remove_background.png)

[**100 Orange Pixels**](https://ordinals.com/inscription/429915c362dacc2b1f7d4a5f7d929ee04e52298c35a7fe9c4e5a29580691b364i0) (24×24px) by  [@ZimmerAllDay](https://twitter.com/zimmerallday) -
see the [Orange Pixels Getting Started Guide and Documentation »](https://github.com/ZimmerAllDay/orangepixels)

**ORC-721 Protocol Update - Look Ma! No More Quotes (`"""`)! No More Commas (`,,,`)! No More Arrays (`[[[]]]`)! No More Objects (`{}`)!  No More JSON! It's Text!**

[**100 D.I.Y. (Left-Looking) Phunks**](https://ordinals.com/inscription/09e3c57879b0a30239b088468277d009f838111d254eb22f35a9b2a31b77a5d4i0) (24×24px)  - world's 1st generative with og standard text deploy & mint format; deploy (& spritesheet) inscribes thanks to [@AlteredOracle](https://twitter.com/AlteredOracle)

[**100 D.I.Y. Maxi Biz (Punks)**](https://ordinals.com/inscription/7e238c49e16368a4b089fbd6f2ca4c866d415e3801f059e54f8e1025650560e1i0) (24×24px)

Show / Hide

![](diymaxibiz/i/diymaxibiz.png)

[**25 D.I.Y. (Recursive) Ordi Troops**](https://ordinals.com/inscription/24ab235103da2f2f4c6ba186e2bc56534a100395d218145af50e9b658e9d9a1fi0) (496×500px)  -  deploy inscribe thanks to [@ord_gen](https://twitter.com/ord_gen)

Wen [next] deploy?   You are welcome to announce your ORC-721 collections
in the [ordinal punks](https://ordinalpunks.com) discord (in the #generative-orc-721 channel)
or in the [ordinal phunks](https://twitter.com/OrdinalPhunksV0) discord (in the #random / General channel).

## D.I.Y. GENESIS PUNKS (MAX. 10 000) WEN MINT?

The idea is re(use) or "recurse on" all 133 .PNG inscriptions in
the recursive punks collection -
that are - surprise, suprise -  pixel-perfect copies of
the "originals" in the CryptoPunksData contract (Anno 2021).

Let's mint a new ordgen / ORC-721 collection (free, first-come/first-serve) - 10 000 D.I.Y. Genesis Punks - (re)using or (is it "recursing on"?) the .PNGs indexed 1 to 133 with the bonus bitcoin orange background at 0 - plus going beyond recursive punks
by matching the attribute ids in the CryptoPunksData in the generative dna ("on-chain" bitcoin metadata).

... read more at the [10 000 D.I.Y. Genesis Punks Readme »](genesis)

**Update** - Sorry for the bad news ...  unfortunately the deploy inscribe is broken ... i am heart broken too ...
the first line is missing in action e.g.  `og deploy genesis`.   If anyone can help out with a new inscribe, please do ... yes, you can.

PS:  Try the [D.I.Y. Genesis Punks (Image) Previewer »](https://ordbase.github.io/generative-orc-721/genesis)

---

# Generative ORC-721 Protocol / Standard for Bitcoin & Co.   (Also Known As OG, Ordgen, Ordinal Generative)

Author:  [Gerald Bauer](https://github.com/geraldb) ([Punk's Not Dead](https://github.com/cryptopunksnotdead), [Learn Pixel Art](https://github.com/learnpixelart), etc)

Let's deploy a new 100 d.i.y. phunk (pixel head) collection
in 8 seconds ;-) - yes, you can. Example - [Inscription No. 13418851](https://ordinals.com/inscription/09e3c57879b0a30239b088468277d009f838111d254eb22f35a9b2a31b77a5d4i0):

... in the standard text format:

```
og deploy diyphunks
name: D.I.Y. Phunks
max: 100
dim: 24x24
dd91c8b33dd19ccd8410e54c2099bfd50d4f777a186ee974fe4c15420c42ea0fi0
```

Classic JSON Format

``` json
{
    "p": "orc-721",
    "op": "deploy",
    "slug": "diyphunks",
    "name": "D.I.Y. Phunks",
    "max": 100,
    "dim": "24x24",
    "generative": "dd91c8b33dd19ccd8410e54c2099bfd50d4f777a186ee974fe4c15420c42ea0fi0"
}
```

That's it. Ready to mint the first d.i.y. phunk with the (generative) specs - `0`:

- 0 - ![](diyphunks/i/0_human.png) phunk (human) base

in standard text format:

```
og mint diyphunks 0
```

Classic JSON Format

``` json
{
   "p":"orc-721",
   "op":"mint",
   "s":"diyphunks",
   "g":[0]
}
```

![](diyphunks/i/phunk0.png)  4x
![](diyphunks/i/phunk0@4x.png)

and the second with the (generative) specs - `0 38`:

- 0 - ![](diyphunks/i/0_human.png)  punk (human) base
- 38 - ![](diyphunks/i/38_laser-eyes.png) laser eyes

in standard text format:

```
og mint diyphunks 0 38
```

Classic JSON Format

``` json
{
   "p":"orc-721",
   "op":"mint",
   "s":"diyphunks",
   "g":[0,38]
}
```

![](diyphunks/i/phunk1.png)  4x
![](diyphunks/i/phunk1@4x.png)

and the third with the (generative specs) - `59 0 38`:

- 59 - ![](diyphunks/i/59_bitcoin-pattern.png)  background - bitcoin pattern
- 0 - ![](diyphunks/i/0_human.png)  punk (human) base
- 38 - ![](diyphunks/i/38_laser-eyes.png) laser eyes

in standard text format:

```
og mint diyphunks 59 0 38
```

Classic JSON Format

``` json
{
   "p":"orc-721",
   "op":"mint",
   "s":"diyphunks",
   "g":[59,0,38]
}
```

![](diyphunks/i/phunk2.png)  4x
![](diyphunks/i/phunk2@4x.png)

and so on.

NEW!  Try the [D.I.Y. Phunks Previewer »](https://ordbase.github.io/generative-orc-721/diyphunks)

Where's the catch?   Step 0: To make  it work you can (re)use
existing inscribed spritesheets / art layers or inscribe your very own.
Read on.

## Spritesheet / Artwork Layers Inscriptions

To inscribe your spritsheets / art layers you have
two format options:

1) binary images "standalone"
2) binary images packed up in a "spritesheet" - ultra-compact (less bytes, saving sats!)

NOTE:  Yes, support for more formats upcoming - next stop - vector graphics (in .SVG).

Let's use the d.i.y (left-looking) phunks as an example.

### Format Option 1) Binary Image - Ultra-Compact

Inscribe the spritesheet / art layers as a single binary image file (image/png).

Example - [spritesheet.png (~4kb) @ Inscription No. 13412985](https://ordinals.com/inscription/dd91c8b33dd19ccd8410e54c2099bfd50d4f777a186ee974fe4c15420c42ea0fi0):

![](diyphunks/spritesheet.png)

4x

![](diyphunks/i/spritesheet@4x.png)

Note:  To make it work all sprites or attributes MUST be of the same image dimension (e.g. 24x24) and get referenced by number (starting with 0)
counting left-to-right and top-to-bottom.

Thus, for example `59 0 38` from the mint starter examples
in standard text format:

```
og mint diyphunks 59 0 38
```

Classic JSON Format

``` json
{
   "p":"orc-721",
   "op":"mint",
   "s":"diyphunks",
   "g":[59,0,38]
}
```

references the sprites / attributes no. 59 - ![](diyphunks/i/59_bitcoin-pattern.png),
no. 0 - ![](diyphunks/i/0_human.png),
no. 38- ![](diyphunks/i/38_laser-eyes.png)
and the sprites / attributes
get merged / stacked / pasted-on-top-of-each-other in the order listed resulting in ![](diyphunks/i/phunk2.png).

Aside - Pasted On Top Of Each Other?!

Yes, the (generative) magic is the transparent background / color!
If you merge a solid / fully opaque image (let's say all black)
on-top-of another image, than it gets completly overwritten -
to make the (generative) magic work - use the transparent color
in your sprite / art layers.

## Deploy Inscriptions

## Mint Inscriptions

## Sample Collections

### Sample No. 1 - D.I.Y. Orange-Pilled Punks (w/ Laser Eyes Optional)

**Format Option 1) Binary Image - Ultra-Compact**

Example - [diypunks/spritesheet.png](diypunks/spritesheet.png) (~4kb):

![](diypunks/spritesheet.png)

4x

![](diypunks/i/spritesheet@4x.png)

and the deploy inscription:

```
og deploy diypunks
name: D.I.Y. Punks
max: 721
dim: 24x24
cf5df319bbe23fa3d012e5ee0810700c8e82aebff41164246f0d87d7b60a9903i0
```

Classic JSON Format

``` json
{
    "p": "orc-721",
    "op": "deploy",
    "slug": "diypunks",
    "name": "D.I.Y. Punks",
    "max": 721,
    "dim": "24x24",
    "generative": "cf5df319bbe23fa3d012e5ee0810700c8e82aebff41164246f0d87d7b60a9903i0"
}
```

and the mint inscriptions...

Try the [D.I.Y. Punks Previewer »](https://ordbase.github.io/generative-orc-721/diypunks)

To learn more or read-up on the D.I.Y. Punks OG & V2
inscribed on bitcoin (btc), see [D.I.Y. Punks Read Me 'n' Frequently Asked Questions (F.A.Q.s) & Answers »](diypunks)

### Sample No. 2 - D.I.Y. Wiener - Edmund "Mundl" Sackbauer et al  (SOON!)

**Format Option 1) Binary Image - Ultra-Compact**

Example - no2/spritesheet.png (~??kb):

![](no2/spritesheet.png)

4x

![](no2/spritesheet@4x.png)

and the deploy inscription:

```
og deploy diywiener
name: D.I.Y. Wiener
max: 100
dim: 32x32
<spritesheet/art layers inscription id here>
```

Classic JSON Format

``` json
{
    "p": "orc-721",
    "op": "deploy",
    "slug": "diywiener",
    "name": "D.I.Y. Wiener",
    "max": 100,
    "dim": "32x32",
    "generative": "<spritesheet/art layers inscription id here>"
}
```

and the mint inscriptions...

### Sample No. 3 - D.I.Y. Ordibots

What's different compared to Generative BRC-721 (by Jerry Fanelli)?
Let's compare the Ordibots (BRC-721)
and D.I.Y. Ordibots (ORC-721) inscriptions!

**Format Option 1) Binary Image - Ultra-Compact**

Example - [diyordibots/spritesheet.png](diyordibots/spritesheet.png) (~3kb):

![](diyordibots/spritesheet.png)

4x

![](diyordibots/i/spritesheet@4x.png)

and the deploy inscription:

```
og deploy diyordibots
name: D.I.Y. Ordibots
max: 1000
dim: 32x32
<spritesheet/art layers inscription id here>
```

Classic JSON Format

``` json
{
    "p": "orc-721",
    "op": "deploy",
    "slug": "diyordibots",
    "name": "D.I.Y. Ordibots",
    "max": 1000,
    "dim": "32x32",
    "generative": "<spritesheet/art layers inscription id here>"
}
```

and the mint inscriptions:

ordibot no. 0 specs:
- background: ![](diyordibots/i/2_brown.png) 2 - brown
- accessories: ![](diyordibots/i/5_none.png) 5 - none
- body:   ![](diyordibots/i/16_standard-oval.png) 16 - standard-oval
- belly:  ![](diyordibots/i/23_empty.png) 23 - empty
- face: ![](diyordibots/i/9_surprised.png)  9 - surprised

```
og mint diyordibots 2 5 16 23 9
```

Classic JSON Format

``` json
{
   "p":"orc-721",
   "op":"mint",
   "s":"diyordibots",
   "g": [2,5,16,23,9]
}
```

![](diyordibots/i/ordibot0.png)  4x
![](diyordibots/i/ordibot0@4x.png)

ordibot no. 1 specs:

- background: ![](diyordibots/i/0_blue.png)  0 - blue
- accessories:  ![](diyordibots/i/4_antenna.png)  4 - antenna
- body:  ![](diyordibots/i/16_standard-oval.png)  16 - standard-oval
- belly:  ![](diyordibots/i/23_empty.png)  23 - empty
- face:  ![](diyordibots/i/8_neutral.png)  8 - neutral

```
og mint diyordibots 0 4 16 23 8
```

Classic JSON Format

``` json
{
   "p":"orc-721",
   "op":"mint",
   "s":"diyordibots",
   "g": [0,4,16,23,8]
}
```

![](diyordibots/i/ordibot1.png)  4x
![](diyordibots/i/ordibot1@4x.png)

and so on.

Try the [D.I.Y. Ordibots Previewer »](https://ordbase.github.io/generative-orc-721/diyordibots)

**Compare to Gen-BRC-721**

The deploy inscription ([no. 8 326 719](https://ordinals.com/content/b7205d40f3b1b1486567f0d6e53ff2812983db4c03ad7d3606812cd150c64802i0))
on May 21, 2023 by Jerry Fanelli

``` json
{
  "p": "gen-brc-721",
  "op": "deploy",
  "slug": "ordibots",
  "name": "OrdiBots",
  "supply": 1000,
  "trait_types": [
     "background",
     "accessories",
     "body",
     "belly",
     "face"
    ],
  "traits": {
       ...
    }
}
```

The 1000 mint inscriptions

``` json
{
   "p":"gen-brc-721",
   "op":"mint",
   "s":"ordibots",
   "t_ins":["b7205d40f3b1b1486567f0d6e53ff2812983db4c03ad7d3606812cd150c64802i0"],
   "h":"2b936881d34e7be726d6ad3f23edbdaf84ae5974e33c987505d4d70a144859d5",
   "id":"0",
   "a":[[0,"brown"],
        [0,"none"],
        [0,"standard-oval"],
        [0,"empty"],
        [0,"surprised"]]
}
```

``` json
{
   "p":"gen-brc-721",
   "op":"mint",
   "s":"ordibots",
   "t_ins":["b7205d40f3b1b1486567f0d6e53ff2812983db4c03ad7d3606812cd150c64802i0"],
   "h":"ad82a097c19a5d349ab99db3ad9102caf624486702d9a147f4d3003162b90222",
   "id":"1",
   "a":[[0,"blue"],
        [0,"antenna"],
        [0,"standard-oval"],
        [0,"empty"],
        [0,"neutral"]]
}
```

and so on.

##  Design

What's different compared to Generative BRC-721 (by Jerry Fanelli)?

Three main ideas:

1) Make it (even) easier
2) Use less bytes (and, thus, save on inscription fees)
3) Many more options (and less restrictions / requirements)

## History / Timeline

Birth of Ordinals

Birth of BRC-20 Tokens

May 23rd, 2023 - Birth of Generative BRC-721

May 27th, 2023 - Hearing first and reading-up on the Generative BRC-721 docu / write-up by Jerry Fanelli and the 1000 Ordibots collection

May 28th, 2023 - Birthday!

## License

The Generative ORC-721 protcol, sample scripts & collections are dedicated to the public domain.
Use it as you please with no restrictions whatsoever.

# Questions? Comments?

Post them over at the [Help & Support](https://github.com/geraldb/help) page. Thanks.


text:
# ORC-721 Collection Timeline

**2023**

## Week 01 - Genesis

Mon, May 29th -  [**721 D.I.Y. Punks**](https://ordinals.com/inscription/753f663770d816f61acd35da8dd04e122eec8582e93ca36b2122f2d4ac206089i0) (24×24px) - sub 10 million club!  - deploy (& spritesheet) inscribes thanks to [@ZimmerAllDay](https://twitter.com/zimmerallday)

Wed, May 31st - [**721 D.I.Y. Punks V2**](https://ordinals.com/inscription/49fc0b24a6d2be8c78b1b468b77729e3516fae223766e64dc3e68d4051c52e89i0) (24×24px)

Wed, May 31st - [**1000 D.I.Y. Ordibots**](https://ordinals.com/inscription/e1be0a2827e42ffaacde0da19006566d9efb5b920e41d29fd59b5d0a3527cfc8i0) (32×32px)

Wed, May 31st - [**999 D.I.Y. Ordibots V2**](https://ordinals.com/inscription/671293d418f7e05a503ffec6703b266ce08eb5522329774f2ac008b883a4e2a0i0) (32×32px)

Fri, Jun 2nd - [**ORC-721 Week 01 Collection - 721 D.I.Y. Cool Cats**](https://ordinals.com/inscription/02ef2b3c240e56acd9ffad6c17e9758b5c5fd2d957fb80949f22de8c5ec6df83i0) (24×24px)   - deploy (& spritesheet) inscribes thanks to [@TheInscriptor](https://twitter.com/TheInscriptor)

## Week 02

Wed, Jun 7th - [**1000 Words on Bitcoin**](https://ordinals.com/inscription/ac685db241919af1e5556bfc5a452e40efc961b074d385de750863256272a8aai0) (102×32px) by  [@ZimmerAllDay](https://twitter.com/zimmerallday) -
see the [Words On Bitcoin Getting Started Guide and Documentation »](https://github.com/ZimmerAllDay/btcwords)

Sat, Jun 10th -
[**ORC-721 Week 02 Collection - 721 D.I.Y. Birdies**](https://ordinals.com/inscription/5cf5cb5cf764f6363e6485b85824909533b8d274c4a9988a9c7362e3d4e4409fi0) (24×24px)  -  deploy (& spritesheet) inscribes thanks to [@TheInscriptor](https://twitter.com/TheInscriptor), public domain ("do what you want") pixel art thanks to [@TheScullCat](https://twitter.com/TheSkullCat)

## Week 03

...


text:
The source for the  website (& services) online @ <https://ordbase.github.io/generative-orc-721>.

## Credits

Thanks to @jokie for starting the Generative ORC-721 Previewer - see the OG fiddles
- DIY Punk Previewer @ https://jsfiddle.net/a6mnft3d/34/show
- Generative ORC-721 Previewer @ https://jsfiddle.net/uf95w2j4/7/show


text: title: "Ordgen / ORC-721"


text:
#  Ordgen / ORC-721

Welcome.

New to Generative ORC-721?  See the [Getting Started Guide & Documentation »](https://github.com/ordbase/generative-orc-721)

Ordgen / ORC-721 Collection (Image) Previewers include:

## Standard Text Format Series

- [D.I.Y. Phunks »](diyphunks)
- [D.I.Y. Maxi Biz (Punks) »](diymaxibiz)
- [D.I.Y. Genesis Punks »](genesis)

##  "Classic" JSON Format Series

- [D.I.Y. Punks »](diypunks)
- [D.I.Y. Ghost Punks »](diyghostpunks)
- [D.I.Y. Ordibots »](diyordibots)
- [D.I.Y. Cool Cats »](diycoolcats)
- [D.I.Y. Birdies »](diybirdies)
- [D.I.Y. Apes »](diyapes)
- [D.I.Y. Aliens »](diyaliens)
- [D.I.Y. Martians - Aliens Vol. 2 »](diymartians)

**More**

- [Words On Bitcoin @ ZimmerAllDay »](https://zimmerallday.github.io/btcwords)
- [Orange Pixels @ ZimmerAllDay »](https://zimmerallday.github.io/orangepixels)

<!--
debug github pages (in subdirectory)

baseurl: {{ site.baseurl }}

-->


text:
  DIY Barbies

  Directions: click on the map below to preview your DIY Barbie.
  Press clear to start over.

  When you're happy, use the attribute list generated.

  <canvas id="canvas" width="240" height="240"></canvas>

   <button id="clear">Clear</button>

DIY Barbies is a project by the ordgen / ORC-721 community.
  Learn more in the Ordgen / ORC_721 discord
  (in the #general channel)
  and the generative-orc-721 github
  This previewer adopted from a fiddle written by Jokie


text:
   The D.I.Y. Ordi Troops moved to its new home here ->
    https://github.com/orc721/orditroops.starter.
    Please, update your link.


text:
    DIY Ordibots Previewer

    Directions: click on the map below to preview your DIY Ordibot.
    Press clear to start over.

    When you're happy, use the attribute list generated.

    <canvas id="canvas" width="320" height="320"></canvas>

     <button id="clear">Clear</button>

    DIY Ordibots is a project by the ORC-721 community.
    Learn more on the Ordinal Punks discord (in the #generative-orc-721 channel)
    and the generative-orc-721 github
    This previewer adopted from a fiddle written by Jokie


text:
  DIY (Recursive) Aliens Previewer

  Directions: click on the map below to preview your DIY (Recursive) Alien.
  Press clear to start over.

  When you're happy, use the attribute list generated.

  <canvas id="canvas" width="240" height="240"></canvas>

   <button id="clear">Clear</button>

DIY (Recursive) Aliens is a project by the ORC-721 community.
  Learn more on the Ordinal Punks discord (in the #generative-orc-721 channel)
  and the generative-orc-721 github
  This previewer adopted from a fiddle written by Jokie


text:
  DIY Punks Previewer

  Directions: click on the map below to preview your DIY Punk.
  Press clear to start over.

  When you're happy, use the attribute list generated.

  <canvas id="canvas" width="240" height="240"></canvas>

   <button id="clear">Clear</button>

DIY Punks is a project by the Ordinal Punks community.
  Learn more on the Ordinal Punks discord (in the #generative-orc-721 channel)
  and the generative-orc-721 github
  This previewer adopted from a fiddle written by Jokie


text:
  DIY Ghost Punks Previewer

  Directions: click on the map below to preview your DIY Ghost Punk.
  Press clear to start over.

  When you're happy, use the attribute list generated.

  <canvas id="canvas" width="240" height="240"></canvas>

   <button id="clear">Clear</button>

  DIY Ghost Punks is a project by @ZimmerAllDay.
  Learn more on the Ordinal Punks discord (in the #generative-orc-721 channel)
  and the generative-orc-721 github
  This previewer adopted from a fiddle written by Jokie