Skip to main content

Concept

This module facilitates decentralised applications to register the verification requirements and post verification action(s) to perform state change on chain.

For more background design information, see the offchain verifiable data notary section.

The sequence of events is as follows:

In the case of smart contract instantiation, the instantiated contract address is stored in the module under the NotaryInfoId key. This can then be used by the applications to manage the state of the notarised object across other modules / contracts.

Application deploying entities are responsible to upload / select code suitable to be registered as VerifierCodeId and PVACodeId. It is the responsibility of the application to ensure that the code uploaded is secure and does not have any vulnerabilities.

Smart Contract Requirements

The verification mechanism smart contracts must implement the following trait

/// Verification Mechanism Contracts must implement this trait
pub mod vm_trait {
use super::*;
/// The trait common for verifier contracts
#[interface]
pub trait VerificationMechanismTrait {
type Error: From<StdError>;

#[sv::msg(sudo)]
fn sudo(&self, ctx: SudoCtx, msg: VmSudoVerifyInput) -> Result<Response, Self::Error>;
}
}

The post verification action can be in the form of:

  • smart contract instantiation
  • smart contract execution
/// Post Verification Exec Contracts must implement this trait
pub mod pve_trait {
use super::*;

#[interface]
pub trait PostVerificationExecTrait {
type Error: From<StdError>;

#[sv::msg(exec)]
fn notary_pve(
&self,
ctx: ExecCtx,
ver_input: VerInput,
ver_output: Binary,
) -> Result<Response, Self::Error>;
}
}

/// Post Verification Inst Contracts must have instantiate method that takes the following InstMsg
#[cw_serde]
pub struct PostVerInstMsg {
pub verification_input: VerInput,
pub verifiaction_output: Binary,
}

/// The input that went into the verification mechanism
#[cw_serde]
pub struct VerInput {
pub input: Binary,
pub caller: String,
}