# Infrastructure Overview

{% hint style="danger" %}
Please note that all information and code snippets provided in this section are for educational purposes only and not to be directly deployed in production.
{% endhint %}

## Infrastructure Components

The Creditcoin Oracle is intended for use by DApp builders. However, in order to use the oracle *effectively* DApp teams will need to set up some infrastructure of their own.

### Source Chain Smart Contract

> Deployed on source chain like <img src="https://1740410107-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVp3bVdljVxZuwysnIzZ1%2Fuploads%2FzN7KJNKew9VX4QvOd1zI%2Feth-diamond-purple.7929ed26.png?alt=media&#x26;token=6acf48bb-010a-4feb-a563-d91e4ebcfe7f" alt="" data-size="line">  `Ethereum`, `Sepolia`

**What to implement:** A smart contract that supports the DApp's source chain logic and emits events that can be verified on Creditcoin.

**Key requirements:**

* Emit events with the data the DApp needs to verify
* Events should be structured to allow easy extraction of relevant fields
* Contract should handle any source chain-specific logic (e.g., burning tokens)

**Example:** To support a token bridge DApp the source chain smart contract might be an ERC20 contract that emits `TokensBurned` events when tokens are burned.

### Universal Smart Contract

> Deployed on the execution chain, <img src="https://1740410107-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVp3bVdljVxZuwysnIzZ1%2Fuploads%2FNAKy4UUXIWbarZjUxJIV%2Fcreditcoin-CTC-logo.png?alt=media&#x26;token=acf9a8d0-310e-49be-a7cd-17bb73895786" alt="" data-size="line"> `Creditcoin`

**What to implement:** A smart contract that verifies cross-chain transaction data using the Native Query Verifier Precompile (address `0x0FD2`) and then executes the DApp's business logic.

**Key responsibilities:**

* Receives proofs (Merkle and continuity) and encoded transaction data from workers via a smart contract call
* Calls the Native Query Verifier Precompile on Creditcoin to verify proofs synchronously
* Extracts transaction/event data from verified transaction bytes
* Executes DApp Business Logic or calls separate business logic contract using the verified data

**Example:** In a token bridge DApp, the USC interprets oracle-provided data corresponding to the burn event on the source chain.

### DApp Business Logic Smart Contracts

> Deployed to the execution chain, <img src="https://1740410107-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVp3bVdljVxZuwysnIzZ1%2Fuploads%2FNAKy4UUXIWbarZjUxJIV%2Fcreditcoin-CTC-logo.png?alt=media&#x26;token=acf9a8d0-310e-49be-a7cd-17bb73895786" alt="" data-size="line"> `Creditcoin`

**What to implement:** One or more smart contracts that contain their DApp's state and business logic.

**Contract organization:** DApp developers have flexibility in how they organize their code:

* **Combined pattern**: USC and business logic code can be kept in the same contract. This works well for simple use cases where the USC contract directly implements the business logic (e.g., minting tokens).
* **Separated pattern**: USC and business logic can be kept in separate contracts. The USC contract handles verification and then calls separate business logic contracts after verification succeeds. This pattern provides better modularity and is recommended for complex DApps.

**Key responsibilities:**

* Store DApp state (e.g., token balances, user data)
* Implement DApp-specific logic (e.g., minting tokens, updating balances)
* Provide functions that can be called by their USC contract
* Enforce access control (typically only allow calls from their USC contract)

**Example:** For a token bridge, this might be an ERC20 contract on Creditcoin that mints tokens when the USC contract verifies a burn event from the source chain.

**Integration pattern:**

* Grant the USC contract special permissions (e.g., minter role, admin role)
* USC contract calls business logic functions after verifying cross-chain data
* Business logic contracts validate inputs and update state accordingly

### Oracle Worker

> Deployed :computer: `offchain`

**What to implement:** An off-chain service that monitors source chain events and automatically submits verified transactions to their USC contract.

**Key responsibilities:**

1. Listen for events from the Source Chain Smart Contract
2. Wait for the block containing the event to be attested on Creditcoin
3. Use the Proof Generation API to get Merkle and continuity proofs
4. Call the USC contract with the proofs and encoded transaction data
5. Retry failed transactions, track processing status, prevent duplicates etc

**Basic worker flow:**

{% @mermaid/diagram content="flowchart LR
A\["1. Detect Event"] --> B\["2. Wait for Attestation"] --> C\["3. Call Proof API"] --> D\["4. Receive Proofs"] --> E\["5. Call USC"] --> F\["6. Verify & Execute"]
" %}

### Complete Flow

With all four components in place:

1. **User** signs transaction on source chain → emits event
2. **Oracle Worker** detects event → waits for attestation → fetches proofs → calls USC
3. **USC Contract** verifies proofs → extracts data → calls Business Logic Contract
4. **Business Logic Contract** executes DApp logic → updates state

This enables seamless cross-chain interoperability where a transaction on one chain automatically triggers DApp logic execution on Creditcoin!

## Next Steps

[source-chain-smart-contracts](https://docs.creditcoin.org/usc/dapp-builder-infrastructure/source-chain-smart-contracts "mention")

*Check out* [*this tutorial*](https://github.com/gluwa/usc-testnet-bridge-examples) *for an example of how to use the Creditcoin stack to set up a decentralized trustless bridge.*&#x20;