The power of DBCs on Safe Network

Safe Network Digital Bearer Certificates (DBC) could be used to manage and transact many kinds of asset not just Safe Network Tokens (SNT). We’ve already had some discussion of NTFs and I think other cryptocurrencies but I haven’t realised the extent of this and how easy and powerful it could be.

If used with other cryptocurrencies such as Bitcoin, those currencies would then benefit from Safe Network’s instant, energy efficient, scalable and effectively anonymous transfers. That’s great, but even better:

  • this can be achieved without having to connect to other cryptocurrency networks or integrate Bitcoin etc. full nodes within Safe Network.
  • very little extra code would be needed because DBCs are already doing most of the work for SNT. I’m pretty damn sure I’m not the first to think of this, not least inside MaidSafe, but I haven’t seen it spelled out (or maybe I’m just slow :smiley:) so here I go!

Example using Bitcoin (now the national currency of El Salvador).

Extra functionality we would need to implement:

  • create a Bitcoin wallet (keypair) on behalf of a Safe account where Safe Network stores but does not reveal the private key. (Maybe this uses bitcoin multi-sig addresses and the private key is split between section Elders).
  • management of the wallet using a DBC which allows the owner (who never sees the secret key) able to transfer ownership of the (whole) wallet to another Safe ID.
  • ability to obtain the secret key from the DBC, invalidating the DBC, so the Bitcoin private key can be used as normal outside Safe Network.

This creates a proxy for ownership and transfer of bitcoin wallets (or any other kind of crypto wallet) over Safe Network without any interaction with the bitcoin network itself. The owner of the bitcoin wallet is the Safe Network, which obscures the actual owner, and hides the ownership history of the wallet.

  • Anyone can check wallet Bitcoin balance using the public address, and can send bitcoin to it independent of Safe Network as normal.
  • Ownership of the wallet can be transferred between Safe accounts and a recipient can check that they are the owner, and know they now control the Bitcoin in that wallet.
  • Settlement can be achieved (but will rarely if ever be needed) by the Safe owner obtaining the private key for the Bitcoin DBC, which in turn invalidates the DBC. They can then import the bitcoin address into any bitcoin wallet, and it no longer exists on Safe Network.

None of this requires Safe Network to have a gateway to or any kind of interaction with the Bitcoin (or other cryptocurrency) network. All it needs to be able to do is generate and store the Bitcoin wallet keypairs and manage ownership using DBCs.

People can wrap any amount of bitcoin like this and transfer it as if it were SNT (but not split it). So if there’s 1BTC in the wallet you can transfer 1BTC but not 0.5BTC. The amount can be increased at any time outside Safe Network though, by sending additional BTC to the wallet. So if it has 0.001 BTC and you want to make it 0.01 BTC you can send the difference to top it up as a normal BTC transaction. It will remain there until you or some future owner decide to invalidate the DBC and obtain the private key for import into some Bitcoin wallet software or create a transaction directly using the key.

I’m not sure if this was apparent to others, but the full implications are only just occurring to me!

Wrapped Bitcoin
The above is not quite wrapped Bitcoin as we’d expect it, since wrapped coins can be moved in any amount, not just as a whole wallet.

Good news is that I think Safe Network can do this too, because we can create a Mint for SNT we should be able to create a Mint for a wrapped amount of anything, including Bitcoin, and then transfer fractions of this (or rather ownership of those fractions) between Safe accounts. I think this may have already been stated but don’t know exactly where.

For example: Carol uses SN to create a DBC with 1BTC in it and uses this to create a Mint with denominations of one millionth of a BTC. She can now send any fraction of this BTC to other Safe accounts in denominations of 1 millionth of a BTC up to a total of 1BTC.

I’m not sure how settlement can work in this case, and without that we have lost fungibility as Bitcoin. We have though created a potentially more valuable new fungible class of minted Bitcoin proxy coins, in whatever denominations the Minter chooses. More valuable because of speed, energy efficiency, transaction cost, scalability and anonymity.


Another trick. We can easily 1 way convert / swap coins like this.

  • Create Safe keypair (BLS so we can then make it multisig if we wish)
  • Try convert to btc address (or whatever) i.e. base58 and check starts with a 1 (or repeat above)
  • Send your BTC to that btc address (which nobody can create a priv key for)
  • Create a mint request to mint X SNT for Y BTC (or whatever, i.e. omni/MAID)
  • Elders check BTC blockchain (via on line block explorers for example) and mint the SNT at whatever rate that is current (or 1:1 swap)
  • Dbc is then issued back to the client for the SNT

Just an example, but we can do quite a lot here with this as you note above, although more eloquently, as usual.


If I understand that, you are able to burn Bitcoin, or Omni/MAID etc, and have an amount of SNT returned at a rate which is determined by Safe Network.

This will be an extremely easy way to convert any suitable cryptocurrency to SNT (in addition to the options I gave in the OP).


It’s a conversion process from X to SNT and it’s one way.


Yes you are correct a burn is a final tx for that blockchain asset.

Yes this is a simple 1:1 transfer.

Yes at scale this would destroy X :slight_smile:


This is all very interesting, with many many use cases.

I see where Antifragile is coming from though, if someone wanted to move btc to snt, the snt are not free, they need to come from someone, not just minted out of thin air, so the btc would need to go to a snt holder not just be burnt, but they could receive a true btc DBC so it’s fine.

For a type of wrapped coin / snt equivalent this would be great.

I hadn’t even considered any of this, hats of to you, genius.


What does this mean?

DO you mean like erc20 rules? All this tokenomics is buzz word mental. In general it means here are some rules and governance, so there?

So creating your own token economics is a very wide question. i.e. on erc20 you cannot do that, there are rules around it all.

Or are you looking at what would the rules/limits be?

You could even do that on day 1 IMO. I am pushing for this type of thing. So the Dbc has a field that can be set. So let’s set that to AntiFragileToken. You then reissue a Dbc into a billion outputs. So you have a billion AntiFragileToken. You can send them to anyone then, but caveats for now (none that are not solvable, but I am not keen on designing this immediately :slight_smile: (time))

  • Can not merge these
  • Can not split them either

Fixing the above is simple enough when we have the impl in place. Al it involves is to allow the Dbc to hold a number field and a type field. So you can merge/split Dbc of the same type based on the number field. It’s like a nested Dbc, so uses the Dbc infrastructure to protect it.

Hope that helps.


Every time I think I have a handle on things, the community surprises. Effortless wrapping and transfer of custodial assets. Wow.

Funny in a way, with SAFE transferred BTC, we have come full circle to yap/rai stones. Everyone agrees they are valuable and are too heavy to transfer, so we simply agree on who has the right to move it now, should they wish.


Yes and I would see it like this.

  • You issue your AntiFragile PubKey (make it public)
  • You state you will create 1billion coins
  • You sign each type in each output Dbc with your SecretKey
  • You re-issue a Dbc with 1 billion of these outputs.
  • Each Dbc issued has that single parent Dbc (so can be checked)
  • Publish the input Dbc and DbcSpent transaction.

That gives you a capped and verifiable supply. We can do (much) better though and in addition we are looking at single use keys. That would be even slicker in many ways, but more on that soon, I hope.


In the simple example right now yes it would, but …

I see that as a simple enough addition to the logic there to allow many such tokens and rules for them.


Maybe this uses bitcoin multi-sig addresses and the private key is split between section Elders)

That’s bad craziness. Please don’t do things like that.

  • If you put extremely high value keys like that on a relatively small, centralized set of machines, you’re painting a target on those machines. Not only are they a monoculture all running the same relatively new Safe code, but they can each also be attacked by means completely outside of Safe.

  • Safe has a relatively good Sybil resistance story… but no permissionless decentralized system has solved Sybil resistance well enough to elect a relatively small set of nodes to hold keys of that kind of potentially unlimited value. Especially because you can at best require a quorum, not unanimity. With Bitcoin, it’s also not free to change the key as old holders go away.

  • If you interlock with another system, you spread the impact of any failure beyond your own system. Not only does the damage become worse, but you become an even bigger target.


Couldn’t this be solved by multiple sections requiring to do that? Sooner or later we will need such system, where network/section multisigns such things.

You can keep increasing the number of shares, but not without limit. It helps, but it’s hard to quantify how much it helps. That’s the whole problem with Sybil resistance. In fact, it’s even possible to accidentally introduce dependencies between “independent” nodes. People constantly intertwine the fates of things by running them “in the cloud”, usually without thinking about the impact.

This aproach looks like, lets not handle anything valuable. Safenetwork is required to secure much more than few wrapped bitcoins. Honeypot of data stored should be way higher. In case SNT has higher market cap than BTC than what?

Several answers to that:

  1. Cash equivalents are always bigger targets than things that can potentially be converted to cash.
  2. If I store some high-value data in the network, I can and should layer encryption on top of that. Just using Safe for data storage doesn’t imply that there’s no other protection. On the other hand, if “the network” has to be able to do something with a crypto key, then that key has to be accessible to “the network” without any additional protection.
  3. Data whose disclosure are that damaging are actually really rare, and usually belong to people who would be able to evaluate the risks and add those layered precautions.
  4. With “native” Safe applications, you’re trusting one system. If you interconnect with another system, you’re trusting both of them, plus the way they interact. Block chains on their own are already complicated enough. You can legitimately say that people are making their own choices with an integration like the suggested one, but you’re still implicitly telling them it’s OK and encouraging them to do it.

Let say BTC goes to zero, how that harms safenetwrok? It will simply multisig a transaction of 0 value. Not big deal.

I was more worried about Safe harming some smart contract system that would not otherwise have any dependency on Safe.


This is not an issue because how much BTC you wrap in a single DBC-wallet is up to you, which makes this an easily manageable risk: you can create multiple wrapped BTC in different DBCs to handle larger quantities with less risk, similar to spreading BTC holdings across multiple addresses.

It is of course valid to ask what is the risk of a Sybil attack, but I think it will be small enough that you should be able to hold large value in a single DBC. What is an acceptable risk for a given value will be case by case, so what is needed is not to rule this out, but to have confidence in the level of risk.

Safe Network can be expected to achieve very good resistance to Sybil attack and we have been promised the maths behind this. This will be tested theoretically, the code audited, demonstrated practically (e.g. with hacker challenges) and tested over time with real world operation. Over time we’ll be able to say with increasing confidence what kind of risk is involved and the scale of value which can be secured, and whether or not there are use cases which would benefit from enhanced measures, such as @Antifragile suggests.


I have been struggling to get DBC but your bitcoin example has just blown my mind. We are Safe. We are the future.

But I still don’t understand DBC technically, any pointers to reading appreciated.


Great thread!

Are there plans to allow multiple DBCs to be traded in a single atomic swap? If that can be done, distributed asset trading of any type will be cracked right open.


Yes, we already have that. So we have input Dbc and output Dbc, both can be multiples. So we can merge many Dbcs into 1 or split 1 into many.


Here’s quite a good primer: Digital Money and DBCs


Thanks Jim

1 Like

Re: sybil attack … this premised on knowing that there is something of value to be gained that is worth MORE than the cost of the attack … but how does one know how much value is stored on Safe in DBC’s? People can make claims I suppose and you can know how much you have. But unless there is a public ledger somewhere, then it seems unlikely that anyone would go to the trouble. Or have I missed something?