DApp Design Patterns

An overview of common design patterns for enabling seamless user interactions in a DApp powered by Universal Smart Contracts

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.

Creditcoin Oracle Design Patterns

How you can use the Creditcoin Oracle vs how you should.

Cross-chain DApps use Universal Smart Contracts in a way that is intended to be maximally flexible. Any data from a source chain such as Ethereum can be securely moved cross-chain by the Creditcoin Oracle. That data can then be verified and used by the Universal DApp which lives on the execution chain, Creditcoin.

This way, the design space is left open for DApp teams to build whatever source chain logic they want and use the Creditcoin oracle to provision whatever data they want.

Most projects, however, are best served by following a specific pattern.

Source chain data flow patterns

These are patterns governing the flow of data to and from the source chain smart contract.

All business logic should live on Creditcoin. The source chain contract should focus on emitting events with the necessary data.

We want to keep logic on the source chain as minimal as possible!

1. Users call a source chain smart contract.

2. The source chain contract emits one or more events.

That's all!

Execution chain data flow patterns

These are patterns governing the flow of data to and from the Universal Smart Contract.

We want to make executing the universal smart contract as seamless as possible!

1. An off-chain worker listens for events from the source chain smart contract

2. The worker waits for the block containing the event to be attested on Creditcoin

3. The worker generates Merkle and continuity proofs using the Proof Generation API

4. The worker calls the USC contract with proofs and encoded transaction data

5. The USC contract verifies proofs synchronously using the Native Query Verifier Precompile

6. The USC contract executes business logic immediately in the same transaction

Best Practices

Beyond the flow of data described above, we outline some best practices to manage the source chain side of your Universal DApp:

1. A Universal DApp should have a single source chain contract which emits all the events relevant to the Creditcoin Oracle. That way, the offchain worker building oracle queries for your DApp only needs to follow events emitted from a single contract address.

2. Unambiguous events: Events should be unambiguous. Try to use unique events for each kind of oracle query you want to submit. For instance, a lending DApp tracking loans on Ethereum would want separate events for LoanInitiated and LoanRepaid.

3. Clear event naming: Events should be named so that it's clear they will initiate cross-chain functionality. For instance, the event name TokensBurned (as used in the examples) clearly indicates a token burn action.

4. Avoid common events: Don't initiate cross-chain functionality using common events such as standard Transfer events. Instead, prefer to wrap actions in calls that emit more specific events such as TokensBurned. This makes it easier for workers to filter and process the correct events.

5. Include all necessary data: Add all the relevant information you want moved cross-chain to the events emitted by the source chain contract. For instance, the TokensBurned event should have fields from and value indicating which account burned the tokens and how many tokens were burned. Otherwise the USC contract on Creditcoin won't know which account to mint tokens to or how many.

Next Steps

Offchain Oracle Workers

Check out this tutorial for an example of how to use the Creditcoin stack to set up a decentralized trustless bridge.