Built-in primitive types

Issuers can start to issue credentials of these primitives types without going through the type creation process.

Based on Galxe’s experience, these types should cover a large portion of common use cases.

Type IDNameDescriptionDefinitionExample
1UnitThe simplest credential type that does not contains any field. Owning a credential of this type means that the owner, indicated by the ID in header, is endorsed by the issuer for the context.empty1. Have you ever been followed by Elon Musk.
2. Have you ever made any donation to Wikipedia.
3. Have you ever been a LP for Uniswap V2 before 2021.
2BooleanA credential with a bool claim. Comparing with Unit type, theoretically the set has two values instead of one. A practical difference is that Boolean type gives the owner the ability to choose to hide or reveal the value in the proof. There are some use cases, but in most cases, the Unit type is preferred.val:bool;Do you have an early supporter role in Galxe’s discord?
Since Galxe only issues credentials of this context to its guild member, owner can choose to reveal this value, showing that he is an early supporter, or without revealing the value, proving that he is at least a member of the guild.
3ScalarA credential with an unsigned integer claim, 248-bit. Unless 256-bit range is necessary, this type is recommended for credentials storing an unsigned integer value.val:uint<248>;1. Holder’s loyalty points of some brand.
2. UNIX Timestamp of the holder’s first transaction on Ethereum.
3. ERC20 token balance on height 1000, when representing the token’s total_supply * decimals requires less than 248 bits.
4Scalar256A credential with an 256-bit unsigned integer claim. Note that due to the scalar field size limit in some verification stack (including babyzk), the output signal of a 256-bit value will represented as two public inputs, making on-chain verification higher than the Scalar type.val:uint<256>;1. ERC20 token balance, where the ERC20 token balance need the full 256-bit encoding.
5PropertyA credential with a 248-bit property claim, using user-defined hash algorithm, with 1 equality check.val:prop<248,c,1>;1. Name of holder’s first pet.
2. Holder’s first name on passport.

Artifacts

Artifacts required to generate and verify proofs can be found at the following IPFS location:

Type NameIPFS
Unithttps://ipfs.io/ipfs/QmX8dx6onZornDd5wsM2raWDz1prRrjLcrNwgZHWonYHvw
Booleanhttps://ipfs.io/ipfs/QmZQBtQ8nxcUM6fLgG4NrFkgmZwpjgcqPz8PQwgvRbpNQK
Scalarhttps://ipfs.io/ipfs/QmPABvgq3Rnu8jqMjXx2HhHAY9h9EL2Q2ZizAUZwVFuNfn
Scalar256https://ipfs.io/ipfs/QmRUR9uyzJ9fL9SodKEB2yA43aez3axHJH9m3Myu8nsv4o
Propertyhttps://ipfs.io/ipfs/QmUv7qrsaaFFUDTouNCRQ8SF6B7UewQGNpANBFuqh6vdw3

Inside each file you will find corresponding resource CIDs for circom file, verifier solidity code, verification key, wasm, and zkey. e.g. here is the resource files for type “unit”

FileIPFS
circom_urihttps://ipfs.io/ipfs/QmW4SgG4pDDLyFLy7V12QxMSx5X7tAqyeA4kgEFR1oURba/circuit.circom
verifier_urihttps://ipfs.io/ipfs/QmW4SgG4pDDLyFLy7V12QxMSx5X7tAqyeA4kgEFR1oURba/verifier.sol
vkey_urihttps://ipfs.io/ipfs/QmW4SgG4pDDLyFLy7V12QxMSx5X7tAqyeA4kgEFR1oURba/circuit.vkey.json
witness_wasm_urihttps://ipfs.io/ipfs/QmW4SgG4pDDLyFLy7V12QxMSx5X7tAqyeA4kgEFR1oURba/circom.wasm
zkey_urihttps://ipfs.io/ipfs/QmW4SgG4pDDLyFLy7V12QxMSx5X7tAqyeA4kgEFR1oURba/circuit_final.zkey

Alternatively, you can find artifacts in our github repo.