# USC Architecture Overview
{% hint style="danger" %}
**Outdated Documentation:** This page covers the architecture used for USC V1, which was deprecated on 2026-03-30. For the latest documentation, please visit: [usc documentation](https://docs.creditcoin.org/usc)
{% endhint %}
## **Overview**
A *decentralized oracle* is a provider of information external to a blockchain which does not rely on a centralized trusted entity for its security. Instead, each step in the oracle’s data provisioning process is executed by a group of independent actors, none of which have the power to unilaterally interfere with data provisioning outcomes. By adding decentralized data provisioning to Creditcoin, we enable it to trustlessly support smart contracts which can access the state of *any* blockchain. These smart contracts, known as **Universal Smart Contracts** (`USC`s), enable the seamless merging of isolated pools of liquidity as well as novel cross chain logic.
## **Key Terms**
* **Source chain:** A client chain for which Creditcoin supports bridging. We begin by first supporting `EVM` chains such as `Ethereum`, with the eventual goal to enable data provisioning from any chain.
* **Execution chain:** Creditcoin blockchain with oracle infrastructure and Universal Smart Contract support.
* **Attestation:** A cryptographic commitment to data from source chain blocks, validated through consensus.
* **Proof:** A cryptographic proof certifying that parts of a given transaction occurred on a *source chain*.
> We only prove *parts* of a transaction as transactions can be quite large, involving many smart contract calls and emitted events. Proofs like `STARK` can get quite expensive for large transactions, so we restrict the proof to the parts absolutely necessary to inform *execution chain* state transitions.
* **Query:** A request to prove certain fields of a transaction. Each query specifies which *source chain*, *block number*, and *transaction* it wants to be proven.
## Architecture
The Creditcoin Decentralized Oracle relies on 3 decentralized groups of actors:
### Attestors
These make assertions about their view of the latest state of a *source chain,* such as Ethereum. Creditcoin doesn't trust any single attestor's report about changes to a source chain's state. Instead, a decentralized group of attestors must reach consensus on what state changes, if any, have occurred.
> For more information on attestors, check out the [attestation](https://docs.creditcoin.org/usc/creditcoin-oracle-subsystems/attestation "mention") section of the docs.
### Provers
These generate *cryptographic proofs* as a response to user submitted queries. Each query requests information on *parts* *of a transaction* (Ex: `to`, `from`, `value`) on a client *source chain*. The prover then processes that query to make those parts of the transaction available on Creditcoin. The prover conducts its work in three steps:
1. First, it uses attestations to prove that the block containing our query transaction is a part of the source chain’s state.
2. Second, it uses merkle proofs to show that the block does in fact contain the query transaction.
3. Finally, a cryptographic proof is generated that, upon verification, proves both these properties.
> For more information on proving, check out the [proving](https://docs.creditcoin.org/usc/usc-v1/creditcoin-oracle-subsystems/proving "mention") section of the docs.
### Validators
These form the *authority set* of the Creditcoin blockchain. They act as gatekeepers, ensuring that the attestors and provers perform their work correctly. Validators check attestor signatures on attestations to verify that a sufficient quorum voted before committing those attestations to on-chain storage. Later, validators run proof verification logic to ensure that the proofs submitted by provers are valid. The fields provided by a proof become available to smart contract logic on Creditcoin only after validators finalize a block containing that proof.
### Interoperability
The net effect of all this work is that third-party builders can create contracts on Creditcoin which have secure, **seamless** access to data on other chains. Such contracts could, for instance, securely burn `ETH` on Ethereum and then *trustlessly* mint `ETH` on Creditcoin, without having to rely on any centralized party.
Builders can leverage these properties to create universal smart contracts which support their own custom cross-chain DApp business logic.
> For more information on how to set up your DApp's logic to leverage Creditcoin `USC`, check out the [dapp-builder-infrastructure](https://docs.creditcoin.org/usc/usc-v1/dapp-builder-infrastructure "mention") section of the docs.
## **Data Provisioning Flow**
The diagram below shows the flow of data from *source chains* to universal smart contracts on Creditcoin.
Reading the diagram above, we can see how groups of attestors begin by following new *source chain* blocks. Then, whenever a DApp submits a query to the Creditcoin Decentralized Oracle, the attestations previously stored on Creditcoin are used to prove that query’s target transaction took place on its *source chain*. The proving results from this query are then stored on-chain in the oracle’s prover smart contract. Finally, universal smart contracts on Creditcoin can read the resulting oracle data, interpret, validate, and finally use it to trigger business logic across any number of custom DApps.
## **Creditcoin Oracle Example Use Case**
The following diagram demonstrates the use of Creditcoin `USC` to power a cross-chain loan infrastructure:
Dark green arrows represent actions that take place as part of the attestation process, creating attestations which can later be used to verify whether any given block is part of the finalized source chain. Light green arrows represent actions taken as part of the proving process, which generates a `STARK` proof for parts of a specific requested transaction.
Red arrows represent actions that take place as part of the attestation process, creating attestations which can later be used to verify whether any given block is part of the finalized source chain. Blue arrows represent actions taken as part of the proving process, which generates a `STARK` proof for parts of a specific requested transaction.
`Ethereum`, with the eventual goal to enable data provisioning from any chain.
* **Execution chain:** Creditcoin blockchain with oracle infrastructure and Universal Smart Contract support.
* **Attestation:** A cryptographic commitment to data from source chain blocks, validated through consensus.
* **Proof:** A cryptographic proof certifying that parts of a given transaction occurred on a *source chain*.
> We only prove *parts* of a transaction as transactions can be quite large, involving many smart contract calls and emitted events. Proofs like `STARK` can get quite expensive for large transactions, so we restrict the proof to the parts absolutely necessary to inform *execution chain* state transitions.
* **Query:** A request to prove certain fields of a transaction. Each query specifies which *source chain*, *block number*, and *transaction* it wants to be proven.
## Architecture
The Creditcoin Decentralized Oracle relies on 3 decentralized groups of actors:
### Attestors
These make assertions about their view of the latest state of a *source chain,* such as Ethereum. Creditcoin doesn't trust any single attestor's report about changes to a source chain's state. Instead, a decentralized group of attestors must reach consensus on what state changes, if any, have occurred.
> For more information on attestors, check out the [attestation](https://docs.creditcoin.org/usc/creditcoin-oracle-subsystems/attestation "mention") section of the docs.
### Provers
These generate *cryptographic proofs* as a response to user submitted queries. Each query requests information on *parts* *of a transaction* (Ex: `to`, `from`, `value`) on a client *source chain*. The prover then processes that query to make those parts of the transaction available on Creditcoin. The prover conducts its work in three steps:
1. First, it uses attestations to prove that the block containing our query transaction is a part of the source chain’s state.
2. Second, it uses merkle proofs to show that the block does in fact contain the query transaction.
3. Finally, a cryptographic proof is generated that, upon verification, proves both these properties.
> For more information on proving, check out the [proving](https://docs.creditcoin.org/usc/usc-v1/creditcoin-oracle-subsystems/proving "mention") section of the docs.
### Validators
These form the *authority set* of the Creditcoin blockchain. They act as gatekeepers, ensuring that the attestors and provers perform their work correctly. Validators check attestor signatures on attestations to verify that a sufficient quorum voted before committing those attestations to on-chain storage. Later, validators run proof verification logic to ensure that the proofs submitted by provers are valid. The fields provided by a proof become available to smart contract logic on Creditcoin only after validators finalize a block containing that proof.
### Interoperability
The net effect of all this work is that third-party builders can create contracts on Creditcoin which have secure, **seamless** access to data on other chains. Such contracts could, for instance, securely burn `ETH` on Ethereum and then *trustlessly* mint `ETH` on Creditcoin, without having to rely on any centralized party.
Builders can leverage these properties to create universal smart contracts which support their own custom cross-chain DApp business logic.
> For more information on how to set up your DApp's logic to leverage Creditcoin `USC`, check out the [dapp-builder-infrastructure](https://docs.creditcoin.org/usc/usc-v1/dapp-builder-infrastructure "mention") section of the docs.
## **Data Provisioning Flow**
The diagram below shows the flow of data from *source chains* to universal smart contracts on Creditcoin.
