Organization
Signature Request Invite
Signature Request
Witness
Organization Link
Organization Member
Price Oracle
- About Price Oracle
- GETGet Median MXN/USD
- GETList Median MXN/USD
- GETGet Daily MXN/USD
- GETList Daily MXN/USD
- GETGet Weekly MXN/USD
- GETList Weekly MXN/USD
- GETGet Monthly MXN/USD
- GETList Monthly MXN/USD
- GETGet Median USDC/USD
- GETList Median USDC/USD
- GETGet Daily USDC/USD
- GETList Daily USD/USDC
- GETGet Weekly USDC/USD
- GETList Weekly USDC/USD
- GETGet Monthly USDC/USD
- GETList Monthly USDC/USD
- GETGet Median USDC/MXN
- GETList Median USDC/MXN
- GETGet Daily USDC/MXN
- GETList Daily USDC/MXN
- GETGet Weekly USDC/MXN
- GETList Weekly USDC/MXN
- GETGet Monthly USDC/MXN
- GETList Monthly USDC/MXN
Endorsable Definition
An Endorsable is a tokenized document in the blockchain created by an organization. Given it’s nature, it’s entirely owned by the mobile app user (a subject) through their wallet controlled by its digital signature.
Its implementation is compliant with e-commerce regulations and digital stocks under the Mexican legal framework. Every time it’s endorsed to a new owner (i.e. transferred), the digital signature is validated and recorded immutably in the blockchain. This way, the ownership history is transparent and secure.
Although the blockchain is public, the content of the Endorsable is not recorded. Instead, only its id is stored given it’s the only requirement for tracking purposes.
The API can only access Endorsables within the organization they belong to.
Endorsables can be traded permissionlessly with third-party infrastructure like its marketplace in OpenSea.
The BigInt scalar type represents non-fractional signed whole numeric values.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
The algorithm used for hashing the document.
SHA256 A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Hash of the document to witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Combined merkleized conservation strategy.
Individual NOM151 conservation strategy.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
The BigInt scalar type represents non-fractional signed whole numeric values.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
The BigInt scalar type represents non-fractional signed whole numeric values.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
AWS S3 URI path to the certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
SHA256 message digest of the issuer's certificate.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
AWS S3 URI path to the issuer certificate's PEM data.
The name of the certificate authority.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The hash of the issuer's certificate.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The issuer's certificate public key. This is the public key that identifies messages the issuer has signed a certificate for a subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
"Country" of the issuer.
Email address of the issuer.
"Municipio/Delegación" of the issuer.
Name of the organization or company. "Razón Social" in Spanish.
Name of the unit within the organization. "Unidad Organizacional" in Spanish.
Postal code of the issuer.
RFC of the issuer.
"Entidad Federativa" of the issuer.
Street address of the issuer.
The latest date at which the certificate is valid.
The earliest date at which the certificate is valid.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
Whether the certificate has been revoked by the issuer.
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona física o moral" in spanish).
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The version of the X.509 standard that the certificate conforms to.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The content data to be signed.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Invites to sign the content.
Custom name for the signature request.
The organization requesting the signature.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
Amount of invites that have signed the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Witness that attest the content using a merkle proof
Date when the signature request was rejected. Only present if rejected.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED The subject this invite is linked to.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
AWS S3 URI path to the certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
SHA256 message digest of the issuer's certificate.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The latest date at which the certificate is valid.
The earliest date at which the certificate is valid.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
Whether the certificate has been revoked by the issuer.
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona física o moral" in spanish).
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The version of the X.509 standard that the certificate conforms to.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Date at which the signature request invite was rejected. Only present if rejected.
The signature from the certificate as a hexadecimal string.
Date at which the signature request invite was signed. Only present if signed.
Witness that attest the signature using a merkle proof
The algorithm used for hashing the document.
SHA256 A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Hash of the document to witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Combined merkleized conservation strategy.
Individual NOM151 conservation strategy.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
The algorithm used for hashing the document.
SHA256 A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Hash of the document to witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Combined merkleized conservation strategy.
Individual NOM151 conservation strategy.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
The algorithm used for hashing the document.
SHA256 A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Hash of the document to witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Policies of the Organization.
Defines the policies for signatureRequests.
Type of conservation strategy to use by default at signature request readiness (ie. when draft is false).
NOM151, MERKLEIZED, WITNESS_CO Quotas of the Organization.
API is enabled for the organization.
The amount of grouped NOM151 certificates available to the organization.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The amount of NOM151 certificates available to the organization.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Address of the initial claiming subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The chain ID where the claim is authorized.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
The BigInt scalar type represents non-fractional signed whole numeric values.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
The algorithm used for hashing the document.
SHA256 A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Hash of the document to witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Address of the initial claiming subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The chain ID where the claim is authorized.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The transaction chain ID.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Signature Request the witness is associated with. May not be present if the witness was via the API.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Witness conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
The timestamp issued by the provider.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
AWS S3 URI path to the certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
SHA256 message digest of the issuer's certificate.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
AWS S3 URI path to the issuer certificate's PEM data.
The name of the certificate authority.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The hash of the issuer's certificate.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The issuer's certificate public key. This is the public key that identifies messages the issuer has signed a certificate for a subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
"Country" of the issuer.
Email address of the issuer.
"Municipio/Delegación" of the issuer.
Name of the organization or company. "Razón Social" in Spanish.
Name of the unit within the organization. "Unidad Organizacional" in Spanish.
Postal code of the issuer.
RFC of the issuer.
"Entidad Federativa" of the issuer.
Street address of the issuer.
The latest date at which the certificate is valid.
The earliest date at which the certificate is valid.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
Whether the certificate has been revoked by the issuer.
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona física o moral" in spanish).
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The version of the X.509 standard that the certificate conforms to.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The content data to be signed.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Invites to sign the content.
Custom name for the signature request.
The organization requesting the signature.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
Amount of invites that have signed the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Witness that attest the content using a merkle proof
Date when the signature request was rejected. Only present if rejected.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED The subject this invite is linked to.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
AWS S3 URI path to the certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
SHA256 message digest of the issuer's certificate.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The latest date at which the certificate is valid.
The earliest date at which the certificate is valid.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
Whether the certificate has been revoked by the issuer.
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona física o moral" in spanish).
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The version of the X.509 standard that the certificate conforms to.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Date at which the signature request invite was rejected. Only present if rejected.
The signature from the certificate as a hexadecimal string.
Date at which the signature request invite was signed. Only present if signed.
Witness that attest the signature using a merkle proof
The algorithm used for hashing the document.
SHA256 A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Hash of the document to witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Combined merkleized conservation strategy.
Individual NOM151 conservation strategy.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
A subject is a person or an organization ("persona física o moral" in Spanish) identified by a certificate.
Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The transaction chain ID.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Signature Request the witness is associated with. May not be present if the witness was via the API.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The content data to be signed.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Invites to sign the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The content data to be signed.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Invites to sign the content.
Custom name for the signature request.
The organization requesting the signature.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
Amount of invites that have signed the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Witness that attest the content using a merkle proof
Date when the signature request was rejected. Only present if rejected.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED The subject this invite is linked to.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Date at which the signature request invite was rejected. Only present if rejected.
The signature from the certificate as a hexadecimal string.
Date at which the signature request invite was signed. Only present if signed.
Witness that attest the signature using a merkle proof
Custom name for the signature request.
The organization requesting the signature.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Policies of the Organization.
Defines the policies for signatureRequests.
Quotas of the Organization.
API is enabled for the organization.
The amount of grouped NOM151 certificates available to the organization.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The amount of NOM151 certificates available to the organization.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
Amount of invites that have signed the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Witness that attest the content using a merkle proof
The algorithm used for hashing the document.
SHA256 A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Hash of the document to witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Address of the initial claiming subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The chain ID where the claim is authorized.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Name of the subject.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
CURP of the subject. It is a unique identifier for people in Mexico.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Certificate of the subject.
Country of the subject.
Email address of the subject.
The push notification token associated with the certificate. Used for sending notifications to the user.
Invite for the subject to sign Plumaa own terms and conditions.
Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The transaction chain ID.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Signature Request the witness is associated with. May not be present if the witness was via the API.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Witness conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
The timestamp issued by the provider.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Witness conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
The timestamp issued by the provider.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.